Why Great Products Feel Obvious: 8 Teardowns

The first time you used a smartphone, did anyone hand you a manual? Probably not. You just touched the screen and it worked. That feeling, the sense that you already know what to do, is one of the most expensive things to build in all of software. And it is almost never an accident.

So let’s pry open eight famous products the way a mechanic opens a clock. For each one, three plain questions: What was the hard problem? What made the solution feel obvious? And which principle explains the magic?

Why this matters

When a product feels hard, people blame themselves first (“I must be doing it wrong”), then quietly leave. You rarely get an angry email. You just get a smaller number.

Here is the trap. “Obvious” is not the absence of complexity. It is complexity that the designer has absorbed, so the user never has to touch it. The hard work did not disappear. Someone else carried it.

Once you can see that move, you can copy it. The same handful of techniques show up in Google, the iPhone, Stripe, and a flat-pack bookshelf. Learn the pattern once and you start spotting it everywhere, including the rough edges in your own work.

The recipe behind every great product

Across every teardown below, the same four-step move keeps appearing. Learn it once, then watch each product perform it.

1. Hide complexity behind a clear mental model. A mental model is the simple picture you hand the user: a blank box means “ask anything,” a sheet of paper means a document, LEGO bricks mean blocks. They picture the model and never the machinery underneath.
2. Choose strong defaults. A default is the choice the product makes for you. Decide what 90% of people want, so almost nobody has to configure anything.
3. Give constant feedback. Every action produces an instant, visible, plain-language response. The user always knows the system heard them.
4. Remove steps and choices. Fewer options means faster decisions. Fewer screens means less to learn.

A few named laws worth knowing

You do not need these to use the recipe, but they give you sharper language for why it works.

• Hick’s Law. The time to make a decision grows with the number of choices. Each extra option adds a little more delay, so short lists like menus and buttons should stay short. Fewer choices, faster decisions.
• Affordance vs signifier (from Don Norman’s The Design of Everyday Things). An affordance is a possible action an object offers (a chair affords sitting). A signifier is the perceivable cue that tells you the affordance is there and how to use it (a label, an arrow, a highlight). The affordance is the possibility; the signifier is the hint. Keep them separate.
• Direct manipulation (Ben Shneiderman). Three properties: you see the object continuously, ideally in its final form; you act with gestures or labelled buttons, not typed commands; and your actions are fast, small, and reversible, with the effect shown instantly.
• Jobs To Be Done (Clayton Christensen). People “hire” a product to do a job. Understand the job, not the feature list.

A quick story for that last one. McDonald’s wanted to sell more milkshakes, so they tried making them tastier. Nothing happened. Then researchers watched buyers and noticed many bought a shake alone, early in the morning, in the car, and drove off. They were “hiring” a thick shake to survive a boring commute. Its real rivals were bananas and bagels, not other milkshakes. Better flavour solved the wrong job entirely.

Eight teardowns

1. Google Search: the blank box

The hard problem: index and rank billions of pages so anyone can find the right one. The obvious solution: a single empty box and one button. The principle: minimalism plus Hick’s Law. With one obvious choice, the decision is instant, and the mental model is simply “type what you want.”

Charmingly, the bare page was partly an accident. Marissa Mayer once asked co-founder Sergey Brin why the page was so empty; he reportedly said they had no webmaster and he did not do HTML. Early testers loaded the page and waited about a minute, so unused to white space that they assumed more was still loading. Google added the bottom copyright line partly as a signal: “the page is done.”

2. The iPhone: touch the thing itself

The hard problem: a pocket computer that is also a phone, an iPod, and the internet, usable with no manual. The obvious solution: touch what you want. Pinch to zoom, swipe to scroll, tap to select. The iPhone shipped with essentially no instruction booklet. The principle: direct manipulation plus strong affordances. A button looks pressable; a list looks scrollable. Steve Jobs called the finger “the most accurate pointing device in the world.” Killing the stylus and the physical keyboard was the bet that let the whole screen become something you touch directly.

3. Stripe: “it just works”

The hard problem: accepting online payments once took weeks of merchant accounts, gateways, and confusing kits. The obvious solution: Stripe’s promise of “payments in seven lines of code.” Copy, paste, done. The principle: developer empathy, expressed as great docs, sane defaults, and fewer steps. Stripe’s documentation is an industry benchmark, with its famous three-column layout: navigation, explanation, and live runnable code side by side. Weeks of setup compressed into a weekend, with clear test-mode feedback the whole way.

The lesson travels beyond code. Stripe treats its documentation as part of the product, not an afterthought. The equivalent for any tool is the in-app guidance a non-technical user reads while setting up. If the help text feels bolted on, the product is harder than it needs to be.

4. Superhuman: hire it to “feel fast”

The hard problem: email is a slow, heavy bottleneck. The obvious solution: a keyboard-driven client that feels instant, plus a real human who onboards you. The principle: Jobs To Be Done. Customers do not hire Superhuman for “more features.” They hire it to feel fast and reach inbox zero.

Founder Rahul Vohra enforces a “100-millisecond rule”: every interaction must respond in under 100ms, the threshold where things feel truly instantaneous. He personally onboarded the first 200 or so users, and the team used a simple survey (“how would you feel if you could no longer use this?”) to raise their “very disappointed” score from 22% to 58% in about a year, by doubling down on what their biggest fans already loved.

5. Linear: opinionated and keyboard-first

The hard problem: issue trackers bloat into slow, infinitely configurable tools, the classic “Jira problem.” The obvious solution: an opinionated tool with one good way to work and a keyboard shortcut for nearly everything. The principle: strong defaults plus removing choices, which is Hick’s Law applied to a whole product. Linear deliberately constrains you with built-in structures like Cycles, Triage, and Backlog instead of letting every team invent fifty custom statuses. Speed is treated as a core feature, not a nice-to-have.

6. Notion: everything is a block

The hard problem: one tool that is docs, wiki, database, and tasks at once, without drowning someone staring at a blank canvas. The obvious solution: “everything is a block.” Type ”/” and snap bricks together. Co-founder Ivan Zhao calls it “LEGO for software.” The principle: one powerful mental model (the block) hiding a flexible engine.

But here is the catch, and it is an important one. Pure flexibility is not automatically friendly. Hand someone a box of LEGO and say “figure it out” and you can overwhelm them just as easily. Notion fixes this with templates and friendly empty states that turn a scary blank page into an obvious next action. Flexibility is only usable when good defaults guide the first step.

7. IKEA: wordless instructions

The hard problem: one assembly manual must work in dozens of languages. The obvious solution: drop words entirely. The stick-figure “IKEA man,” arrows, and numbered pictures show rather than tell. The principle: visual signifiers carry meaning without language. Text would need translating into around 35 versions per update, each one a chance to mistranslate. Wordless gives you a single, cheaper, lower-error artifact. IKEA’s two stated rules are clarity (each step instantly understood) and continuity (a predictable flow from one step to the next).

8. ATM and checkout: convention as obviousness

The hard problem: a stranger must complete a multi-step transaction under stress, with no training. The obvious solution: conventional, standardized flows. Insert card, enter PIN, choose amount, take cash. Or an online checkout with a visible progress bar, one clear primary action per screen, saved address and card defaults, and confirmation at each step. The principle: convention and consistency. Match the user’s existing mental model so the next step is always obvious.

You can feel the difference when it breaks:

  Good checkout (obvious)        Broken checkout (hidden steps)
  [Cart]  ->  [Pay]  -> Done     [Cart] -> [Create account?!]
    |  progress bar shown          |  surprise shipping fee
    |  saved card default          |  no progress shown
    v                              v
  one click, confident          confused, abandons cart

Common misconceptions

• “Simple means less powerful.” No. Google sits on one of the most complex systems ever built, behind one empty box. Simple on the surface and powerful underneath are not in conflict; that gap is the design.
• “Obvious products had less work put in.” The opposite. The cleaner it feels, the more complexity someone quietly absorbed for you.
• “Maximum flexibility is the most user-friendly.” Flexibility without guidance is just a blank page that intimidates. Notion only works because templates and empty states point at the first move.
• “Good help text can be added at the end.” Stripe proves documentation and in-app guidance are part of the product, not a final chore. Treating them as an afterthought makes everything harder to use.

How to make your own product feel obvious

Run the same recipe the giants run, in this order:

1. Name the real job. Before any feature, ask what users are actually “hiring” your product to do. Solve that, not the feature wish-list.
2. Give one clear mental model. Pick a single picture (“this is your store,” “everything is a block”) and make every screen reinforce it.
3. Set strong defaults. Decide what most people want and pre-fill it. A new user should reach a useful result without opening ten settings.
4. Respond instantly, in plain words. After every action, show a clear “Saved” or a visible change. Aim for fast feedback; under ~100ms feels instant.
5. Cut steps and choices. Remove screens, fields, and options until removing one more would break the job. Let people act as a guest before forcing accounts.
6. Design the empty, loading, and error states on purpose. These are where users get stuck. Friendly empty states and clear errors are what make flexibility usable.
7. Never hide cost or steps until the last second. Surprise fees and forced sign-ups add friction at the worst moment and quietly kill conversions.

Conclusion

If you remember one thing, remember the swan. On the surface it glides, calm and effortless. Beneath the water its feet are paddling furiously. The designer’s whole job is to do all the paddling so the user only ever sees the glide.

“Obvious” was never about having a simple product. It was about absorbing the hard parts so completely that the user forgets they were ever hard.

So here is the question that ruins this for you forever, in the best way: the next time something feels effortless, whose effort are you actually feeling? Start watching for the paddling, and you will never look at a checkout, a menu, or a flat-pack manual the same way again.