Keep the simple path short and the deep path open

A camera that takes a decent picture when the shutter is pressed, and still lets a photographer set aperture and exposure by hand, follows this rule. So does a spreadsheet. Typing numbers into a grid and adding up a column takes no training, while the same program runs the macros and models behind a company’s forecasts.

Kay’s slogan came out of his work at Xerox PARC in the 1970s, where his group built Smalltalk and argued about how children and other non-specialists should use computers. The aim was a system a child could start using right away that would never block an expert who wanted to go further. Colleagues at PARC took it up as a design principle for their own projects, the hardware designer Chuck Thacker among them.

Each half rules out a common failure. “Simple things should be simple” is aimed at products where an everyday task requires the full machinery: a form with thirty fields to send a basic invoice, or a configuration file to change one setting. “Complex things should be possible” is aimed at the opposite, products so stripped down that anyone with a real need outgrows them in weeks and leaves.

In practice the principle is about layering. The common path is visible and short. The deeper controls exist but stay out of the way until someone looks for them, in an advanced panel, a keyboard shortcut, a scripting interface or an API. Unix command-line tools work this way, with a bare command for the usual case and flags for everything else. Good web applications do it with sensible defaults and a settings page that most users never open.

The difficulty is that the two halves pull against each other as a product grows. Every complex capability adds weight, and some of it leaks into the simple path: an extra option on the main screen, or a dialog that asks a question most users cannot answer. Microsoft Word is the usual example. Typing and printing a letter never stopped being possible, but years of added features crowded the menus until Microsoft rebuilt the interface around the ribbon in 2007, largely because users kept asking for features the program already had and could not find.

Some products are better off refusing the second half. A tool whose value is its plainness, such as a to-do list with no settings, can lose its appeal the moment it becomes a platform. Its users chose it because it could not do much. For products like that, a more honest rule is that complex things should be possible elsewhere: let power users export their data and move to something heavier.

The slogan also leaves a hard question open, which is what counts as simple. Designers tend to decide from their own habits, and the tasks most users perform are often different from the ones the designers imagined. The reliable way to find the simple path is to watch what most people actually do, then make that path short.

What keeps the line useful after nearly four decades is that it names two failures at once. Most design advice warns against one of them, and a product that avoids only one has usually walked straight into the other.