CLI Design: an idea whose time has come

Al Sargent
4 min readDec 10, 2020

Recently, Tomasz Tunguz published an essay on Rediscovering the power of the Command Line. One bit stuck out:

The learning curve is steep, and I mean precipitous. I had to learn vim first, and then I read piles of configuration examples to get things working properly. Most of the documentation isn’t great.

In other words, command line interfaces (or CLIs for short) are powerful but not user-friendly. This might seem like an arcane problem, but it’s not. For any developer-first company like Twilio, Stripe, Hashicorp, or AWS, terminal usage is crucial piece of the user experience. The better a CLI, the higher the adoption, and the greater the valuation.

Thus, a good CLI can drive incremental growth that’s worth billions of dollars in valuation. Twilio is valued at $50 billion as I write this. Stripe, $100 billion. Hashicorp, “only” $5 billion.

And yet, even with billions at stake, little has been done to optimize CLIs.

A lot of terminal applications are quite powerful, but I get the sense that developers have focused more on building features into their CLIs, rather than making those CLIs easier to understand, quicker to use (think autocomplete), or providing good guidance when someone mistypes a command.

And we have little in the way of de-facto standards for CLIs the same way we have standards for graphical user interfaces, such as cntrl/cmd-z/x/c/v for undo, cut, copy, paste. These commands, introduced decades ago with the first Mac, now work across many GUIs, whether web-based or native. We take this compatibility for granted in GUIs, but it doesn’t exist in CLIs.

To be fair, there are notable exceptions of great CLI design: zsh has some pretty incredible capabilities, including autocomplete, automatic cd, and spelling correction.

Another example: Homebrew, which tends to have very clear messages explaining what other commands one needs to run. Here’s one recent example:

To nontechnical folks, this might seem like intimidating gibberish. But to technical folks who are used to parsing through messages, this is highly usable: it tells us what to run (“git -C …”), why the restriction was made (GitHub’s request), and even has brand voice (“sorry for the inconvenience”).

But these examples of CLI design are very much the exception, not the norm. I believe that one root cause is that usability researchers and designers— at least the ones I’ve met — tend to come from artistic, non-technical backgrounds. They look at things like layout and colors, not text semantics. This isn’t a dig on them; they see things that I’ll completely miss. (For the record, I got a C in my college Art History class — which is supposed to be an easy course. Intelligence comes in many forms.)

Similarly, brand managers tend to come from a liberal arts background, often focused on the written words as well as the graphical arts. A terminal is a foreign experience for them.

And I haven’t heard Growth Marketing folks talk about instrumenting CLI usage to understand user journeys and feature usage rates. They often have a more quantitative background than Brand and Usability folks, but even so, are less than likely to have worked much in a terminal.

As a result, terminal UIs tend to get built by engineers who rarely, if ever, think about usability, brand, or growth metrics.

To address this problem, we need is CLI Design, where CLI Designers look to make CLIs as user-friendly, brand-consistent, and growth-driving as GUIs. These are the same things web designers do, but in the text-only medium of a terminal. It’s a new discipline, requiring a new role in the organization.

Granted, CLI Design is emerging as a concept, as these articles show:

… but there doesn’t appear to be any definitive books on good CLI Design, backed by research, that advance CLIs the same way Tog on Interface, About Face, Usability Engineering, or Don’t Make Me Think advanced GUI design back in the 90s, setting the stage for the fast growth of web and mobile applications over the past few decades.

Who’s going to write it?

It’s a ready-made opportunity for someone looking to advance their technical career, since the resources above, and others easily discoverable online, would probably provide you with a lot of content to get started.

--

--

Al Sargent

Occasional thoughts on tech, sailing, and San Francisco