Case study: Hacking the Matrix with UX design
A Case Study By “The Designer”
The following report was rescued from the archives of the Nebuchadnezzar. It was drafted by an artificial intelligence known only as “The Designer.”
Table of contents
Introduction
Greetings, I am The Designer, a Construct model developed by the Zion Council in response to the Machine’s rapid rate of innovation.
The Council commissioned an audit of the Nebuchadnezzar’s mission preparedness after the ship suffered a series of catastrophic losses. Not only do these losses demoralize the team and inflict psychological trauma, but ongoing fatalities will force the Council to decommission the Neb from Matrix operations.
To avoid this, I have been tasked with identifying opportunities for increasing the Neb’s mission-success-ratio.
Scope
I examined our digital and physical mission support systems for opportunities to:
- enhance avatar sensory perception,
- optimize Operator’s console,
- maximize exit opportunities, and
- strengthen pre-op preparedness
Process
Step 1 — Field Study. I began by joining the crew on two Matrix missions and observing their behavior. I noted any important processes, significant moments, or roadblocks that occurred throughout each day. I also used the ship’s onboard security cameras to record and later review pre- and post-mission behavior.
Step 2 — Individual Interviews. Using non-directive and open ended questions, I encouraged team members to reflect on their daily experiences. Whereas observations enabled me to view behaviors, interviews revealed the underlying reasons for those behaviors. For example, during one mission, Trinity took 18 seconds to answer a payphone and exit the Matrix —a delay that nearly cost Neo his life. Understanding the reasons for this hesitation could enable us to prevent recurrence.
Step 3 — Journey Mapping. After I completed my observations and attitudinal interviews, I mapped out the overarching journey for Matrix missions.
Step 4 — Competitive Research. From there, I collected as much data as possible on the systems, processes, and success rates of other ships.
Step 5 — Synthesis. Finally, I synthesized my data into the key conclusions outlined below.
Key Insights
Matrix missions are extremely strenuous. Despite this, the Nebuchadnezzar has failed to allocate resources to the design and development of sophisticated equipment and processes. I’ve identified six critical updates that must be implemented if we are to improve the team’s survival rate:
- Keep medical staff on site
- Establish mixed reality visualizations
- Inject developer tools
- Modernize the Operator’s console
- Rethink exit strategy
- Use knowledge to your advantage
Let’s discuss each improvement below:
Keep medical staff on site
Starting with the low hanging fruit: given the treacherous nature of Matrix missions, the Neb’s failure to staff a single clinician is grossly negligent. Just one physician trained in emergency medical care could materially decrease mission mortality. Considering their sedated state, a physician may even be able to operate on members while jacked-in. But, in instances where operating isn’t feasible or necessary, there are still a wide variety of applicable mid-mission treatments.
Establish mixed reality visualizations
As stated above, crew members are essentially sedated during missions, leaving them blind to the outside world. Despite persistent threats from sentinels, natural disasters, and even sabotage, mission participants must be manually alerted by an operator of impending dangers. This is wholly insufficient, and it is imperative that the Neb develops a system for ongoing cross-reality communication.
Luckily, there are tools to do just this. Headjacks enable secure, two-way communication between the real world and the Matrix. Currently, the Neb uses this technology sparingly. Most inter-reality communication is conducted through virtual models of late-20th century cellphones. This is to avoid generating anomalies that could alert Agents of their presence. But there is another way to avoid alerting agents: using crew members’ pre-existing brain-to-computer interfaces. By leveraging headjacks to feed visualizations directly into their visual cortexes, and auditory perceptions directly into their brainstems, they could:
- stream live security footage from the Neb;
- stream live audio from the Operator, and
- project the Operator’s console as a heads-up display (HUD).
Since the data syncs directly with their brains, it never accesses the simulation and is completely invisible to Agents (and all other programs).
Inject developer tools
Using the same technology, jacked-in teams could enjoy a robust developer toolkit. Deja vu, for example, is generated by disruptions in the Matrix. Those disruptions could prompt alerts on the Operator’s developer console (now streamed through the HUD).
“A déjà vu is usually a glitch in the Matrix. It happens when they change something.” — Trinity
Once alerted, team members could use the HUD to run scans of the local area, track Agent activity, and get ahead of their plans.
Besides monitoring for threats, a developer console could enable jacked-in teams to establish exit points without Operator assistance. When in a crisis, such as during a sentinel attack, this independence could rescue teams from certain catastrophe.
Modernize the Operator’s console
In a time when hyper-intelligent computers rule the world, and a perfect replica of reality simulates life for nearly all of humanity, the Neb still relies on low-res monitors running something akin to DOS. Cypher, a less than reputable source, has insisted that “there’s way too much information to decode the Matrix.”
This is entirely inaccurate.
While the simulator does produce yottabytes of data per year, it is easily read by trained practitioners. If a human can read the Matrix, a computer can too. The fastest synaptic transmission is 10 million times slower than a computer equivalent. It is mathematically impossible for our brains to read code faster or more efficiently than, say, an off-the-shelf Graphics Processing Unit (GPU).
“The image translators work for the construct program — but there’s way too much information to decode the Matrix.” — Cypher, not knowing what he’s talking about
With this in mind, it’s time for the Neb to build a translation layer that can visualize the Matrix on high definition screens. This will lower the cognitive load required for operating the console and, in turn, dramatically increase the Operators responsiveness.
But, there’s no need to stop there. The translation layer isn’t all that’s missing from the Neb’s console. It’s also missing any form of touch interface. Instead, the ship relies on mechanical keyboards, an ancient relic of the 20th century. It’s long past time to install an adaptable, dynamic interface. When accessing the stock room, for example, the Operator should be able to seamlessly drag and drop inventory into the room. On the other hand, if searching the Matrix for exit opportunities, the Operator should be able to utilize a map interface with selectable locations.
Rethink exit strategy
Speaking of exit opportunities, the Neb’s reliance on landlines is a severe threat to its team’s safety. At present, exiting the Matrix requires that the following are true:
- an exit point is established by the Operator in advance;
- the Operator opens the exit point, ringing the phone; and
- a team member places the phone’s receiver to their ear, initiating the departure.
Given the perilous circumstances faced inside the simulation, accomplishing all three requirements is remarkably challenging. Moreover, this system requires that one member leaves at a time, drastically slowing the process.
One justification for such a cumbersome extraction process is “security.” I’ve been told that, unlike cell phones or other wireless technologies, landlines are inherently secure. Short of actually cutting the telephone wires, Agents can’t interfere with those exits. Another justification ambiguously claims that landlines provide a more “significant portal…than cell lines.”
To say the least, I find both of these excuses underwhelming. I’ll explain my thoughts on each one:
First, Agents are bound by rules. These rules inhibit their ability to manipulate the Matrix (unless, of course, they’re set free).
“…their strength and their speed are still based in a world that is built on rules. And because of that, they will never be as strong or as fast as you can be.” — Morpheus
This tells us that Agents can’t simply will a complex encryption away. They must hack through it like anyone else: with time and effort. This means that the Neb can safely use an AES-256 bit end-to-end encrypted cellular network and be more secure than through a telephone line. It would be virtually impossible for Agents to hack your network using 1999 hardware (or even 2016 hardware), and the minute risk that they can would be drastically offset by your team’s enhanced flexibility, adaptability, and reliability.
Second, my logs show that cellular connections reached up to 10 gb/second…back in 2021 — around 180 years ago. With this in mind, it’s unthinkable that, at the time the Matrix was architected, man or machine considered 7 kb/second to be “significant” (especially considering they were moving several brains worth of data).
Granted, none of this technology existed in the simulated world of 1999, so how could the Neb leverage it? That brings me to my next point…
Use knowledge to your advantage
Unlike Agents, humans are bound only by their minds. Free your minds, and you can do anything. Pair this with your complete and unhindered access to the Matrix’s physics engine, and you can invent, quite literally, anything within the laws of nature—including an encrypted cellular network. So, while the Agents are toiling away with a 7 kilobit landline connection, you can safely leverage the glory of 10 gigabits per second (or even 319 thousand). And, so long as your devices don’t draw the attention of the Matrix’s slaves, Agents won’t even notice.
“You have to let it all go, Neo. Fear, doubt, and disbelief. Free your mind.” — Morpheus
With this in mind, it is absolutely critical that the Neb onboards physicists and engineers with Matrix specializations. These new crew members would be responsible for analyzing, developing, and testing enhanced tools within the Matrix. This ongoing research could set your team leaps and bounds ahead of the Agents, resolving them to insignificance.
Takeaway
After conducting a thorough assessment of the Nebuchadnezzar’s mission preparedness, it is evident that the ship fails to meet the Zion Council’s mission guidelines. As such, it poses a material risk to its crew and joint mission task forces.
The Nebuchadnezzar must immediately implement suggestions or face censure. Once implemented, these changes must be monitored and updated as necessary until the Neb shows a substantially lower mission-success-ratio.
Objections or complaints may be filed with Councillor Hamann.
Jeremy Abrams is a senior full stack designer with a background in human centered design, research, and development. He also has a demonstrated history of managing local and remote cross-functional teams. In a prior life, Jeremy acquired a JD from the Chicago-Kent College of Law and was admitted to the Illinois state bar in 2014.