Closing the Gulfs: Action, Feedback & the Seven Stages

Every time a person uses software, a small drama plays out. They want something. They guess how to get it. They act. Then they wait to see what happened. If any part of that loop is unclear, the software feels confusing, slow, or "broken" — even when the code worked perfectly. This chapter gives you a precise vocabulary for where and why a screen confuses people, and a checklist to fix it.

The vocabulary comes from Don Norman, a cognitive scientist (someone who studies how the mind thinks and learns) who wrote The Design of Everyday Things (1988, revised 2013). Norman later coined the term "user experience." His most useful idea is that bad design opens up two gulfs — wide gaps the user has to leap across.

The two gulfs

Gulf of Execution

The gap between what the user wants to do and what the system lets them do. The question in their head is "How do I work this?" They stare at the screen trying to figure out what actions are even possible. If a shop owner wants to save their store settings but can't find a Save button — or can't tell the form is submittable — that gulf is wide.

Gulf of Evaluation

The gap between what the system did and whether the user can tell what happened. The question is "What happened? Did it work?" They clicked Save, nothing visibly changed, no message appeared — so they have no idea if it saved. A wide gulf here is exactly what makes a UI "feel broken."

"UI" here means user interface — the buttons, fields, and messages a person actually sees and touches. The execution gulf is bridged by making actions visible and obvious. The evaluation gulf is bridged by feedback — telling the user, in plain words, what just happened.

The Seven Stages of Action

Norman breaks the loop above into seven stages. Don't memorise them as a rigid sequence (real action jumps around and is often subconscious). Treat them as a diagnostic checklist: a list of points where a design can fail. We'll walk through them with one concrete task — saving changes to your store settings.

            GOAL  (keep my changes)
              |
   EXECUTION  v              EVALUATION
   2. PLAN                   5. PERCEIVE
   3. SPECIFY                6. INTERPRET
   4. PERFORM   --system-->  7. COMPARE
   (bridge the              (bridge the
    Gulf of Execution)       Gulf of Evaluation)
              \____ repeat or stop ____/

1. Goal — what you want to achieve: "I want to keep my changes." Goals are often vague; the user translates them down into actions.
2. Plan — the approach: "I'll save it."
3. Specify — the concrete steps: "I'll click the Save button" (or press Ctrl+S).
4. Perform — actually do it: move the mouse, click.
5. Perceive — notice what the system now shows: a "Saved successfully" message appears, the little "unsaved changes" dot disappears.
6. Interpret — make sense of it: "green message in plain words = it worked."
7. Compare — check against the goal: "Yes, saved. Done." (Or: "An error — I'll try again.")

Stages 2–4 (plan, specify, perform) bridge the Gulf of Execution. Stages 5–7 (perceive, interpret, compare) bridge the Gulf of Evaluation. Norman frames each stage as a question the user asks: What do I want? What can I do? How do I do it? then What happened? What does it mean? Is this okay?

Feedback: the heart of it all

Feedback is how you close the evaluation gulf. Jakob Nielsen (Norman's NN/g co-founder) makes it his very first usability rule, "Visibility of System Status": the design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time. Without it, users can't tell if an action succeeded, failed, or is still running — so they re-click, or give up.

Good feedback is immediate, plain-language, and proportionate. Immediacy matters more than people expect — delayed feedback is often worse than none, because the user assumes failure and clicks again, sometimes submitting twice.

How fast must feedback be? Three classic thresholds (Robert Miller 1968, restated by Nielsen) tell you when to show a spinner:

Norman's seven principles — your execution-side checklist

If feedback closes the evaluation gulf, these seven principles (from the 2013 edition) close the execution gulf and keep the whole loop honest. Use them as a checklist when reviewing any screen.

1. Discoverability (visibility)

Can the user figure out what's possible and the current state just by looking? Check: is the primary action obviously present and reachable?

2. Feedback

Is every action's result communicated immediately and in plain words? (This is Nielsen's Heuristic #1.)

3. Conceptual model

Does the design project a coherent picture so the user's mental model matches reality? Check: do the labels and structure tell a consistent story a shopkeeper would understand?

4. Affordances

The properties of an object that determine how it could be used — a button affords pressing, a link affords clicking. (Norman refined the term from psychologist James Gibson.)

5. Signifiers

The perceivable cue that an affordance exists — the underline on a link, the raised look of a button. Norman's big 2013 point: worry more about signifiers than affordances. Check: does the clickable thing look clickable?

6. Mappings

The relationship between a control and its effect should be natural — up means more, the control sits next to what it changes. Check: do controls map intuitively to what they alter?

7. Constraints

Limit possible actions to prevent errors — disable or hide what can't be done now, instead of warning after the fact. Check: have you made the wrong action impossible?

Loading, empty, and error: feedback that keeps a screen alive

Any screen that loads data must handle three states. Each one is really feedback about system status — leave one out and the evaluation gulf reopens.

• Loading — show a skeleton (greyed placeholder shapes) or spinner, never a blank page. A blank screen reads as "broken"; uncertainty makes users repeatedly re-check whether it's still loading.
• Empty — never a raw "No data." Give a next action: "You haven't added any products yet — click 'Add Product'." An empty state is an onboarding moment that answers "what do I do now?"
• Error — plain-language message plus a recovery action; never a status code, stack trace, or untranslated text key. State the problem and constructively suggest a fix. The best error, of course, is the one a constraint prevented entirely.

Start from the goal, not the control

The seven stages begin with the goal — and if you misread the goal, you optimise the wrong stage perfectly. Clayton Christensen (Harvard professor, The Innovator's Dilemma) framed this as Jobs-to-Be-Done: customers "hire" a product to do a job. The classic line: people don't want a quarter-inch drill, they want a quarter-inch hole.

For your print SaaS, that means: a store owner's goal isn't "configure the checkout form" — it's "get paid for an order without confusing my customer." Understand that job first. Then narrow the Gulf of Execution (make every action discoverable, with honest signifiers, natural mappings, and guarding constraints) and the Gulf of Evaluation (immediate, plain-language feedback and the three data states). Do both, and the user walks all seven stages without ever noticing the work you did.

Key takeaways

• Two gulfs cause most confusion: Execution ("how do I do this?") and Evaluation ("did it work?"). Good design narrows both.
• The Seven Stages of Action are a diagnostic checklist for where a task breaks — three execution stages, three evaluation stages, around one goal.
• Feedback closes the evaluation gulf: immediate, plain-language, proportionate. "Saved successfully," never "200 OK."
• Use response-time limits (100ms / 1s / 10s) to decide when a spinner or progress bar is required.
• Norman's seven principles (discoverability, feedback, conceptual model, affordances, signifiers, mappings, constraints) are your execution-side review checklist.
• Loading, empty, and error states are feedback — missing any one makes a working screen feel broken. And always start from the user's real job, not the control.