How bad UX almost killed everyone in Jurassic Park

Our heroes start out when they discover the Main Control Room. Their goal is relatively simple: They’re trying to reset the power grids in order to re-electrify the fences/keep the Velociraptors at bay long enough for help to arrive.

Want to read this story later? Save it in Journal.

Tim hops onto the computer and here’s what he sees:

Now, granted, I don’t have a ton of context about the intended users or dinosaur park management best practices. But even so, there are some issues here.

• The number of visually identical options on this page is way too high. People can typically handle between 5–7 options at a given decision point, mayyybe 7–9 if it’s a system being used by experts all day.
• Further, these visually identical options misrepresent the information hierarchy. There actually is a hierarchical relationship here, but it’s not represented clearly enough. If you look closely, the top row of “Security Main”, “Monitor Main”, etc, seem to be containers for the options below them. (there are also lines between these options to enforce this), yet they’re represented identically, making this relationship unclear.
• It’s also not clear if those ‘Main’ sections are clickable buttons or just labels. These poor affordances that fail to distinguish clickable elements is a recurring issue.
• The options themselves are… poorly labelled. There’s a ton of acronyms, and various vague wording that leaves the user guessing and makes it difficult to know what will happen if you press an option or how to find a particular thing you’re looking for. This ends up being a big problem for our heroes.
• In all, I feel pretty confident that the organization of these categories does not reflect the mental model of an intended user.

Just to explore, Tim first taps “Access TNL.”

The system tells Tim he already has access and tells him to pick something else.

This ‘Access TNL’ button isn’t necessary. Why make a user go out of their way to figure out of they have TNL access? Whatever TNL is, it should just be accessible if you have access, or disabled/hidden if you don’t.

You may be thinking, well if the user didn’t have access, it’d help them get it. But if a user didn’t have access, they shouldn’t be able to edit their own access (because then why would it need to be restricted in the first place).

It would functionally make sense as an area for an admin to manage other people’s access, but we know it’s not that because if it were, it would have brought Tim to another screen where he could manage user access.

In any case, after poking around, Tim Taps ‘View VBB.’

The options on this page are… unclear, and the hierarchy is again far too flat.

Further, some of these boxes again seem to be actions, whereas some I think are labels.

While it is confusing, it’s not totally nonsensical. I’m pretty sure it’s an interface to help a user manage a set of security cameras and how their streams are displayed on monitors.

Assuming this, the division into two separate controls “Remote CLC Video — H” and “Remote CLC Video — P” feels unnecessary to me. There should just be a single list of all video feeds, and the user should be able to group them any way they like.

Within this screen Timmy explores various submenus and eventually gets a list of monitors (UI not shown). He tries to go back, but…

“Most systems had a single button or single command to return to the previous screen, or to the main menu. But this system did not.”

User’s always need an ‘emergency exit’ to get back to where they came from when they take a wrong turn or make a mistake.

We never find out how Tim gets back to the main screen, but eventually he does.

Next he jumps into Common Interface to try to find help on how to use the system.

It’s not totally clear what common interface is supposed to be. I think they’re generally applicable functions that can be applied across the system. Again, this UI doesn’t come close to speaking the user’s language. It also has some confusingly similar options: What’s the difference between “Find” and “Search”?

On this screen, Tim’s looking for help on how to use the system.

“Maybe help on this system was called “info”. He pushed INFO.”

If you can’t find the place to find help, you’re in trouble. Anyways here’s what he sees.

My only takeaway here is don’t hire Integrated Computer Systems to build your next park system. Not to mention Dennis Nedry (the guy who shuts down the system to steal the DNA and ruins everything) is the project supervisor.

He pushes ‘Find’, then ‘Go Back’.

It looks like these buttons are just informational about what they would do. This shouldn’t be necessary — a system should be self explanatory.

Even just taking that as it is, the guidance doesn’t tell me what these commands do or how to use them.

Tim’s happily poking around here, when…

“Suddenly, without warning, the main screen was back.”

Probably goes without saying, but a key part of good usability is giving the user freedom and control. Moving a user around without warning to different pages is not that (and maybe is a bug).

At this point, you might be wondering what is even happening anymore. The first time I read this, I had totally lost track of what they were trying to do.

Tim is trying to reset the power grids in order to re-electrify the fences/get control of the park. After poking around to all these different parts of the system, he’s accomplished nothing.

Treating this as a usability test, the design has utterly failed thus far. With a clear goal in mind, Tim has navigated through several main sections of the tool, none of which ended up being helpful. I do acknowledge a child is not the intended user of a large enterprise system, so some struggles with usability would be expected, but even so, the poor organization of the home screen and the system’s vague options have made it impossible for poor Tim and Lex to know how to accomplish their goal.

Tim scans the tool again and sees ELECTRICAL MAIN and SETGRIDS DNL both look like they might have something to do with grids. He also notices that SAFETY/HEALTH and CRITICAL LOCKS might be important.

Tim presses SETGRIDS DNL.

Then he presses Standard Parameters.

This screen is a key for the one above. Tim tries to use this screen to access the Lodge Grids by pressing the F4 button on the upper screen.

A system should not require a user to remember things to use it. Why not just put those labels directly on the first screen?

When he presses it, he gets an error:

“It was saying the power was incompatible with the command he was giving. But what did that mean? Why was the power incompatible?”

Unclear errors leave the user feeling frustrated. A good system should help users avoid errors like this in the first place. If there is an error, don’t blame the user and help them recover. This error does none of that.

After this, Tim and Lex get distracted for a while with some Velociraptors chasing them. When they get back, the main screen is flashing. (Black means they’re flashing).

Tim tries to press SETGRIDS DNL again, but gets another error: “Warning: Command Execution Aborted (Aux Power Low)”. Another unhelpful error. Tim is informed through the radio that he needs to turn on the Main power, so he pushes ELECTRICAL MAIN.

He pushes ‘Main’, nothing happens. Next he pushes ‘Main Grid P.’ He sees another error, “MAIN POWER GRID NOT ACTIVE/AUXILIARY POWER ONLY”. Then he pushes MAIN SET 1 and the power comes on. This would have been so much simpler if Integrated Computer Systems had hired a designer.

Once the power’s on, he pushes RESET GRIDS. Then he sees an option for which Grid he’d like to reset. He selects Lodge. He then needs to specify the grid number. Luckily he remembers its F4. Had he not randomly stumbled upon that key earlier, he’d have been screwed. Why would a user need to know the grid number to do this? Don’t make your user’s remember things!

Once he completes it, the grid is reset, the electric fences are restored, and the people are saved.