The Obvious, the Easy, and the Possible

Last year, when the show was still running, I used to binge-listen to Work In Progress, the podcast with Jason Fried (founder and CEO of Basecamp) and Nathan Kontny (CEO of Highrise).

In one of my favorite episodes, Fried talks about the idea of thinking about product development and interface design in terms of three buckets: the obvious, the easy, and the possible.

In this article, I’m going to explain what this idea is all about and why I think it’s so powerful – even if you’re more of a programmer person and don’t think of yourself as someone who can design web applications.

The three buckets

Whenever you build a product or feature, you have to figure out what matters – and to what degree – and what does not. You then focus development efforts appropriately.

According to Fried, you have to understand which things go in which bucket by asking yourself these three questions:

• What needs to be obvious? The thing(s) people do all the time – the core of the product – should be obvious. On Twitter, for example, it’s obvious how to send a tweet thanks to the big blue Tweet button in the upper right corner. Not everything can be obvious, of course, because screen real estate, attention span, etc. are limited resources. It’s your job to decide.

• What should be easy? The things people do frequently, but not always, should be easy. It can be hard to know the difference between the two, though. Byword, my writing app of choice, makes it easy to export a Markdown document to PDF via the File menu. In a writing app, exporting isn’t something people do all the time, yet it’s done often enough that it should be easy to accomplish.

• What should be possible? The things people do sometimes – or rarely – should at least be possible. On GitHub, it’s possible (but not obvious or particularly easy) to create a new OAuth token via Settings -> Personal access tokens -> Generate new token -> Confirm password -> Enter token details. As there tend to be way more things in this bucket than in the other ones, you should ask yourself if making something at all is the right choice.

Command-line interfaces

You might be wondering why I, a systems guy who’s mostly into web infrastructure, care about design principles. Indeed, the only interfaces I normally “design” are command-line interfaces – the primary means of interaction with the bulk of server software.

But even though designing a web application and creating a CLI are two different beasts, the same principles apply. When developing a command-line tool, you too have to figure out:

• What needs to be obvious? It’s best practice to provide commands for the most common operations. For instance, the Go tool makes it clear that go build will compile source code whereas go test will run tests. Most Go programmers use both many times a day, justifying the existence of these commands.

• What should be easy? You should offer command-line options (or sub-commands) for actions users do frequently. The go get command, for example, downloads and installs packages along with their dependencies. When passed the -d option, it will skip the installation step, providing a convenient way to fetch all of a project’s dependencies.

• What should be possible? You may allow users to enable advanced, experimental, or dangerous features via environment variables or lengthy command-line options. Setting the GO15VENDOREXPERIMENT variable in Go 1.5, for example, will tell the Go tool to resolve dependencies in vendor/ directories. For other use cases, it might be enough to output data in a structured format that’s easy for other tools to process.

Conclusion

No matter if you’re creating a web application, command-line tool, or any other user-facing product, thinking deeply about what needs to be obvious, easy, or possible can mean the difference between building something that merely gets the job done and something that’s a joy to use.