A deep dive into the UX of the Nostromo’s self destruct procedure

Because I was so preoccupied with whether I could, I didn’t stop to think if I should…

Jaye Hackett
5 min readMar 22, 2019

Alien (1979) is one of my favourite films, partially because of Ron Cobb’s excellent “used future” production design.

The heavily industrial designs of the spaceship Nostromo contrast heavily with our modern sleek, silver-and-blue spacecraft aesthetic. It’s all physical dials, curvy CRT monitors and exposed pipework. Like an oil rig in space.

Original Ron Cobb concept art for the Nostromo’s bridge

At the climax of the film, Ripley triggers the Nostromo’s self-destruct to rid herself of the titular menace. The process is deliberately convoluted and confusing, raising interesting design questions:

How many steps is that?

A self-destruct is certainly something you don’t want to trigger accidentally, and despite their well-publicised flaws, Weyland-Yutani presumably didn’t foresee a hostile extraterrestrial stowaway when they were building the Nostromo’s interfaces. Does this justify all the confusing steps?

Good design is sensitive to the emotional state of its users, and although no real-life vehicle has a self-destruct (as far as I know), fiction has thrown up only a limited number of situations where you’d want to use it. Things like:

  • To prevent a valuable ship being captured by space pirates or other baddies
  • To prevent a navigational hazard by destroying a malfunctioning ship

These are all incredibly stressful situations where time is of the essence. A well-designed critical system would avoid unnecessarily confusing already-tense users.

We know from real-world UX failures like the Chernobyl disaster that accurate indicators of system status, and clear, simple controls are vital if users are to take the correct steps in risky, high-stress situations.

The emergency destruct controls, with instructions, keyboard and collapsible towers visible.

Let’s look at each step Ripley takes to scuttle the Nostromo:

First, hit a button marked “PRESS IN EMERGENCY” to release a cabinet cover, and pull the big red lever inside

This first step doesn’t seem to be part of the procedure itself per se, and is a little redundant given the additional lever-pulling right after. Best to get rid and get straight to the good stuff.

Unscrew a second nearby cover to reveal more big red levers, and pull them both.

These levers are just brilliant. Big, red, suitably dangerous-looking, and you need to pull them in the right order. Exactly what you want for a critical, destructive user action. Almost impossible to trigger accidentally. 10/10.

Wonderful levers

Open up a floor-mounted panel on the other side of the room, containing the “actual” emergency destruct controls.

Now we get into the weird stuff. I don’t think there’s any design reason for this panel to be:

  • in the floor
  • on the other side of the room to where Ripley just was

This only makes sense if we assume that the Nostromo’s nuclear reactor is right underneath Ripley, and by operating this panel she’s directly touching the reactor, rather than using an explicitly “designed” interface abstracted away from the machinery it controls.

This also accounts for the fact that all these controls aren’t on the bridge where they clearly should be.

The instructions on the emergency destruct panel, with helpful French (!) translation

The text on the cover of the panel has a reasonably good typographic hierarchy (the word DANGER is appropriately, largest), but the instructions themselves, arguably the most important text on this cover, are tiny and shoved into one corner!

Spend precious seconds reading instructions, then press a sequence of buttons.

No no no.

This keyboard violates practically every design rule there is. Seeing as there’s no hint of flexibility in the self-destruct process (the timings are printed out, after all), we’d be better off just getting rid of this keyboard entirely.

Nightmare keyboard

It is worth noting that Ripley doesn’t appear to provide any passwords or passcodes during this entire process, so theoretically anyone could give the Nostromo’s crew a very bad day indeed. This keyboard would be a sensible point for such authentication to occur.

Security for MU/TH/R, the ship’s computer, is similarly flimsy. Despite us being told several times that access to the computer’s interface room is tightly controlled, Captain Dallas and Ripley never seem to provide any authentication codes or similar to access the room.

Perhaps Weyland-Yutani is just very trusting when it comes to mission-critical systems, or maybe there’s some kind of hidden biometric identification we’re not seeing.

Screw four bolts into collapsible metal towers, pull them up and press a button on each one.

This is the strangest step, and it certainly violates the basic design rule of obviousness.

As Ripley interacts with each tower, it starts rising of its own accord out of the console. Roughly halfway through the process, MU/TH/R’s famous ten minute countdown starts and the game is on.

Reactor control rods?

The biggest usability issue here is that it’s not clear to the user exactly when the self-destruct is “on” and “off”. This comes back to bite Ripley (hah) in a big way later on, when she tries in vain to cancel the self-destruct, missing the five minute window by seconds.

How does it measure up?

Although Nostromo’s self-destruct certainly makes accidental activation difficult, it falls short in key areas:

  • Still easy for a bad actor to follow the procedure, since there’s no obvious security involved.
  • The five minute grace period to cancel the self-destruct is basically meaningless, since the cancel operation itself takes a significant amount of time and there is no single moment at which we can say it’s “done”. Ripley thinks she’s done it in time, but is mistaken.
  • Several steps don’t make the process appreciably harder to trigger accidentally, but do add confusion, like the keyboard from hell and the lever to access the other levers.

Doing it better

A better-designed interface would:

  • Be sensitive to the user’s immediate needs, and their wider social needs (“I need to destroy this ship, but I am frightened and rushing”)
  • Make it easy to recover from errors (“I’ve changed my mind about destroying the ship!”)
  • Be only as complicated as it needs to be to achieve the user’s goal
  • Confirm user permissions (“I have the right to destroy the ship if I choose”)

Let’s take a moment to appreciate a much more sedate, user-friendly and secure self-destruct proceedure. Maybe if Weyland-Yutani had hired some UX designers…

So much for the Enterprise E

--

--

Jaye Hackett
Jaye Hackett

Written by Jaye Hackett

Strategic designer & technologist. Why use three short words when one long weird one will do? jayehackett.com