UX For Wizards
What it’s like to design for the command line
“I hate to say it’s like a conversation, because computers are really fucking stupid,” Randall Hansen is telling me, in a gruff voice thickened by a cold he’s fighting off.
“It’s more like submarine warfare. You’re in an unfriendly environment. Any sort of breach in the system or error in your process could cause catastrophic damage from which you and your co-workers are unlikely to recover. You periodically fire things off into a murky void, which may or may not return results, and may or may not accomplish their purpose. And the people who do it for a living tend to spend a lot of time hunched over keyboards in the dark, becoming specialists in arcane tasks, because there’s no other way to get it done.”
Hansen is a user experience designer based in Portland, Oregon, describing what it feels like to use a command line interface (CLI) on a modern computer. You’ve probably seen CLI’s in the movies, especially any movie about computers or “hacking” from the 1980s. Unlike a graphical user interface (GUI) such as Mac OS X or Windows, the command line doesn’t have a “desktop,” “trashcan,” mouse pointer, or any visualized interface elements whatsoever. It looks like this, which is pretty much the same way it looked 20 years ago, and 20 years before that:
That’s it. But when Hansen compares the user experience of a CLI to sub warfare, he’s speaking as a guy who happens to like the command line — or, at the very least, respect it.
And you ought to respect it, too, because everything that we take for granted with our cloud-connected laptops and mobile devices — that Twitter refreshes when you pull-to-refresh; that your Amazon item actually gets purchased when you click the orange button on Amazon.com; that Gmail doesn’t flush your messages down the memory hole when you “archive” them — all that coordinated functionality takes place in data centers full of servers managed by people called “system administrators.” And sysadmins use the command line.
Hansen used to direct the UX design team at Puppet Labs, a software company specializing in “IT infrastructure automation.” The team’s job was (and still is, although Hansen has moved on to other projects) to make using that prompt and cursor less like sub warfare for their users — and “even introduce some delight into the experience,” he says.
And why not? Sysadmins are people too. It’s just that their UX stakes are much, much higher. If you or I download a crappy app that makes it cumbersome or confusing to add a filter to a photo, we leave a 1-star review on the App Store, delete it, and life goes on. But if a sysadmin’s software—with its command-line interface—is cumbersome or confusing to use, it puts entire systems at risk. When Gmail goes down for ten minutes, the entire internet freaks out; the difference between those ten minutes of inconvenience and some potentially catastrophic downtime might hinge on the user experience that a sysadmin encounters when solving the problem.
In other words, our convenient, cloud-based computing world is actually a command-line world: we just (ignorantly, blissfully) live in it. But for the people who do make all our digital trains run on time with their arcane keyboard commands, what is “user experience”?
You’ve probably heard the oft-quoted line from Steve Jobs about design: “It’s not just what it looks like and feels like. Design is how it works.” If your job is to design UX for a CLI, you could just throw out the first sentence altogether. The command line has no substantive look or feel. “How it works” is all there is.
A graphically-interfaced app or file system needs a “look and feel” because it is simulating an object that you can physically manipulate. To a sysadmin using a CLI, however, the system is less an object than a servant waiting to carry out orders. If the definition of a “good” UX for a GUI-based app boils down to “it just works,” a “good” UX for a CLI process might be simply stated as: it just obeys.
Since the point of a command line is to issue—you guessed it—commands under expectations of automatic and precise obedience, some of the usual GUI-based assumptions about computer usability get turned inside out. Instead of ample affordances and rich interactivity — which provide multiple, discoverable, error-tolerant paths to fulfilling the same task — a CLI user wants the opposite: minimal interactivity, maximal precision, and what Hansen calls “silence in success.”
“You want to make changes to the state of the system as efficiently as possible,” he says. “That means fewer keystrokes for issuing commands, and no ‘confirmation’ feedback when something executes successfully. The assumption is that the system does exactly what you tell it to.” In other words, the progress bars, green checkboxes, and other real-time reassurances that GUIs provide to users that their actions have been registered by the system are just distracting noise in a CLI. “It would probably make the user annoyed, like there are training wheels that they can’t take off,” Hansen says. Errors are to be reported succinctly and described specifically; otherwise, the system ought to “keep its mouth shut.”
So how does a UX designer “delight” the user of such a spartan tool? Not with the toylike visual surprises of consumer software, but by exceeding functional expectations.
“Using the command line is all about controlling a computer at the speed of thought,” Hansen says. “If you can type 100 words per minute, that’s how fast you can make things happen on the command line.” Something as basic as tab completion—in which the computer auto-completes the rest of a command after the user types the first few characters and hits Tab—can make the UX of a CLI feel even more frictionless, he says. Sensibly organized, well-written documentation also goes a long way (after all, a command line user can’t visually “poke around” inside menus to discover functionality).
“It’s common just to spray out all the options in alphabetical order, but the first time you encounter it you may not know what you’re looking at, other than a thousand lines of ‘help,’” Hansen explains. “Good documentation will have several examples at the bottom: ‘Hey, you want to perform these five common tasks? Here’s how. Here’s why.’”
“Delight” may be Silicon Valley’s design buzzword du jour, and its analog on the command line may sound pretty arid. But Hansen has a story about how that Spock-like UX pays off. “I know a guy who worked at Morgan Stanley in New York years ago,” he says. “He created a command line tool that lost something like $70 million in less than a minute by running out of control and eating all the memory on a certain machine. As soon as he saw this happening, he ran across the room to the sysadmin, who put in a single command that shut it down in a matter of seconds.
Every time this guy might have made a typo, it would have cost another $10 million. But he typed the command right the first time.
“What this guy knew he was doing wasn’t saving a file or quitting an application,” Hansen explains, “but murdering a runaway system process with a certain name on a certain machine, all at once. He had all the variables in his head, and he knew the most efficient way to precisely manipulate the state of the system in one stroke.” Like the Sorcerer in Disney’s Fantasia rescuing hapless Mickey from the onslaught of water-carrying brooms with a forceful sweep of his hand, the sysadmin could tell the whole desperately spiraling mess to just stop. I’ll bet he was delighted.
