The obvious, the easy, and the possible

2 minute read

Update (August 2016): There’s now an updated and revised version of this article.


I’ve been binge-listening to Work In Progress, the YouTube show/podcast with Jason Fried (founder and CEO of Basecamp) and Nathan Kontny (CEO of Highrise). In one of my favorite episodes, Jason 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 post, I’m going to explain what this idea is all about and why I think it’s so powerful – even if you don’t think of yourself as someone who can design web applications.

Whenever you build a product or feature, you have to figure out what really matters. In other words, you have to understand which things go in which bucket. Ask yourself:

  • What needs to be obvious? The thing(s) people do all the time – the core of the product – should be obvious. For example, on Twitter 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. As an example, Byword for Mac 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 whether making something at all is the right choice.

You might be wondering why I, a systems guy who’s mostly into infrastructure automation, care about design principles. Most of the time, the only interfaces I “design” are command-line interfaces. While designing a CLI is undoubtedly different from designing a web application, the same principles apply: I have to figure out what needs to be obvious (and provide commands for common operations), what should be easy (e.g. via command-line options), and what should merely be possible (e.g. by enabling an experimental feature via an environment variable or by formatting output so that it can be processed by other tools).

By figuring out which things go in which bucket, it is more likely that I – and you – build something that actually provides value to the person using it, no matter if you’re creating a web application, command-line tool, or any other user-facing product.

References

The original post, “The Obvious, the Easy, and the Possible”, published on Signal v. Noise in 2011.

The show that inspired me to write this piece in the first place: