The “Make It Obvious” Toolkit: Defaults, Constraints & Discoverability

Earlier chapters argued that good design feels obvious. This chapter hands you the tools to make that happen. It turns the recurring theme of this guide — every feature must be both good code and good experience for non-technical users — into a concrete checklist you can run against any screen.

The reader to keep in mind is a print-shop owner. They never read a manual. They navigate by intuition. If they have to stop and puzzle out a label, or hunt for a control, or guess what a button does, your design has already failed them. The whole craft below is about removing that puzzling.

The six building blocks (Norman's foundations)

Norman gives us six ideas that sit underneath everything in this chapter. Learn the words; they are the vocabulary of the craft.

Affordance

The actions a thing makes possible. A chair affords sitting; a button affords pressing. It is a relationship between the object and the person, not just a property of the object.

Signifier

A visible cue that tells the user where and how to act. As Norman puts it: affordances say what is possible; signifiers say where the action should happen. A label, an icon, a highlighted field — all signifiers. A field labelled Store Name signifies "type your shop name here." A field labelled tenant identifier signifies nothing to a shopkeeper.

Constraints

Limits that shrink the set of possible actions so the right one stands out and wrong ones become hard or impossible.

Mapping

The relationship between a control and its effect. Good mapping uses natural, spatial logic — like a stove where each knob sits next to the burner it controls. Bad mapping causes the same mistake for a lifetime.

Feedback

Immediate, informative confirmation of what just happened. Norman is blunt: feedback must be both immediate and informative. Delayed or vague feedback is worse than none.

Conceptual model

The mental picture the user builds of how the thing works. Good design makes the system behave the way that picture predicts.

Norman also gives a phrase worth memorising: knowledge in the world versus knowledge in the head. Anything you make visible — a label, a sensible default, a signifier — is "knowledge in the world," and it spares the user from having to remember anything. Steve Krug compressed this entire chapter into one book title: Don't Make Me Think.

Tool 1 — Smart defaults: set what 90% want

A default is the value already filled in before the user touches anything. A smart default is an educated guess at what most people want, so the common case needs zero configuration.

For the print SaaS, this means a new product should arrive pre-set to the choice 90% of owners want: status Active/Published, a sensible default tax class, a common print size, a reasonable starting quantity. The owner can ship without opening a single setting. This is also Hick's Law in action (Hick–Hyman, 1952): decision time grows with the number of choices, so fewer visible choices plus a good default means a faster, more obvious decision.

Tool 2 — Constraints: make bad actions impossible

This maps to Nielsen's heuristic #5, Error Prevention: the best design stops problems before they happen, not just explains them afterward. There are two error types to guard against. A slip is the right intention but the wrong action (a typo). A mistake is the wrong plan. Constraints and good defaults prevent slips; confirmations (next tool) guard against mistakes.

• Use an input mask — a field that shapes input as the user types — for phone numbers, prices, or dates, so an invalid format can't be entered.
• Offer a fixed set of valid choices (a dropdown) instead of free text when only three values are valid.
• If a button can't be used yet, disable it and say why in a tooltip. A greyed-out button with no reason is a dead end.

Tool 3 — Discoverability and placement (mapping)

Nielsen's heuristic #6, Recognition rather than recall, says: make options visible so users never have to remember things from one screen to apply on another. The practical rule is mapping — put a control where its effect lives.

So a setting about a product belongs next to the product, not buried in global Settings just because that's where the code happens to live. Jakob's Law reinforces this: users spend most of their time on other sites, so they expect yours to work like the ones they already know. Reuse familiar patterns; don't invent novel layouts.

Tool 4 — Plain labels (signifiers)

Nielsen's heuristic #2, Match between system and the real world, says speak the user's language, not internal jargon. Every label is a signifier; the wrong word signals nothing.

Tool 5 — Forgiving design for destructive actions

Norman's rule for errors: assume people will do something wrong, make actions reversible, and make irreversible actions hard. The NN/G guidance is precise. When you can, prefer undo over a pre-emptive confirmation — undo lets people work fast and recover. When a confirmation is genuinely needed, make it count, because over-using confirmations trains people to click through blindly ("confirmation fatigue").

For the most dangerous deletes, require a non-standard action. MailChimp makes you type the list name before deleting a mailing list; GitHub makes you type the repository name. This "type-to-confirm" pattern forces real attention. Keep the Delete button far from Save (Fitts's Law: distance and size change how easy a target is to hit — make dangerous ones harder).

Tool 6 — Immediate feedback and human errors

This is Nielsen's heuristic #1, Visibility of system status. Pair it with the Doherty Threshold (IBM, 1982): productivity soars when the system responds in under 400 ms. Below that it feels instant. When you can't be that fast, show a skeleton or optimistic UI so the screen never looks blank — a blank screen reads as "broken."

User action
   |
   v   under ~400ms -> feels instant
[ Save ] --+-- success -> "Saved successfully"
           |
           +-- slow ----> skeleton / spinner (never blank)
           |
           +-- error ---> plain message + recovery action

When something fails, Nielsen's heuristic #9 applies: state the problem in human language, suggest a fix, and preserve the user's typed input so they edit rather than re-start. Avoid blaming words like "invalid" or "illegal." Never show a raw status code, stack trace, "System error," or an untranslated key like message.exportError — a visible dotted key is a missing string and a broken last mile. Postel's Law helps at the input edge: be liberal in what you accept ("UK" = "United Kingdom"), then normalise on the backend.

How you know the 90%, the right place, the right word

None of this is guesswork. Clayton Christensen's milkshake study showed that ~40% of a chain's milkshakes were bought early-morning by solo commuters, ordered to go, as the only purchase — the shake was "hired" to make a dull commute bearable and keep one hand busy. That same chain's afternoon buyers were parents treating kids, who needed a thinner, smaller shake. Same product, two jobs, two right designs. You discover the obvious default by studying the real job, not demographics.

To gather that evidence, use Rob Fitzpatrick's The Mom Test: don't ask "do you like my idea?" (people lie to be kind). Ask about specific past behaviour — "walk me through the last time you set up a product," "how do you do it today." That is how "where would someone who's never used software look for this?" gets a real answer instead of a designer's hunch.

The "Make It Obvious" checklist

Run this against every screen and control. This is the recurring theme of the guide, turned into a list.

• Default set to the 90% choice, and reversible.
• Label is a plain-language signifier — passes "would a shopkeeper understand this?"
• Placement is where the user looks: the setting lives near the thing it affects.
• Constraints make wrong actions hard or impossible; any disabled control says why.
• Destructive actions state the exact consequence; the button restates the verb; undo offered when feasible.
• Feedback is immediate and plain ("Saved successfully," not "200 OK").
• All three states present: loading (skeleton), empty (helpful next action), error (plain message + recovery).
• No raw technical output: no status codes, exception text, untranslated keys, UUIDs, slugs, or engine type names anywhere visible.
• Consistent with existing patterns — no novel one-offs (Jakob's Law, and the Principle of Least Astonishment).

Key takeaways

• Treat user errors as design failures: send the right signals (signifiers), and the right action becomes the obvious one.
• Smart defaults are the highest-leverage tool — set the 90% choice, keep it reversible, and choose it ethically.
• Prevent slips with constraints; guard mistakes with consequence-stating confirmations; prefer undo over endless "Are you sure?"
• Put controls where their effect lives, name them in plain words, and never leak UUIDs, codes, or raw errors to a non-technical owner.
• Feedback must feel instant (under ~400 ms) and every data view needs loading, empty, and error states.
• You learn the obvious default by studying the real job (Christensen) through honest, behaviour-based questions (the Mom Test) — not assumptions.