Designing the Obvious
Timeless design principles for apps
Description
There is a particular kind of software that gets out of the way. We open it, we do the thing we came to do, and we close it without ever once stopping to ask how it works. No tutorial, no manual, no moment of squinting at a button wondering what it does. It just behaves the way we already expected it to. Robert Hoekman, a web designer who spent years building applications and watching real people stumble through them, gave this quality a name in his 2006 book Designing the Obvious. Obvious software is the kind nobody notices — and that, he argues, is the whole point.
The trouble is that obvious is hard. Most web applications are not obvious; they are crowded, packed with features somebody once requested, lined with options that exist because removing them felt risky. Each addition seems harmless on its own. Together they produce the familiar experience of opening a tool and feeling slightly stupid, sure the problem is us and not the design. Hoekman's claim is that this is backwards. When users get lost, the application failed them, not the other way around. And the applications that don't get them lost share a small set of traits that have nothing to do with trends or technology.
What makes the book unusual is that it refuses to sell a process. There is no methodology to adopt, no certification, no diagram of phases. Hoekman is interested in the finished feel of a thing, and in the handful of principles that reliably produce it whoever you are — the founder, the developer, the person writing the copy on a checkout page.
The question we’re asking : What separates the web applications people use without thinking from the ones that quietly defeat them?What we’ll see : How a designer who watched real users fail extracted the traits of software that simply works — and why obvious turns out to be the hardest thing to build.
Table of contents
01Chapter 1 — The application that disappears
Hoekman opens with a deceptively plain observation: the best software is the software we forget we are using. Think of the tools that never make us pause — the search box that returns what we wanted, the form that submits without complaint. We don't admire them. We don't even notice them. That invisibility is the achievement. A great web application, in his framing, is one that lets us stay focused on our task instead of on the interface standing between us and it.
This runs against a deep instinct in software, which is to be impressed by what a product can do. Feature lists sell. A long roster of capabilities looks like value, and every stakeholder has a favorite thing they want added. But Hoekman points out that users almost never arrive wanting features. They arrive wanting to finish something — to send the message, book the room, publish the post. The application is a means, never the end, and the moment it starts demanding attention for its own sake, it has begun to fail at the only job that matters.
02Chapter 2 — Only what the work requires
If obviousness has a first commandment in Hoekman's account, it is to build only what's necessary. This sounds like an argument for minimalism, but it's subtler than that. The point isn't to strip things away for the sake of looking clean; it's to refuse the features that don't serve the actual work the user came to do. Necessary is defined by the activity, not by what's technically possible or what a competitor happens to offer.
The enemy here is what he calls feature creep, and the way it sneaks in is rarely dramatic. A request comes from sales. A power user wants an option. An executive saw something in a rival product. Each addition is defensible in isolation, and saying no feels petty or risky. So the application accumulates, layer by layer, until the interface that was supposed to help now has to be navigated. Hoekman's response is to keep returning to the question of who actually needs a given feature, and how often, and whether its presence costs more in clutter than it earns in use.
03Chapter 3 — The first ten minutes decide everything
No matter how clean an application is, a new user arrives knowing nothing about it, and Hoekman devotes serious attention to that first encounter. Getting users up to speed quickly, he argues, is not a nicety bolted on at the end; it's a design problem to solve from the start. The early moments are when people decide whether a tool is worth their effort, and most abandonment happens not because the application is bad but because the on-ramp was too steep.
His preferred answer is rarely a tutorial. Manuals, welcome tours, and walls of instructional text are, in his view, often a confession that the design didn't do its job — if the interface needs explaining, the explaining is patching a leak. The better approach is to make the next step obvious through the design itself: clear defaults, sensible starting states, and visual cues that show people where to go without telling them. An empty screen that explains what to do with it teaches more gently than any pop-up.
04Chapter 4 — Errors are the designer's fault, not the user's
The most quietly radical idea in the book is its stance on mistakes. When a user does something wrong, Hoekman refuses to call it user error. People don't read carefully, don't follow instructions, and act on assumptions — and a good application should expect exactly that. The job of design is to prevent errors before they happen and to handle them gracefully when they slip through, never to blame the person for behaving like a person.
Prevention comes first. If a field only accepts a certain format, the design should make the right format unmistakable rather than waiting to scold. If an action is destructive, it should be harder to trigger by accident. Good defaults, sensible constraints, and confirmations placed only where they truly matter all reduce the chances of a mistake before there's anything to recover from. Hoekman's instinct is to engineer the situation so the wrong move is difficult and the right one is the path of least resistance.
05Conclusion
The application that disappears, the one we use and forget, turns out to be the product of relentless choices — what to leave out, how to greet a stranger, where to catch a fall. Hoekman never pretends any of this is easy. Obvious is the hardest quality to build precisely because it hides its own effort; the better the work, the less anyone notices it was done at all. That is the strange economy of good design: success looks like nothing happened.
