Week 13: The Design of Everyday Things Ch. 7

Week 13: The Design of Everyday Things Ch. 7

Welcome to Week 13 of A Real, Magical Summer! 

This week we're reading the final chapter 7 of a national bestseller, Don Norman's "The Design of Everyday Things." 

If financially able, you are encouraged to order a physical copy. You can purchase it on ThriftBooks, Amazon, or a local book retailer that may have a cheaper copy onsite.

If you aren't yet able to purchase the book, here are highlights from each chapter to follow along and guide your study.

Don Norman's The Design of Everyday Things

Good design, as Norman frames it, rests on discoverability and understanding, affordances and signifiers that make possible actions visible, constraints and mappings which guide correct use, and feedback plus clear conceptual models to let users predict and evaluate results. This thoroughly material process of perception, action, and iterative refinement maps directly onto “A Real, Magical Summer” where evolution itself is non-teleological design through variation, selection, and environmental feedback, producing living affordances without any external designer. In the same spirit, the project’s physicalist magick is transformance achieved by proof-of-work in art, design, and STEM. When causal mechanisms are made visible and testable, ordinary materials yield reliable, surprising effects without mystification.

Audiobook

 

Chapter 7

What design should do

Norman reduces user-centered design to a few obligations.

Make it easy to determine what actions are possible at any moment.

The object should not require guesswork. Constraints do most of this work: physical ones (a plug that only fits one way), semantic ones (a picture of a flame near the hot control), cultural ones (red means stop), and logical ones (if two burners are left and two knobs are left, those knobs belong to those burners). When constraints are used well, the wrong action is hard or impossible, so the right action becomes obvious.

Make things visible.
Visibility covers three layers at once:

  • the conceptual model (how the system is supposed to work)
  • the alternative actions now available
  • the results of actions already taken

If a control, state, or outcome is hidden, the user must invent a story. That story is often wrong.

Make it easy to evaluate the current state of the system.
Feedback must be immediate, intelligible, and matched to the action. Without it, people repeat commands, abandon tasks, or blame themselves.

Follow natural mappings.
Intentions should line up with the actions required; actions should line up with effects; visible information should line up with how the system is interpreted. Spatial layout and temporal closeness help: the left knob for the left burner, the control next to the thing it changes.

In all: make it easy for the user to tell what to do and what is going on.
That is the chapter’s test. If people need a manual, a ritual, or a lucky guess, the design has already failed.

Norman also reminds the reader that three models must stay aligned: the design model (what the designer intended), the user’s model (what the person constructs), and the system image (what the object actually shows through appearance, behavior, and documentation). The system image is the only channel the designer has. If it is inconsistent, the user’s model will drift.


Seven principles for transforming difficult tasks into simple ones

1. Use knowledge in the world and knowledge in the head.
Put as much as possible in the world — labels, layout, constraints, visible state — so memory load stays low. Knowledge in the head is faster once learned, but it is fragile and takes time to acquire. Good design supports both: newcomers can operate from what they see; experts can internalize and go faster.

2. Simplify the structure of tasks.
Do not dump complexity onto the user. Norman names several tactics:

  • keep the task essentially the same, but add mental aids (checklists, visible cues, reminders)
  • use technology to reveal what was invisible (feedback, progress, relevant state) and hide what is irrelevant
  • automate but keep the task the same (remove busywork without changing the user’s goal)
  • change the nature of the task when technology can recast the problem entirely (the car that no longer needs hand-cranking)

The warning: automation is dangerous when it takes too much control from the user. If the machine acts without a clear model, without reversibility, or without a way for the person to stay in the loop, the person becomes a helpless monitor. Keep the person able to understand, intervene, and recover.

3. Make things visible: bridge the gulfs of execution and evaluation.
The gulf of execution is “How do I do this?” The gulf of evaluation is “What just happened, and is it what I wanted?” Visibility on the doing side shows possible actions and how to perform them. Visibility on the checking side shows results and current state. Together they close the action cycle.

4. Get the mappings right.
Natural mappings beat arbitrary ones. If the relationship between control and effect is spatial, cultural, or analogical, people do not have to memorize it.

5. Exploit the power of constraints, both natural and artificial.
The best interface often feels as if there is only one sensible next step, and it is the right one. Lego-style physical constraints, cultural conventions, and logical layout all shrink the space of error.

6. Design for error.
People will slip and mistake. Treat error as a normal part of dialogue, not as user failure. Make actions reversible. Make irreversible actions hard. Use forcing functions so a dangerous step cannot happen without a deliberate extra act. Let people explore without catastrophe. When something goes wrong, show what was done and how to undo it.

7. When all else fails, standardize.
Some mappings are inherently arbitrary (which side is hot water; QWERTY; which way a light switch goes). Then consistency is the last tool: learn it once, use it everywhere. Standardization only works if it is widespread, stable, and introduced at the right moment. It is a last resort, not a substitute for visibility and natural mapping.


The POET method, mappings, constraints, and Norman’s last jab

“POET” is Norman’s own shorthand for the book’s method: design from human action, not from the machine’s internals. The method keeps circling the same pair: get the mappings right and exploit both natural and artificial constraints. Those two do more to make a system self-explaining than extra features or extra instructions.

The chapter ends with a deliberately un-academic scoreboard. Give mental prizes, even flowers, to people who produce designs that let users know what to do and what is going on. Jeer the rest, and send weeds. The joke is the moral: usability is not a taste. It is whether the object communicates.

 

Back to blog