Breakdowns: Objects. Seventeen things you can hold, and what they teach about things you can't.
A radio with a clear lid, a calculator with round keys, a CD player you switch on by pulling a cord, a clock whose second hand waits for the train. Physical products are design under pressure: every part costs money, every control takes space, every mistake ships in a box. This guide takes them apart one decision at a time and carries each decision across into software you can build alone.
Reading timeAbout 4 hours, in 6 sittings (one per part)
Practice time2 weeks, plus one object a week after that
Break down any physical product with a seven-lens method and write it up in one page (analyse).
Explain why each of seventeen classic objects looks and behaves the way it does, including what it costs and what it gave up (understand).
Tell a reason worth copying from a surface worth ignoring, so you translate mechanisms instead of textures (evaluate).
Turn each object's decisions into concrete software patterns: defaults, controls, states, families, budgets (apply).
Run a breakdown on an object from your own desk and ship one change in your own product because of it (create).
Warm-up: how to study objects
You have already met Rams's ten principles, Fukasawa's "without thought" and Kenya Hara's emptiness in the starter guide. Here you stop quoting them and start reading them in the objects themselves. Principles are compressed lessons; objects are the uncompressed source. When you read the source you see the trade-offs the principles hide.
Each product chapter has the same shape, so you can skim or study. A facts box. An annotated drawing with numbered pins. A list of numbered decisions that match the pins, each with why and what it cost. What it left out. Where it falls short. Then "Steal this for your software", a quiz and a short exercise. The drawings are schematic recreations, simplified on purpose: they show structure, not exact proportions. Look up photographs of the real thing as you read; the gap between the drawing and the photo is itself a lesson in what matters.
Study plan: one part per sitting. Keep a notebook (paper or a text file) titled "Steal list". Every time you hit a "Steal this" item that applies to your product, copy it in with today's date. By the end you'll have twenty to forty candidate changes, and the final chapter helps you pick three.
Diagnostic
You admire the Braun T3 pocket radio and want your note-taking app to feel like it. Which first move is most likely to work?
The T3 is great because of a decision (one dominant control, a speaker grid that is also the face, nothing else), not because of its texture or colour. Options a and b copy the surface; d copies the words. Option c copies the reason. This whole guide trains that difference. If you picked a or b, read Translating atoms to bits with extra care.
Diagnostic
A physical product designer has to decide whether to add a second button. A software designer faces the same question. What usually differs?
This is the central idea of the guide. Physical products inherit discipline from cost. Software has no such cost, so the discipline must be chosen. See chapter 2.
Part one
The method
Before seventeen objects, one way of looking. These two chapters give you a repeatable breakdown method and a set of rules for carrying lessons from atoms to bits without dragging along the textures, the nostalgia or the constraints that no longer apply.
1
How to break down a product
Taught by Dieter Rams, with Don Norman and Naoto Fukasawa
A breakdown is not a review. You are not judging whether you like the object; you are reverse-engineering the decisions that made it, and the costs those decisions paid, through seven fixed lenses.
Most people "study" good design by looking at it and feeling something. That feeling is real but it doesn't transfer. You can't open your editor and type "make it feel like a Braun". What transfers is a decision: this radio puts its only frequently-used control under the thumb, and hides the rest. Decisions are portable. Feelings are not.
The trouble is that decisions are invisible once they're made. A finished object looks inevitable, as if it could not have been any other way. Your job in a breakdown is to make it look chosen again. For every feature ask: what were the alternatives, why was this one picked, and what did it cost? If you can't name a cost, you haven't understood the decision yet. Every real decision costs something.
The seven lenses
Look through each lens in order. The order matters: it goes from why the thing exists, to how it looks, to how it's used, to what it's made of, to the small stuff, to its relatives, and finally to the absences, which are the hardest to see.
Seven lenses, then one translation step. Lenses 1 to 6 describe what is there. Lens 7 describes what is not. Only after all seven do you translate, and you translate the reason, never the surface.
1 Purpose
What job does it do, for whom, in what situation? What is the one sentence that, if false, would make the object pointless? (The Kindle: "read books for hours without your eyes or the battery giving up.")
2 Form
Overall shape, proportions, hierarchy of parts. What is biggest? What do you see first? Does the form explain the function, or hide it?
3 Interaction
Every control: where it is, how it moves, what feedback it gives, and whether its current state is visible without touching it. Map the most common task, step by step.
4 Material and medium honesty
Is each material used for what it's good at? Does anything imitate something else (plastic pretending to be wood)? How does it age: does wear make it worse or more personal?
5 Details
Radii, gaps, the click of a switch, the label typeface, the colour of a single key. Details are where care becomes visible, and where cheap shortcuts show.
6 System and family
What is it part of? Siblings in the same line, modules that combine, accessories, refills, the shop it's sold in. Great objects are rarely alone.
7 What was left out
Features competitors had that this lacks. Controls you expected and didn't find. Labels, logos, colours, settings removed. The absences are where the courage is.
Key idea
If you can't name what a decision cost, you haven't understood it yet.
A worked example: the humble wall light switch
Take an object you touch daily and never think about. A good rocker light switch, the large flat kind common in European homes.
Purpose. Turn a room's light on or off, in the dark, with a full hand of shopping, without looking.
Form. A large flat rectangle. The whole face is the control, so the target is huge. (Fitts's law in plastic; see The Human Mind.)
Interaction. Press top or bottom. The rocker's tilt shows state at a glance, and the snap gives sound and touch feedback in under 50 ms.
Material honesty. Matte plastic that hides fingerprints. No fake brass.
Details. Rounded edges, no sharp seam to catch a fingernail. Sometimes a tiny glowing dot so you can find it at night.
System. Same frame for sockets, dimmers and blanks, so a wall of them reads as one family.
Left out. No label, no screen, no app, no "are you sure?". Costs: no scheduling, no remote control. Most people never miss them.
Now translate: the most-used action in your product should be a large target, show its state at rest, respond instantly, and ask nothing. That's one sentence of design direction, earned from a light switch.
Don't
A review, not a breakdown. Feelings and adjectives. Nothing you can act on in your code tomorrow.
Do
A breakdown. Decision, alternatives, reason, cost, translation. Five lines you can act on.
Lab: the lens explorer
Braun SK 4 · Purpose
Ask: what job, for whom, where?
Play records and radio in a modern living room, as a piece of equipment rather than a piece of furniture.
Translate: decide whether your app is an instrument or a decoration. Instruments get out of the way.
Pick an object, then step through the lenses in order. Notice that lens 7 usually produces the most useful translation, and that the same lens gives very different answers for different objects.
The one-page breakdown template
Use this every time. One page, never more: the limit forces you to rank. Fill it in pencil or in a text file. Keep every one you write; after ten you'll have a personal pattern library no course can give you.
Checklist: one-page breakdown
Before
The lenses
Decisions and translation
Do
Handle or use the object, or watch someone use it on video, before you write.
Write every decision as "chose X over Y because Z, at the cost of W".
Spend the most time on lens 7; absences are invisible unless you hunt for them.
Include one honest criticism. Reverence makes you a fan, not a designer.
Keep a fixed template so breakdowns compare across objects.
Don't
Describe colours and finishes and call it analysis.
Assume every feature was intentional. Some are cost-cutting or factory limits; say so when you suspect it.
Stop at the object. A breakdown without a translation is trivia.
Pick only famous "design classics". A good kettle or a bus ticket machine teaches as much.
In the wild
Rams's ten principlesDieter Rams, formulated late 1970s to 1980s
Rams wrote his principles after decades of designing, as a summary of what his objects had already done. They are the output of breakdowns, not the input. Principles come from studying decisions; study the decisions and you'll write your own.
The Design of Everyday ThingsDon Norman, 1988 (revised 2013)
Norman's doors, stoves and taps are breakdowns of ordinary objects, each ending in a general idea (affordances, signifiers, mapping, feedback). Ordinary objects are as instructive as famous ones.
Teardown sites like iFixitFounded 2003
Hardware teardowns photograph every screw and score repairability. They're "lens 4 and 6" breakdowns: material and system. A narrow lens, applied consistently across many products, becomes a powerful comparison tool.
For the solo creator
You don't have a design team to critique with, so breakdowns are your critique partner. One object a week, one page each, twenty minutes. Do it on the same day as your weekly review (see The Solo Practice) and you'll find a steady stream of small, specific improvements instead of waiting for inspiration.
Common mistakes
Admiring instead of analysing
Beautiful objects trigger a pleasant feeling, and it's easy to write that feeling down as if it were insight.
Ban adjectives in the first draft. Every sentence must name a part, a decision, or a cost.
Skipping lens 7
You can't see what isn't there, so you list only what's present.
Put a competitor next to the object (an ordinary calculator next to the ET 66) and list the differences. Most of them will be absences.
Translating literally
The easiest translation is visual: copy the colour, the radius, the dial.
Translate the mechanism. The next chapter is all about this.
Check yourself
You're breaking down a popular electric kettle. You've written: "Sleek matte finish, nice blue light, very premium." What's the best next step?
The first draft is a review. Option d turns the blue light into a decision with a reason and a cost, which translates directly (show state only while it matters). Comparisons (c) help with lens 7 later, but first you need decisions.
Exercise 1.1 25 minutes · an object within reach
Your first one-page breakdown
Pick an everyday object within arm's reach: a pen, a stapler, a tap, a remote.
Use it for its real job twice, slowly.
Fill the seven lenses, one or two lines each.
Write five numbered decisions in the form "chose X over Y because Z, at the cost of W".
Translate two decisions into one-sentence directions for your own product.
You're done when: you have one page with seven lenses, five decisions with costs, and two software directions.
Beginner
Competent
Strong
Mostly description; costs missing.
Five real decisions with costs; translations are general ("keep it simple").
Decisions include at least two absences; translations name a specific screen or control in your app.
2
Translating atoms to bits
Taught by Dieter Rams, with Bret Victor and Kenya Hara
Physical products get their discipline for free, from cost, space, weight and physics. Software has none of those limits, so you must translate the reasons a physical decision was made, and then impose the discipline yourself.
A Braun radio couldn't have forty buttons: each one meant a hole in the case, a switch, wiring, assembly time, and a few more pfennigs on every unit sold. A pocket radio couldn't be bigger than a pocket. A Game Boy had to run on four AA batteries for a whole car journey. The designers often turned these limits into virtues, but the limits came first.
Your app can have forty buttons for free. It can be any size, any colour, any number of screens. Adding a setting takes ten minutes. That freedom is why so much software sprawls. Nothing pushes back.
So when you study an object, separate three things: the surface (colour, texture, shape), the constraint (what physics or cost forced), and the reason (the human need the decision served). Translate the reason. Recreate the constraint on purpose when it helped. Leave the surface behind.
Three layers, three treatments. Leave the surface, choose which constraints to re-impose as budgets, and translate the reason into a software pattern.
Four kinds of translation
Direct. The idea works the same way on screen. The ET 66's colour-coded keys become a calculator app's coloured operator column. The Swiss clock's single red accent becomes one accent colour in your UI.
Metaphorical. The behaviour transfers, not the mechanism. MUJI's pull cord doesn't become a drawn cord on screen; it becomes "the main action happens with one obvious gesture and no menu".
Constraint transfer. A physical limit becomes a self-imposed budget. The Game Boy's battery life becomes a performance budget (load in under one second, run on a five-year-old phone). The 606's fixed rail spacing becomes a spacing scale.
Anti-translation. Some lessons tell you what not to bring across. A physical shutter dial is great because fingers find it without looking; a drawn dial on a touch screen loses that, and is often worse than a plain list.
Don't
The costume. A drawn knob is hard to turn with a finger, gives no physical detent, and hides the station list. It copies the surface and loses the reason.
Do
The reason. One dominant control, state you can read at a glance, and a fast list. Radio-like behaviour, screen-native form.
Copy the look vs copy the reason: a "MUJI CD player" app
Player
Drag the cord down 120 px to play
Repeat
Shuffle
EqualiserFlat ›
Bill Evans · Waltz for Debby
❚❚
Started playing when you opened the app
Up nextMy Foolish Heart
Copy the look: a drawn cord you must drag a long way, plus the usual settings. It imitates Fukasawa's object and misses his point, which was that you don't have to think.
Copy the reason: opening the app is the pull. Music resumes where you left it, one control to stop it. That's "without thought" on a phone.
The constraint budget
Because software won't push back, write your own constraints down and treat them as physics. Examples that work for a solo product: at most five user-facing settings; one accent colour; first screen usable with no account; page weight under 200 KB; cold start under one second on a mid-range Android phone; any action undoable for 10 seconds. These are your "price per button". Breaking one should feel as expensive as adding a part to a production run.
Physical constraint
What it forced
Software budget you can choose
Each button costs money on every unit
Few controls, each justified
A hard cap on settings and toolbar items
Battery life
Low-power displays, simple chips
Performance and data budgets; works offline
Pocket size
Prioritised layout, one main control
Design mobile-first at 360 px wide
Tooling cost of a new mould
Shared parts across a product family
A small component library reused everywhere
It has to survive being dropped
Robust, forgiving construction
Undo, autosave, no destructive one-tap actions
Myth
"Flat design killed skeuomorphism, so physical objects have nothing to teach screens." Flat design rejected fake textures, which were surface. The reasons behind good physical objects (clear state, direct mapping, few controls, honest materials) are exactly what good flat design needed and often forgot. Many flat apps hide state and affordances that a 1958 radio showed plainly.
Do
Write each lesson in the form "because people need X, the object does Y; in software, Z".
Turn helpful physical limits into written budgets.
Ask which physical advantages your medium lacks (touch, detents, no-look use) and compensate.
Use screen-native strengths: search, undo, sync, instant change.
Don't
Draw knobs, cords, leather and wood to signal "quality".
Assume a physical control maps well to touch; most rotary gestures are awkward on glass.
Copy a limit that no longer serves anyone (a fixed small capacity, a one-colour screen) just for nostalgia.
In the wild
iOS 7Apple, 2013
Removed the leather, felt and linen of earlier iOS apps and kept layered depth and motion to show structure. Drop the costume, keep the information the costume was carrying (hierarchy, state).
Halide camera appLux, 2017
Takes cues from manual cameras (exposure and focus as direct, visible controls) but uses swipe gestures fitted to a phone rather than drawn dials. Translate the behaviour of a camera, not its chrome.
Teenage Engineering's OP-1 field and its software2022
Even a hardware company's on-screen graphics are flat, playful diagrams, not drawings of the hardware. The screen speaks in its own language.
For the solo creator
Put your constraint budget in the README of your project, right under the product's one-sentence purpose. When you are tempted to add a setting at midnight, you'll have to edit the budget first, in writing. That small friction is the closest thing you have to a factory's cost accountant.
Common mistakes
Skeuomorphic homage
You love an object, so you draw it. It feels like respect.
Ask what the object's form was for. Draw the function, not the object: a big target, a visible state, an instant response.
Importing scarcity
Old objects were limited, and limits look like purity.
Keep only limits that serve the user now. A 5 GB iPod was a limit of 2001; "one library, one control" is the lesson.
Forgetting what touch screens lack
Screens can show anything, so you assume they can do anything.
Physical controls give detents, resistance, no-look use. Compensate with large targets, haptics where available, and keyboard shortcuts.
Check yourself
You're building a timer app inspired by the Braun AB 1 alarm clock. Which translation keeps the reason and drops the surface?
The clock's reasons are legibility and a single accent for the moving part. Option a keeps both in screen-native form. b copies surface, c copies a constraint that no longer helps, d borrows someone else's identity (and is a trademark problem).
Check yourself
Which is a "constraint transfer" rather than a direct or metaphorical translation?
Constraint transfer turns a physical limit into a chosen budget. a is direct, b is metaphorical, d is the anti-translation to avoid.
Exercise 2.1 30 minutes · on your own product
Write your constraint budget
List every place your product could grow without limit: settings, toolbar items, colours, fonts, screens, page weight, startup time, notifications.
For each, write a number you will not exceed. Pick numbers that hurt slightly.
Next to each, name the physical object that inspired it (a radio with three controls, a clock with one accent colour).
Check your current product against the budget. Mark every breach.
You're done when: your README has a "Budget" section with at least six numeric limits, and you've listed current breaches.
Beginner
Competent
Strong
Vague limits ("not too many settings").
Six numeric limits, checked against the product.
Limits with reasons, breaches listed with a plan, and one breach already fixed.
Part two
Braun and the Rams school
Between the mid-1950s and the mid-1990s, Braun's design department under Dieter Rams, with Hans Gugelot and the Ulm school early on and Dietrich Lubs later, made radios, calculators, clocks and shelving that still define "good design" for most software designers. Five objects, five lessons: show what's inside, let one control dominate, code by colour, design a system not a thing, and spend your single accent where it matters.
3
Braun SK 4: the radio with nothing to hide
Taught by Dieter Rams and Hans Gugelot
A radio-phonograph that stopped pretending to be furniture. White metal, light wood ends, and a clear lid, so you could see the machine for what it was and the record you were playing.
In 1956 most radiograms in German living rooms were polished wooden cabinets with cloth grilles and brass trim: furniture that happened to contain electronics. The SK 4 put a turntable and a radio in a plain white steel body with wooden end panels, laid every control out on the top plate, and covered the top with transparent acrylic. People called it Schneewittchensarg, Snow White's coffin. It was meant as mockery. It became a compliment.
MakerBraun, Germany
DesignersDieter Rams, Hans Gugelot (HfG Ulm)
Year1956
CategoryRadio-phonograph combination
Study it forTransparency, honesty, appliance over ornament
Everything on the top plate. Turntable left, radio dial and controls right, a clear lid over both. Pins match the decisions below.
A clear acrylic lid instead of a wooden or metal one. You see the record, the arm and the dial with the lid closed: the machine explains itself. The usual account is that a metal lid was tried and rattled, and transparent acrylic solved the problem while showing the insides. Cost: acrylic scratches and shows dust, and the coffin jokes. Clear dust covers later became standard on turntables, which is the best evidence the decision was right.
A white-painted metal body, not a veneered cabinet. It reads as equipment, closer to a laboratory instrument than a sideboard. Cost: to many buyers in 1956 it looked cold and unfinished. Braun accepted a smaller market for a clearer identity.
Light wood only at the ends. The one warm material sits where hands touch and where the object meets the room. It isn't decoration; it's the structural end of the box. Cost: two materials to source and join, but the warmth made the white bearable at home.
Every control in one field on the top plate. Knobs and keys line up in a grid beside the turntable, where your eyes already are when you put on a record. Nothing on the sides, nothing hidden. Cost: you must open the lid to change station.
A slotted metal speaker front instead of cloth. The slots are the speaker's honest opening, cut into the same material as the body. Cost: less forgiving of dents than fabric; the pattern must be precise because it is the whole face.
Small, plain labels. Short words in a clean sans-serif, no logos competing with function. The type supports the controls instead of announcing the brand.
What it left out
Gloss veneer, brass trim, cloth grilles, curved "radio cabinet" shapes, a large logo, legs. Most importantly it left out disguise: the assumption that technology in the home should look like something else. That single absence is the reason the object still matters.
Limits and criticism
It was a combination unit with a built-in speaker, so sound quality was bounded by the box, and Braun's own later hi-fi went modular (separate amplifier, tuner, speakers). It was a product for a modernist minority; many households kept their walnut radiograms. And "honest" is not the same as "warm": the SK 4 needed those wooden ends to be livable.
Don't
A closed lid. The work is invisible; status hides behind an overflow menu. People can't tell whether to wait or worry.
Do
A clear lid. The content shows while it works, with a quiet, specific status. The machine explains itself.
Steal this for your software
Show the work through a clear lid. Let people see the real content while processing happens: rows appearing as they import, a document that shows its saved state, a sync count rather than a spinner.
Look like a tool, not a decoration. Neutral ground, content in front, chrome minimal. Your UI is the white steel; the user's content is the record.
One warm material. In a neutral interface, choose one place for warmth (a serif for reading text, a single accent, a friendly empty state) and put it where people touch most.
One control field. Put all controls for a task in one place near the content they affect, not scattered across toolbars, menus and side panels.
Expect the coffin jokes. When something honest looks unusual, early mockery is normal. Judge by whether people keep using it.
Do
Expose state and progress in the content area itself.
Keep controls together beside what they change.
Use plain labels in your interface typeface.
Don't
Hide your product's real nature behind ornamental chrome.
Scatter one task's controls across three regions.
Let branding compete with function in the working view.
In the wild (software with a clear lid)
iA WriterInformation Architects, 2010
The document is the interface; formatting is visible as plain Markdown characters rather than hidden behind a toolbar. Show the material, not a disguise of it.
Stripe DashboardStripe
Lets developers see the API requests and responses behind payments in its logs. Transparency is a feature for people who must trust the machine.
Git clients like Fork or Tower2010s
Show the diff, the branch graph and the staged state on one screen. One control field next to the material it changes.
For the solo creator
Transparency is cheap to build and saves you support email. A visible "Saved 3 seconds ago", an import that shows rows arriving, an error that names the line: each is a few lines of code, and each removes a class of "is it broken?" messages you'd otherwise answer yourself.
Common mistakes
Transparency as clutter
"Show the work" gets read as "show everything": logs, IDs and timestamps on every row.
The SK 4 shows the record and the dial, not the wiring. Show what the user cares about (their content, progress, result); hide internals behind a details view.
Cold minimalism
You strip all warmth in pursuit of purity.
Keep one warm element where hands touch, like the wooden ends.
Check yourself
Your photo-backup app shows a single spinner for minutes during the first upload. Applying the SK 4 lesson, what do you do?
The clear lid shows the real material (your photos) and a plain state. a is still a closed lid with nicer paint; c is the wiring, not the record; d hides a long process people want to monitor.
Exercise 3.1 30 minutes · on your own product
Find your closed lids
List every place your product does work the user can't see: saving, syncing, importing, generating, sending.
For each, write what the user sees now and what they're wondering at that moment.
Redesign one so the content itself shows progress, with a specific status line.
You're done when: you have a list of hidden processes and one redesigned (sketch or code) where content shows its own progress.
Beginner
Competent
Strong
Spinner replaced with a progress bar.
Content appears progressively, with a specific count.
Also handles failure in place (the failed item shows why and offers retry).
4
Braun T3: one control, one face
Taught by Dieter Rams, with Jony Ive as a later student of the object
A pocket transistor radio whose whole front is two things: a grid of speaker holes and a big round tuning disc. The control you use most is the biggest thing on the face, and nothing competes with it.
Transistors made radios small enough to carry in the late 1950s. Most pocket radios of the time borrowed the look of their big cousins: chrome trim, little dials, logos. The T3 reduced the face to a rectangle of perforations and a disc under your thumb. More than forty years later, people placing it next to a first-generation iPod saw an obvious family resemblance: a grid-like or plain upper area and a large circular control below.
MakerBraun
DesignerDieter Rams
Year1958
CategoryPocket transistor radio
Study it forControl hierarchy, form follows the main task
Two zones, one hierarchy. Listening on one side, tuning on the other. The iPod drawing is there to show the resemblance in hierarchy, not to claim a copy.
The speaker grid is the face. Instead of hiding the speaker behind a decorative grille, a regular field of holes makes the sound's exit the main visual pattern. Cost: the hole pattern must be precise and evenly spaced, or the whole face looks wrong.
The tuning disc is the biggest control. Tuning was what you did most, so it got a large wheel under the thumb, readable at a glance. Cost: less room for anything else, which was the point.
The scale is on the control itself. Numbers on the disc rotate past a fixed mark, so the control and its display are one object. No separate pointer and window to align in your head (Norman would call this good mapping).
A pocket-shaped body with soft corners. Sized and rounded for a hand and a pocket rather than a shelf. Cost: a small speaker with limited sound, accepted as the price of portability.
Nothing else on the front. Secondary functions stay out of the face. The front shows only what the listener needs while listening and tuning.
What it left out
Chrome bezels, a large logo, multiple small knobs of equal size, decorative typography, a carrying handle that would add bulk. It also left out the idea that a radio must look like a miniature of a bigger radio.
Limits and criticism
A single-band pocket radio with a small speaker. The rotating disc is lovely for slow browsing but slow if you know exactly what frequency you want, the same tension the iPod's wheel would face with large libraries. A big, single control is only right when one task really dominates.
Don't
Equal weight everywhere. When every control is the same size, people must read them all to find the one they need every time.
Do
One dominant control. Content up top, the main action biggest, the rest small and out of the way.
Steal this for your software
Size by frequency. Rank your actions by how often they're used. The top one gets the largest target and the best position (thumb zone on mobile). Everything else steps down.
Put the display on the control. A slider that shows its value on the thumb, a segmented control that shows the current state, a date picker that shows the date. Don't make people match a control to a distant readout.
Let the necessary part be the pattern. In a reading app, the text is the decoration. In a dashboard, the data is. Don't add ornament on top of the thing that already fills the space.
Keep the face for the main mode. Secondary functions go behind one tap. The first screen shows only what someone needs while doing the main job.
Do
Draw a frequency ranking of your actions before you draw a layout.
Merge control and readout wherever you can.
Test the main action one-handed on a phone.
Don't
Give secondary actions the same visual weight as the primary.
Use a single big control when there are really two equally frequent jobs.
Copy a circular wheel onto a touch screen because a famous object had one.
In the wild
Apple iPodApple, 2001
A screen above and one large round control below; Jony Ive later wrote the foreword to Sophie Lovell's 2011 book on Rams. The lineage is about hierarchy, not about circles.
ShazamShazam, 2008 on iPhone
For years, the main screen was dominated by one huge button to identify a song. When one job dominates, let one control dominate.
OvercastMarco Arment, 2014
The now-playing screen gives play/pause and skip the biggest targets; less frequent options sit smaller. Size by frequency.
For the solo creator
You don't need analytics to rank actions. Watch three people use your product for ten minutes each, tally which controls they touch, and redesign the hierarchy from the tally. One afternoon's work, often a bigger improvement than a week of new features.
Common mistakes
Democracy of buttons
Every feature cost you effort, so every feature feels like it deserves equal space.
Your effort is not the user's frequency. Rank by use, not by build time.
The wrong dominant control
You make your favourite feature big, not the most used one.
Check with real use. Sometimes the boring action (search, add) is the one that deserves the T3 disc.
Detached readouts
Settings show state in one place and controls in another, like a value shown above a plain slider.
Put the value on or beside the control, updated live.
Check yourself
Your habit-tracker's home screen shows six habits, each with "Edit", "Stats", "Share" and "Done" buttons of equal size. What's the T3 move?
Marking done is the job people do daily; the rest is occasional. c sizes by frequency and clears the face. a and b keep equal weight, d copies a surface.
Exercise 4.1 40 minutes · on your own product
Frequency map and redesign
List every action on your main screen.
Estimate (or tally from three sessions) how often each is used per session.
Sketch the screen where size and position follow that ranking: one dominant control, two or three secondary, the rest one level deeper.
Merge at least one control with its readout.
You're done when: you have a ranked action list and a before/after sketch of your main screen.
Beginner
Competent
Strong
Ranking done; layout unchanged.
Layout follows ranking; one dominant control.
Ranking from observed use; secondary actions moved; a control and readout merged; shipped.
5
Braun ET 66: colour as a map
Taught by Dietrich Lubs and Dieter Rams
A pocket calculator whose keys are round, slightly domed, and coloured by job: numbers in one tone, operations in another, and a single accent for the key that finishes the sum. You can read the keyboard's structure before you read a single label.
By the 1980s calculators were cheap, everywhere and mostly ugly: flat rubber keys, every key the same, labels crowded into the plastic. The ET 66 continued a line Braun had started with the ET 22 and ET 33 in the 1970s and refined it into a small, dark, quiet object. Its colour coding is so legible that the layout became one of the most imitated in software.
MakerBraun
DesignersDietrich Lubs, Dieter Rams
Year1987
CategoryPocket calculator
Study it forColour coding by function, touchable affordance, a later software homage
Three tones and one accent. Read the drawing from a distance: you see a block of numbers, a column of operations, a top row of functions and one bright key, before any label. The pin numbers match the decisions.
A quiet display, set back. A plain digit window at the top, nothing around it but the dark body. The answer is the only thing to read. Cost: no second line of history, which software calculators later added.
Round, convex keys. Each key is a small dome. The shape says "press me" to the fingertip, centres the finger, and makes adjacent keys feel separate even without looking. Cost: more complex moulding than flat keys, and fewer keys fit.
Function keys in their own tone. Clear, percent and similar keys share a colour distinct from numbers, so the "dangerous" or unusual keys look different from the ones you press all the time.
Operations in a column, in their own colour. The arithmetic keys line up on the right edge in one tone. Your eye learns "verbs on the right, nouns in the middle". The grouping does the work a label would otherwise do.
One accent key. The equals key carries the only bright colour, marking the action that completes the task. A single accent is strong because it's alone. Cost: once used here, the colour can't be spent anywhere else on the object.
A strict grid. Equal spacing and alignment so the colours read as regions, not as a random pattern. Colour coding only works on a disciplined layout.
What it left out
Scientific functions, a second display line, a solar panel strip across the face, printed brand slogans, and the visual noise of every key competing equally. It also left out multiple accent colours: the restraint is what makes the one accent mean something.
Limits and criticism
Colour coding by tone alone is fragile: in poor light, or for people with low contrast sensitivity, a dark key on a dark body can disappear. The labels are small. And a homage can become a trap: by the 2010s, colour-coded round keys became a "Braun look" applied to apps where the grouping itself was not clear.
Colour as a map: try both calculators
0
0
Uniform keys: work out 12.5 × 8 − 3. Notice you have to read each label to find the operations and the clear key. Errors (hitting C when you wanted ÷) are easy.
Coded keys: do the same sum. Numbers are dark, operations mid-grey, clear is red, equals is the single accent. Your hand finds regions before your eyes read labels. Colour here supports shape and position; it never works alone.
Steal this for your software
Colour by role, not by whim. Pick three or four roles (content, action, destructive, primary) and give each a fixed treatment across the product. Never colour something "to make it pop".
Spend one accent. Reserve your brightest colour for the single action that completes a task (Save, Send, Done). If everything is accented, nothing is.
Group before you colour. Colour coding only works on a clean layout. Align actions into regions first, then reinforce the regions with tone.
Always back colour with a second cue. Position, shape, label or icon, so the map still works for colour-blind users and in dark mode (see Accessible & Inclusive).
Make tap targets feel pressable. Screens can't dome a key, but clear shape, generous size (44 pt or 48 dp minimum) and an instant pressed state do the same job.
Do
Write down your colour roles as tokens before designing screens.
Test your UI in greyscale; the structure should survive.
Give destructive actions a distinct role and a distinct position.
Don't
Use three accent colours on one screen.
Rely on colour alone to tell keys or states apart.
Copy the orange-operator calculator look onto a screen that isn't a keypad.
In the wild
iPhone CalculatorApple, since 2007
Round keys, a dark ground, numbers in one tone and the operators in a single orange column. Widely described as a homage to the ET 66. The homage works because the grouping logic came along, not only the look.
GitHub's merge buttonGitHub
The green merge action stands out as the completion step; destructive branch deletion uses a different, red treatment. Roles get colours, and the colours stay put.
Things 3Cultured Code, 2017
A mostly neutral interface where colour is used sparingly for meaning (for example the yellow star for Today, blue for the add button). Scarce colour carries meaning.
For the solo creator
Define four colour tokens today: --ink, --muted, --accent, --danger. Ban every other colour from your components for a month. It's the cheapest way to get ET 66 discipline, and it makes dark mode almost free (see Systems & Platforms).
Common mistakes
Accent inflation
Each new feature wants to be noticed, so it gets the accent colour.
One accent per screen, on the completing action. Everything else earns attention through position or size.
Colour without grouping
You colour buttons by category but scatter them around the screen.
Group first. A colour region needs to be a region.
Low-contrast elegance
Dark keys on dark bodies look refined in a portfolio.
Check contrast (at least 3:1 for UI components) and test in sunlight.
Check yourself
Your invoicing app's editor uses blue for "Save draft", blue for "Send", blue for "Add line", and red for "Delete line". People sometimes send invoices by accident. What would Lubs do?
Three equal blue buttons mean the accent maps to nothing. d assigns roles: neutral actions, one completing accent, one danger role, plus position. a confuses danger with importance, b treats the symptom, c removes the map entirely.
Exercise 5.1 45 minutes · on your own product
Colour-role audit
Screenshot your three main screens.
List every colour used on interactive elements and what it currently means.
Collapse them into at most four roles. Reassign every element.
Convert the screenshots to greyscale and check that the structure still reads.
You're done when: you have a role table (colour, role, where used) and one screen restyled to it.
Beginner
Competent
Strong
Colours listed.
Four roles defined and applied to one screen.
Roles are tokens in code, applied product-wide, greyscale test passes, contrast checked.
6
Vitsœ 606 and the Braun TP 1: design the system, not the thing
Taught by Dieter Rams, with Niels Vitsœ
A shelving system of aluminium wall rails, pins and shelves that you can extend, rearrange and move house with, using parts that still fit decades later. The product isn't a shelf. It's a set of rules that make shelves.
Rams designed the 606 Universal Shelving System for the furniture company Vitsœ (originally Vitsœ + Zapf) in 1960, and it is still made today, now in the UK. Parts made decades apart are designed to work together, so owners add to it over a lifetime instead of replacing it. The year before, Rams's TP 1 for Braun had shown the same thinking at pocket scale: a small T 4 pocket radio and a portable record player that could be combined into one unit or used apart.
Study it forModularity, backward compatibility, longevity, repair
Rails, pins, shelves, cabinets. A small vocabulary of parts and one fixed spacing rule generate any configuration. Schematic; real hardware details differ.
A wall rail as the foundation. The structure lives in slim aluminium tracks fixed to the wall, so the furniture has no heavy sides or legs. Everything else hangs from it. Cost: needs a wall you can drill, and careful installation.
A fixed hole pitch as the "grammar". Holes at a regular spacing let any shelf go at any height. The spacing is the interface between parts, and it hasn't been changed. Cost: you can't fine-tune to the millimetre; you live on the grid.
Few part types. Shelves, cabinets, desks and a few accessories. A small vocabulary keeps manufacture simple and keeps combinations predictable.
Backward compatibility as a promise. New parts fit old systems. Owners extend instead of replace, and the company sells to the same customer for decades. Cost: the company can never "redesign" the interface; innovation must happen within it.
Plain, neutral finishes. The system disappears behind the books and objects on it, and doesn't date as fashions change.
Designed to be moved and reconfigured. The shelves come down and go up again in a new home, with a new layout. Vitsœ has long offered planning help and buys back or resells used systems. The relationship continues after the sale.
Composable devices. Each half works on its own; together they become a portable music system. Schematic; the real unit is slimmer.
What they left out
The 606 left out fixed sizes, matching "sets", and the idea of a finished piece of furniture. There's no "complete" state; it is always ready for the next change. Both objects left out planned obsolescence: nothing about them invites you to replace the whole thing.
Limits and criticism
Systems ask more of the buyer: you have to plan. The 606 is expensive compared with flat-pack shelving, and the fixed grid will occasionally fight an odd wall. Backward compatibility also locks the maker in; every new part inherits decisions from 1960. That's a feature for owners and a constraint for designers.
Don't
Furniture, not a system. Every screen is a one-off piece. Adding a feature means designing new parts that don't fit the old ones.
Do
Rails and shelves. A small set of parts on one spacing scale. New screens are new arrangements, not new furniture.
Steal this for your software
Define your "hole pitch". One spacing unit (4 or 8 px) and a short scale built from it. Every margin and gap lands on it, so any component sits next to any other.
A small vocabulary of parts. A dozen components, not a hundred. New features are arrangements of existing parts first, new parts only when unavoidable.
Backward compatibility as respect. Old documents open, old URLs work, export formats stay readable, keyboard shortcuts don't move. Every break costs your users their investment.
Composable features. Like the TP 1, let pieces work alone and better together: a share sheet extension, a CLI next to the app, an API that powers integrations.
Keep the relationship after the "sale". Changelogs, migration paths and import tools are your planning service and buy-back scheme.
Do
Write down your data formats and URL structures as promises.
Design new features with existing components before drawing new ones.
Make export and import first-class.
Don't
Redesign the interface between parts every year.
Ship a "v2" that orphans v1 data.
Confuse a system with a style guide; the 606 is defined by how parts connect, not by how they look.
In the wild
Plain text and Markdown filesMarkdown by John Gruber, 2004
Apps like iA Writer and Obsidian store notes as plain files, so your notes outlive the app. An open, stable format is your wall rail.
The web platform1990s to today
Browsers still render pages written decades ago. "Don't break the web" is a backward-compatibility promise at planetary scale. Longevity is a design decision you keep making.
Unix command-line tools1970s onward
Small programs that each do one job and combine through text streams. A small vocabulary plus a shared interface generates endless configurations.
For the solo creator
Systems thinking is how one person keeps a product coherent for years. The 606 has survived because the rail is fixed and everything else is free. Decide your rails now (spacing scale, component set, data format, URL scheme) and you can change almost anything else later without a rewrite. See Systems & Platforms for building a design system for one.
Common mistakes
The one-off screen
Each new screen is designed from scratch because it feels faster.
Build new screens from existing parts; add a new part only when three screens need it.
Breaking the rail
A redesign changes the data format or URLs because the new structure is cleaner.
Migrate silently, keep redirects, read old formats forever. Cleanliness is not worth your users' trust.
Over-systematising too early
You build a hundred-component library for a product with three screens.
The 606 started with a few parts. Start with spacing, type and five components; grow from real need.
Check yourself
You want to restructure your note app's storage from a single JSON blob into a database. What's the 606 way to ship it?
The 606 changes and grows constantly, but the interface between parts stays fixed. a changes the internals and keeps the promises. b and c push your redesign cost onto users. d confuses compatibility with standing still.
Exercise 6.1 40 minutes · on your own product
Name your rails
List the things in your product that, if changed, would break users' habits or data: formats, URLs, shortcuts, spacing, core components.
Mark which are already stable and which drift.
Write a "promises" section in your README: what you'll never break and how you'll migrate when you must.
Pick one drifting element (for example spacing) and lock it to a scale this week.
You're done when: your README lists your rails as promises, and one drifting element is now on a fixed scale.
Beginner
Competent
Strong
List of rails exists.
Promises written; one element locked.
Spacing, components and data format all documented; an automated check (lint, test) guards one of them.
7
Braun clocks and watches: one accent, perfect legibility
Taught by Dietrich Lubs, with Dieter Rams
A small travel alarm clock (the AB series, and later the AW wristwatches) that you can read in a half-second from across a dark room: high-contrast face, clear sans-serif numerals, and a single yellow accent on the hand that matters most.
Dietrich Lubs joined Braun in the early 1960s and became responsible for much of its clock, watch and calculator work. The alarm clocks he designed with Rams in the 1970s and 1980s, including the AB 1, and the AW 10 wristwatch of 1989, share a recognisable language: matte black or white case, a face with nothing extra, careful numerals, and one warm colour. Braun still makes clocks in this language today, which says something about how little it has needed to change.
MakerBraun
DesignersDietrich Lubs, with Dieter Rams
YearAB series from the 1970s; AB 1 in the 1980s; AW 10 watch 1989
CategoryTravel alarm clocks and wristwatches
Study it forLegibility, a single accent colour, hierarchy of hands
A face with a strict hierarchy. Thick hour hand, thinner minute hand, hair-thin accent second hand, and a separate alarm indicator. Pins match decisions.
A simple geometric case. A square or rectangular body around a round face. The case stays matte and dark (or white), so the face is the only bright, readable area. Cost: almost no room for brand expression.
Numerals chosen for reading, not style. Clean sans-serif digits, sized so the face reads at arm's length, often with all twelve numbers rather than marks only. Cost: a busier face than a "minimal" four-marker dial, accepted because reading the time quickly is the whole job.
A hierarchy of hands. Hour hand shortest and thickest, minute hand longer and thinner. Weight tells you which is which before length does.
One accent colour, on the moving part. The second hand (yellow on many Braun designs) is the only colour. It shows the clock is running and gives the face life without adding noise. Cost: the accent can't be used for anything else, including the brand.
The alarm setting shown on the face. A distinct hand or marker shows when the alarm will ring, so you check it with a glance in bed, not by pressing a button.
Few, well-placed physical controls. A large snooze or alarm-off area that's easy to hit half-asleep; small, recessed setting wheels you only touch occasionally. Frequency sets the size, again.
Lab: legibility and the single accent
Glance at the clock for half a second, look away, and say the time. Then switch off numerals and weighted hands and try again. Turn on "decoration" (extra rings, a logo, a second colour) and notice how the yellow hand loses its pull. One accent is a signal; two are a pattern.
What it left out
Date windows on most models, luminous decoration, multiple colours, a big logo on the face, textured dials, Roman numerals. It also left out any second accent: no red alarm button competing with the yellow hand.
Limits and criticism
Matte dark faces can be hard to read in the dark without lighting, and analogue faces in general are slower to read precisely than a digital display. Some models' setting wheels are small and fiddly. The style has been copied so much that a yellow second hand now reads as "Braun-like" decoration on products that lack the underlying hierarchy.
Don't
Four accents, no signal. When everything is coloured, the eye has nowhere to go first.
Do
One accent on what moves. The colour marks the live, changing part; everything else is neutral.
Steal this for your software
Accent the live thing. Use your accent colour for what's current, changing or active: the playing track, the selected item, the timer running. Static things stay neutral.
Hierarchy by weight. Like the hands, distinguish elements by weight and size first. Headline thick and short, body lighter, captions finest.
Show the scheduled state. An alarm hand is a preview of the future. Show upcoming events, scheduled sends and next billing dates where people glance, not inside settings.
Legibility over minimalism. If removing numerals makes the time slower to read, keep the numerals. Minimal means nothing unnecessary, not nothing.
Do
Test glanceability: a half-second look, then recall.
Keep one accent per view and give it a meaning.
Show scheduled or future states on the main surface.
Don't
Strip labels or numbers for elegance when they carry the job.
Use the brand colour for decoration and then again for state.
Put the most-used control in the smallest target.
In the wild
Apple Watch facesApple, 2015 onward
Several faces use neutral dials with a single accent colour for the second hand or complications chosen by the user. One accent, user-chosen, on what moves.
LinearLinear, 2019
A largely monochrome interface where colour is mostly reserved for status and priority. Colour as state, not decoration.
Google Calendar's current-time lineGoogle
A single red line marks "now" across the day view. The accent marks the live moment.
For the solo creator
Pick your accent colour once and write its meaning next to the token: "accent = the thing happening now" or "accent = the completing action". When you're unsure whether something deserves the accent, the written rule answers for you, and your interface stays as calm as a Lubs clock.
Common mistakes
Brand colour everywhere
The brand colour feels like identity, so it goes on headers, icons, links and buttons.
Identity can be in the shapes and type. Keep the accent for one meaning.
Minimal at the cost of reading
Removing numerals or labels looks cleaner in a mockup.
Run the half-second glance test. Speed of reading wins.
Check yourself
Your podcast app uses its orange brand colour for the logo, all icons, links, the play button and the progress bar. Users say the screen feels busy. Using the Lubs lesson, what do you change first?
The accent should mark the live thing. b gives orange one meaning. a softens the noise but keeps it; c doubles it; d throws away a useful signal.
Exercise 7.1 30 minutes · on your own product
The glance test
Show your main screen to someone (or yourself, after a break) for half a second.
Ask: what's the most important thing on it, and what state is it in?
Count accent-coloured elements. If more than one meaning uses the accent, reassign.
Repeat the glance test.
You're done when: a half-second glance reliably gives the main state, and the accent has one written meaning.
Beginner
Competent
Strong
Accent count reduced.
Accent has one meaning; glance test passes.
Also passes in dark mode and at 200% text size.
Connect the ideas: Part two recap
Which single sentence best summarises what the SK 4, T3, ET 66, 606 and the Lubs clocks have in common?
Colour (a) and part count (b) are consequences. The common move is a visible hierarchy of importance plus refusal. That same move underlies visual hierarchy in Visual Design and "less, but better" in Honest & Calm.
Part three
Japan: emptiness and the super normal
Braun taught order. These three chapters teach something quieter: designing objects that fit into behaviour people already have, that leave room for the user, and that don't ask to be noticed. Naoto Fukasawa, Kenya Hara and Jasper Morrison give you the vocabulary: "without thought", "emptiness", "this will do", "super normal".
8
MUJI wall-mounted CD player: the pull cord
Taught by Naoto Fukasawa
A square speaker you hang on the wall, with the CD spinning in plain view and a cord hanging from it. Pull the cord and music plays, the way pulling the cord on a kitchen ventilation fan starts the fan. You don't learn it. You already know it.
Fukasawa developed the idea around 1999 as part of his "Without Thought" workshops, which looked for designs that fit behaviour people perform unconsciously. MUJI produced it, and it is in the collection of the Museum of Modern Art in New York. The disc turning slowly behind a clear cover recalls the blades of a fan, and the cord completes the memory. The object borrows an action from your body's memory and gives it a new job.
MakerMUJI (Ryohin Keikaku)
DesignerNaoto Fukasawa
YearConcept around 1999; produced by MUJI
CategoryWall-mounted CD player with speaker
Study it for"Without thought", borrowed behaviour, one gesture
Speaker, disc and cord on a wall. The fan on the right isn't part of the product; it's the memory the product uses. Schematic: real speaker perforations and button placement differ.
Hang it on the wall like a fan. Mounting it on the wall takes it off the shelf and puts it at eye level, where a ventilation fan would be. Placement is part of the meaning. Cost: you need a wall spot near a socket, and it's not portable.
The disc spins in view. A clear cover shows the CD turning. You see that it's playing without any light or display, and the motion recalls fan blades. Cost: dust, and a visible mechanism has to look good while moving.
A pull cord as the main control. One pull to start, one to stop. No reading, no choosing, no learning. Your hand has done this before. Cost: a cord is imprecise for anything beyond on and off, so other functions need separate controls.
The speaker is the body. The square face is the speaker surround. No separate speakers, no wiring between boxes. One object, one shape.
Secondary controls kept small and out of the face. Volume and track buttons are small and sit at the edge. The face is reserved for the disc.
A visible power cable, accepted. The cord to the socket hangs down. Fukasawa didn't hide the honest fact that it needs power; the object stays simple enough that one cable doesn't spoil it.
What it left out
A display, a remote control, a stack of buttons on the face, a lid you open with a button, a brand name on the front, stereo separation. It also left out instructions. The point is that you don't need any.
Limits and criticism
CDs went away; the object's medium aged faster than its idea. Sound from a single small box is limited. And "without thought" depends on a shared memory: someone who never pulled a fan cord gets a neat gadget, not a moment of recognition. Borrowed behaviours are cultural, and not everyone has the same ones.
The best design dissolves into behaviour.Paraphrase of a recurring idea in Naoto Fukasawa's talks and his book with Jasper Morrison, "Super Normal" (2007)
Don't
Invented behaviour. A novel gesture needs teaching, and most people skip the tutorial.
Do
Borrowed behaviour. Pull-to-refresh borrows "pull to bring something new" and needs no tutorial for most phone users now.
Steal this for your software
Borrow a behaviour people already have. Pull to refresh, swipe to dismiss, type to search, drag a file onto a window, press Space to play. Map your main action to one of these before inventing anything.
Make "opening it" the pull. If there's one thing people do every time, do it on launch: resume the last document, the last track, the last position.
Show state through the content. Like the turning disc, let the content itself show activity (a waveform moving, a progress bar filling) instead of an extra status light.
One gesture for the main job, small controls for the rest. Keep secondary controls small and at the edges.
Do
List the behaviours your users already perform in their tools and homes.
Map your primary action to the most familiar one.
Check the borrowed behaviour is shared by your audience across cultures and platforms.
Don't
Invent a new gesture for a common action.
Draw a pull cord on a screen (that's the costume).
Hide the only way to do something behind an undiscoverable gesture.
In the wild
Pull-to-refreshLoren Brichter, Tweetie 2, 2009
Brichter's gesture borrowed the natural move of scrolling past the top to "ask for more". It spread across nearly every list-based app. The best gestures feel discovered, not taught.
Spotlight and RaycastApple, 2005; Raycast, 2020
One keystroke, then type what you want. Typing a name is behaviour everyone already has. Search is the software pull cord.
AirPods caseApple, 2016
Opening the case near an iPhone offers to connect. The natural action is the command. Turn an action people already take into the trigger.
For the solo creator
Borrowed behaviour is also cheaper to build and support: platform gestures come with accessibility, documentation and muscle memory included. A custom gesture is a feature you have to teach, test and explain forever.
Common mistakes
Cute metaphors
You find a charming physical reference and build around it, even if users don't share the memory.
Test recognition with three people. If they need it explained, it's not "without thought".
Single gesture, no alternative
A hidden swipe is the only way to delete or archive.
Keep a visible path too. The MUJI player still has buttons.
Check yourself
You make a white-noise app for sleep. What's the most "without thought" design for starting it?
Opening the app is the pull. People at bedtime don't want decisions. a asks for choices, b invents behaviour, d copies the costume.
Exercise 8.1 30 minutes · on your own product
Find your pull cord
Write the one action users take most often in your product.
List five everyday behaviours (from tools, homes or other apps) that resemble it.
Pick the most widely shared one and redesign the action around it, or make app launch perform it.
Test with two people without explaining.
You're done when: your main action works with a borrowed behaviour or on launch, and two people used it without instruction.
Beginner
Competent
Strong
Behaviours listed.
Main action redesigned and tested.
Launch does the main action, with a visible fallback control, and keyboard and screen reader paths also work.
9
MUJI as a system: emptiness and "this will do"
Taught by Kenya Hara, with Ikko Tanaka and Naoto Fukasawa
MUJI is not one object; it is a way of making thousands of objects that share no logo, little colour and plain packaging, so that each one is an empty vessel the owner fills with their own life. Its ideal is not "this is what I want" but a confident "this will do".
MUJI began in 1980 as a private label of the Japanese supermarket chain Seiyu, with about forty products. The name, short for Mujirushi Ryōhin, means roughly "no-brand quality goods". The founding art direction came from graphic designer Ikko Tanaka. Its early approach rested on three practices: careful selection of materials, streamlined manufacturing, and simplified packaging. Kenya Hara became its art director in the early 2000s and gave the philosophy its clearest language: emptiness.
MakerRyohin Keikaku (MUJI)
Key figuresIkko Tanaka (founding art direction), Kenya Hara (art director from 2002), Naoto Fukasawa (product advisory)
YearFounded 1980
CategoryBrand and system of household goods, stationery, clothing, food, retail
Study it forEmptiness, defaults, consistency across thousands of products
Emptiness is not simplicity
Hara draws a distinction that matters for software. Simplicity, as European modernism practised it, is reduction toward a correct, rational form: remove until only the essential remains. Emptiness is something else: a form that is open enough to receive whatever the user brings. A simple object says "here is the right answer". An empty object says "here is room for your answer". A plain MUJI notebook isn't the correct notebook; it's a notebook that becomes yours as you fill it.
Hara's famous illustration is the MUJI "Horizon" advertising campaign of 2003: photographs of nearly nothing, a horizon line over the salt flat of Uyuni in Bolivia and over Mongolian grassland, with the small MUJI logo. The images carry no message. Viewers project their own. That is the brand's whole idea in one picture.
Two kinds of minimal. Simple products prescribe; empty products receive. Both remove ornament, for different reasons.
"This will do" versus "this is what I want"
Hara describes MUJI's target feeling with two Japanese phrases. Kore ga ii: "this is what I want", a strong, specific preference, the feeling most brands chase. Kore de ii: "this will do", which in MUJI's sense is not resignation but a calm, confident satisfaction. The product is good enough that you stop searching. It doesn't need to be your favourite; it needs to be right enough that you never think about it again.
Software chases kore ga ii relentlessly: delight, personality, endless customisation so each user gets exactly what they want. That produces settings pages with ninety toggles and products that need tuning before they work. A kore de ii product ships excellent defaults, and most people never change them.
Where MUJI aims. Not the weakest feeling, the most settled one. The search ends.
A writing app's settings: two philosophies
Settings (1 of 4)
FontChoose from 48 ›
Font size11 to 32 ›
Line height1.0 to 2.4 ›
Paragraph spacingCustom ›
Theme14 themes ›
Accent colourPick ›
Cursor styleBar ›
Typewriter sound
Word goal confetti
Settings
Text sizeA − ● +
AppearanceFollows system
Sync
The typeface, measure and spacing were tuned once, carefully, for reading and writing. You can just write.
Kore ga ii: every preference is honoured, so every user has to decide everything. Most will fiddle for ten minutes and end up with something worse than a good default.
Kore de ii: three settings, each one with a real reason to exist (eyesight, light, devices). The rest is decided by the designer, who did the work so the user doesn't have to.
The system's decisions
Different objects, one language. Unbleached paper, clear plastic, plain labels, sizes that fit together. Pins match the decisions.
Materials shown as they are. Unbleached or off-white paper, kraft card, undyed fabrics where possible. Skipping bleaching and dyeing was originally a cost saving that became an aesthetic. Cost: a narrower colour range, and some people read it as "cheap".
Transparent and translucent plastics. Clear gel pens show their ink level; translucent polypropylene boxes show their contents. The material tells you what's inside.
Sizes that fit each other. Storage boxes, drawers and shelves are sized to stack and nest together across the range, so a new purchase fits an old one. A system, like the 606.
The label does the talking, and it's quiet. Product name, material, size and price on a simple label or tag; usually no logo on the product itself. Information replaces branding.
Standard formats and consistent stationery. Notebooks in standard paper sizes and simple rulings; pens in a few tip sizes and colours. The range is deep but not wide, so choosing is fast.
The shop as part of the product. Stores use natural materials and calm lighting with products shown plainly. The retail experience and the objects speak one language.
What it leaves out
Logos on products, seasonal colour trends, character licensing, aggressive packaging, sale-driven urgency, and the idea that each product should be someone's favourite. It deliberately avoids peak emotion in favour of steady trust.
Limits and criticism
"No brand" became a very strong brand; the absence of a logo is now instantly recognisable, which is a paradox Hara himself has discussed. Quality varies across a range this large, and "this will do" can slide into "this is mediocre" if the defaults aren't actually excellent. Emptiness only works when the empty thing is very well made.
Steal this for your software
Design for "this will do". Spend your effort on defaults so good that most people never open settings. Every setting you add is an admission that you didn't decide.
Make the product an empty vessel. Neutral chrome, generous space, the user's content as the only colour. A notes app should feel like a MUJI notebook: plain until you write in it.
Labels instead of branding. Inside the product, replace logos and slogans with plain, useful information: what this is, what it costs, what will happen.
Deep, not wide. A few excellent templates or options, not a gallery of a hundred mediocre ones.
Sizes that fit. Consistent components and exports so every part works with every other, like stackable boxes.
One language from shop to product. Your landing page, onboarding, app and emails should feel like one calm store (see Identity & Launch).
Don't
A full vessel. The product's personality fills the space before the user has written anything.
Do
An empty vessel. Space, a cursor, and one quiet fact. The user brings the meaning.
Do
Count your settings and justify each one in writing.
Use your content area for the user's content first.
Prefer a few deep, excellent options over many shallow ones.
Don't
Confuse empty with unfinished; emptiness requires excellent craft.
Fill empty states with mascots and marketing.
Treat customisation as a substitute for deciding.
In the wild
iA WriterInformation Architects, 2010
Famously shipped with very few settings and a carefully chosen typeface and measure; the team argued that good defaults were the feature. Kore de ii in software: decide, so the writer doesn't have to.
Apple NotesApple
An almost empty page with a few formatting options; used by a huge number of people precisely because it asks nothing. "This will do" can be the most-used product in its category.
Plain-text notebooks: Obsidian, Bear2020, 2016
Quiet canvases that become personal through use and structure the user adds. Empty vessels let users build their own meaning.
For the solo creator
"This will do" is a gift to a solo developer. Every setting doubles some part of your test matrix and your support surface. Shipping one excellent default and three justified settings means less code, fewer bugs, and a calmer product. Your time goes into making the default great.
Common mistakes
Empty means lazy
You remove things and stop there, leaving a bare, unconsidered screen.
MUJI's emptiness is backed by obsessive material and proportion work. Spend the saved effort on type, spacing and defaults.
Settings as conflict avoidance
Two users want different things, so you add a toggle instead of deciding.
Ask which choice serves most people's real job; ship that. Add a setting only for needs (eyesight, accessibility, device), not tastes.
Copying the beige
MUJI's look is easy to imitate with kraft tones and sans-serif labels.
Imitate the attitude, not the palette: plain information, no shouting, room for the user.
Check yourself
Users of your budgeting app ask for 15 new chart types. Which response is most "kore de ii"?
Kore de ii means doing the deciding so users are satisfied without searching. b answers the needs under the requests. a and d are kore ga ii (preference through options), c mistakes emptiness for refusal to listen.
Check yourself
What's the difference between "simple" and "empty" in Hara's sense, applied to a journaling app?
Both remove clutter, but simple gives one correct form while empty leaves room. Neither is always better; choose deliberately.
Exercise 9.1 60 minutes · on your own product
The settings purge
List every setting in your product.
For each, write whether it serves a need (eyesight, language, device, accessibility) or a taste.
For each taste setting, decide the best default and write one sentence defending it.
Remove or hide at least a third of the taste settings. Keep need settings.
Look at your empty states. Remove anything that's about you rather than the user.
You're done when: you have a settings table (need or taste, default, decision) and a build with fewer settings.
Beginner
Competent
Strong
Table done; nothing removed.
A third of taste settings removed; defaults defended.
Removed, defaults improved, empty states cleaned, and a short changelog note explaining why.
10
Super Normal and ±0: the ordinary, perfected
Taught by Naoto Fukasawa and Jasper Morrison
Some objects are so well suited to life that you only notice their quality after using them for a while. Fukasawa and Morrison called this "Super Normal": not design that stands out, but design that settles in.
In 2006 the two designers staged an exhibition in Tokyo called Super Normal, gathering ordinary objects (many anonymous, some designed by them) that had been refined by long use into something better than "designed". A book, Super Normal: Sensations of the Ordinary, followed in 2007. A few years earlier, in 2003, Fukasawa had helped launch ±0 (Plus Minus Zero), a Japanese brand of household appliances and goods built on a similar idea: not more, not less than necessary. Fukasawa often illustrated "without thought" with an umbrella stand that is nothing but a shallow groove in the floor near a wall: people already lean umbrellas there, so the groove simply holds the tip.
WhoNaoto Fukasawa, Jasper Morrison
Year±0 launched 2003; Super Normal exhibition 2006; book 2007
CategoryDesign philosophy; household products
Study it forDesigning for long use, not first impressions
RelatedWithout Thought; MUJI
The disappearing umbrella stand. A groove near the wall where people already lean umbrellas. The design is almost nothing; the observation is everything.
Design the place, not the product. Instead of adding a new object (a bucket, a rack), modify the environment where the behaviour already happens. Cost: it only works where you control the floor; it's not a product you can sell in a box.
Start from observed behaviour. The idea comes from watching people lean umbrellas against walls and set the tips in tile joints. Observation precedes form.
Use the existing support. The wall already holds the umbrella; the groove only stops it sliding. Do the smallest thing that completes what people are already doing.
No visible "design". Nothing to recognise as designed. The object succeeds when nobody notices it, which makes it impossible to market on looks.
Judge by use over time. A Super Normal object is evaluated after weeks of living with it, not in a showroom. The first-impression test and the long-use test are different tests, and Super Normal favours the second.
Two curves. Products optimised for the first screenshot often lose people over months; products optimised for daily use often gain them. Your App Store screenshots measure only the left edge.
What it leaves out
Signature shapes, "statement" colours, surprise for its own sake, and the designer's ego. Super Normal leaves out the moment where someone says "oh, that's designed". ±0's products tend to be calm, softly geometric household items that look like idealised versions of what you already expected a humidifier or a toaster to look like.
Limits and criticism
Super Normal is hard to sell: it doesn't photograph well against loud competitors, and it can be mistaken for blandness. It also relies on having a well-observed "normal" to perfect; for genuinely new product categories there's no normal yet, and someone has to design the first one boldly.
Don't
Designed to be noticed. Memorable on a landing page, slower every single time after.
Do
Super normal. Type naturally or tap a plain calendar. Nobody will screenshot it; everybody will use it fast.
Steal this for your software
Design the environment. Sometimes the best feature is a change to where something happens: a default folder, a sensible file name, a pre-filled field. A groove, not a stand.
Perfect the expected. For standard components (date pickers, forms, tables, menus), make the expected version excellent rather than inventing a new one.
Judge after a month. Use your own product daily for a month before calling a design done. Write down what still annoys you on day 30.
Observe workarounds. When users do something odd to get their job done (copying into a note, renaming files a certain way), that's the tile joint. Build the groove there.
Do
Use platform-standard controls and polish them.
Collect users' workarounds and design for them.
Evaluate designs by repeated use, not by first look.
Don't
Reinvent common controls to look distinctive.
Judge a design by how it looks in a Dribbble shot.
Add an object where a small change to the context would do.
In the wild
Natural-language dates in Fantastical and TodoistFlexibits, 2011; Doist
Typing "lunch with Asha next Friday 1pm" creates the event. It perfects the most normal input there is: writing a sentence. Super normal input beats novel widgets.
macOS Finder's "Recents" and sensible defaultsApple
Saving to a sensible default location and showing recent files reduces filing work without a new tool. Change the environment, not the user.
Plain HTML forms done wellgov.uk design system, 2010s
The UK Government Digital Service built a reputation on plain, extremely well-tested form patterns. Boring, perfected, and used by millions.
For the solo creator
You are your product's most frequent user, which is a Super Normal advantage. Keep a "day 30" note: every small irritation you feel using your own product, dated. Fix the oldest one every Friday. Over a year that's fifty grooves cut exactly where your hand goes.
Common mistakes
Novelty for the launch
You need something to show on launch day, so you make a common control "unique".
Make the launch story about the job done better, not the widget.
Normal as an excuse
"Super normal" gets used to justify generic, untuned UI.
Super Normal means normal perfected. Check spacing, wording, speed and edge cases until the ordinary feels effortless.
Check yourself
You notice many users of your file-sharing app rename uploads to "2025-03-14 Client name - Invoice". What's the Super Normal response?
The renaming is the tile joint. d cuts a groove where behaviour already happens. a adds a new object, b documents the friction, c replaces predictable behaviour with surprise.
Exercise 10.1 20 minutes a day for a week · on your own product
The day-30 diary
Use your own product for its real job every day this week.
Each day, write every tiny friction you notice, however small.
On day 7, group them and mark which are workarounds you've been doing without noticing.
Pick one and design the "groove": the smallest change to the context that removes it.
You're done when: you have a dated friction diary and one shipped "groove".
Beginner
Competent
Strong
Diary kept for a few days.
Full week; one groove shipped.
Also logged other users' workarounds; groove chosen from the most repeated one.
Connect the ideas: Part three recap
Braun (Part two) and the Japanese designers (Part three) both remove ornament. What's the most useful difference for your own work?
Both are tools. Hierarchy and order (Rams) help dense, control-heavy tools. Behaviour-fit and emptiness (Fukasawa, Hara) help habits and personal content. See also The Human Mind for habit formation and Reading & Writing for empty canvases.
Part four
Devices that disappear, and devices that play
Five devices with screens, wheels, buttons and dials, so the translation to software is close. The Kindle and the iPod show how a single-purpose device can vanish into its task. The OP-1 and the Game Boy show that constraints and play can be the point. Leica and Fujifilm show what a physical control does that a menu can't.
11
Amazon Kindle: the device that disappears
Taught by the Kindle team at Amazon (Lab126), with E Ink
A reading device whose explicit goal is to vanish while you read: a paper-like screen that doesn't glow, a battery measured in weeks, buttons where your thumb rests, and almost nothing else to do.
The first Kindle (November 2007) was an odd wedge with a full keyboard, page-turn bars on both edges, and a free mobile data connection for buying books. Over fifteen years, the line removed and refined: the keyboard went (2011), a front light arrived with the Paperwhite (2012), page-turn buttons came back with an asymmetric grip in the Oasis (2016), warm adjustable light spread across the range, and the Scribe (2022) added a stylus for writing. Through every version the core promise stayed: reading, for hours, without the device getting in the way. (The reading software is broken down in Breakdowns: Reading; here we study the hardware.)
Study it forSingle purpose, subtraction over time, calm technology
A lineage of subtraction and refinement. Keyboard gone, light added from the edges, buttons returned where the thumb rests. Schematic; proportions simplified.
E-ink instead of an LCD. Reflective electronic paper reads like print in daylight, doesn't flicker, and uses power mainly when the page changes. That's what gives weeks of battery. Cost: slow refresh, ghosting, poor video and animation, and (until recently) no colour.
A keyboard, then none. The 2007 keyboard made searching and buying possible without a touchscreen. Once touch arrived, the keyboard became dead weight and went. The device got smaller, cheaper and more about reading. Lesson: a feature right for one era can be wrong for the next.
Page turns on the edges. The original had long page-turn bars on both sides so either hand could turn. The core action was physical and always under the thumb.
Battery measured in weeks. The headline spec was never speed or pixels. Battery anxiety ends; you stop thinking about charging, which is part of disappearing.
A front light, not a backlight. The Paperwhite lit the screen from the edges onto its surface, keeping the reflective, paper-like quality while allowing night reading. Later models added warm light to shift the tone toward amber in the evening. Cost: slight unevenness near the light source on some units.
Physical page buttons returned. The Oasis brought back buttons, because tapping glass with the hand that's holding the device is awkward. Touch is flexible; buttons are effortless. Both stayed.
An asymmetric grip. The Oasis moved the weight to a thicker edge so one hand holds it like a book's spine, with the screen rotating so either hand works. Form shaped around how people actually hold a book for an hour.
What it left out
Notifications from other apps, a general web browser worth using, email, social feeds, video, games, a glowing backlight. This is the decision that matters most. A tablet can show books too; it also shows everything else, all the time. The Kindle's absences are its product.
Limits and criticism
The device is tied to one store and ecosystem, a real cost to owners. Lock-screen advertising on cheaper models undercuts the calm. The software has often lagged the hardware: slow menus, cluttered home screens that push store recommendations. And e-ink refresh still makes navigation feel sluggish. "Disappearing" is a goal, not always an achievement.
Don't
A device that interrupts. Every overlay takes you out of the book.
Do
A device that disappears. Text, a margin, one quiet number.
Steal this for your software
Define the "while" state. Your product has a core state (reading, writing, listening, focusing). In that state, hide every control and suppress every interruption. Chrome appears on tap and fades away.
Make absence the feature. No notifications, no badges, no feed in the focused state. Say so in your marketing: "nothing else happens here".
Battery as respect. Translate "weeks of battery" into low CPU, no polling, dark mode that actually saves power on OLED, small downloads. Your app shouldn't appear in anyone's battery settings.
Put the core action where the hand already is. Tap zones on the edges, keyboard arrows, volume keys or headphone controls for "next". Don't make the main action a small target in the middle.
Light that adapts to the hour. Respect system dark mode, and consider warmer, lower-contrast reading themes in the evening.
Subtract as you learn. Like the keyboard, remove features that the context no longer needs. Each version should be a little more focused.
Do
Name your product's "while" state and design it first.
Measure your app's energy use on a real device.
Let people reach the core action without looking.
Don't
Show upsells inside the focused state.
Keep a feature only because early users once needed it.
Use animation in a reading view; it's the opposite of e-ink calm.
In the wild
Kobo e-readersRakuten Kobo
A close competitor with physical page buttons on some models, warm light, and support for open formats like EPUB. The same "disappear" goal, plus a more open system.
iA Writer's focus modeInformation Architects
Dims everything but the current sentence or paragraph while you write. Define the "while" state and remove the rest.
reMarkable tabletsreMarkable, 2017
An e-paper tablet for writing that deliberately leaves out apps, browsing and notifications. Absence as the headline feature.
For the solo creator
The Kindle's best decision, leaving things out, is also the cheapest. You can't out-build a tablet, but you can out-focus one. A single "while" state done perfectly beats ten features done adequately, and you can actually finish it.
Common mistakes
Interrupting your own focus mode
Growth pressure puts "rate us", upsells or tips inside the core state.
Only interrupt at natural pauses (end of a chapter, after saving), and never during.
Chrome that never leaves
Toolbars stay visible "for discoverability".
Show controls on tap or mouse move, fade them after a few seconds, and keep one subtle hint that they exist.
Check yourself
You run a language-learning app. Lessons are interrupted by streak reminders, friend activity and a shop banner. What's the Kindle-like redesign?
Define the "while" state (the lesson) and protect it; put the rest at the natural pause. b and d move noise, c removes things that may help motivation outside the focused state.
Exercise 11.1 45 minutes · on your own product
Protect the "while" state
Name the core state of your product in one word (reading, writing, playing).
Screenshot it. Circle everything that isn't the content or the one core control.
Move each circled item to before or after the state, or behind a tap.
Measure: what share of the screen is content now versus before?
You're done when: you have before/after screenshots and the content share has risen.
Beginner
Competent
Strong
Some chrome removed.
All non-core items moved; content share up noticeably.
Also no interruptions fire during the state, and the core action works with keyboard or edge taps.
12
Apple iPod and the click wheel: one control for a thousand songs
Taught by Apple's iPod team (with Tony Fadell, Jony Ive and Phil Schiller among those credited), after Dieter Rams
A music player that solved "how do you navigate a thousand songs with your thumb?" with a single circular control that scrolls faster the faster you turn it, and moved everything complicated off the device and onto the computer.
Apple announced the iPod on 23 October 2001 with the line "1,000 songs in your pocket". Competing MP3 players either held few songs or had large hard drives with clumsy button navigation. The first iPod's mechanical scroll wheel, then a touch-sensitive wheel (2002), then the click wheel with buttons built into the wheel itself (introduced with the iPod mini in January 2004 and the fourth-generation iPod later that year), made long lists fast to browse. Syncing through iTunes meant the device itself never needed a file manager.
MakerApple
Year2001 (first iPod); click wheel 2004
CategoryPortable music player
Capacity at launch5 GB, about 1,000 songs
Study it forOne control for a large space, acceleration, moving complexity elsewhere
Screen above, wheel below. The wheel scrolls; four points on it are buttons; the centre selects. Pins match the decisions. Schematic of a click-wheel model.
Hierarchical lists, all the way down. Artists, albums, songs, playlists: every screen is a list, and every list works the same way. Learn one screen and you know them all. Cost: deep libraries mean many levels.
A circular control for an endless list. A wheel has no end, so you can keep turning through a thousand items without lifting your thumb, unlike up/down buttons you must press a thousand times. The circle maps to "continuous".
Acceleration. Turn slowly and the selection moves one item per notch, precisely. Turn fast and it jumps many items per notch. One control serves both browsing and travelling. Cost: overshoot, which the slow mode then corrects.
Buttons on the wheel. The click wheel put Menu, Play/Pause, Back and Forward under the wheel itself, at the four compass points. Fewer separate parts, one area for the thumb. Cost: less tactile separation than distinct buttons.
A centre select button. Turn to choose, press the centre to go in, press Menu to go back. Three verbs cover the whole interface.
A click you can hear. The wheel produced a small click sound from the device as you scrolled, feedback that matched the speed of your movement. Cheap, and it made a touch surface feel mechanical.
Lab: scrolling 1,000 songs with one wheel
Notches turned: 0
MENU▶❚❚◀◀▶▶
Drag around the wheel (or focus it and use the arrow keys; hold for speed) to reach the target song shown in the stats line. Try it with acceleration off, then on. With acceleration, fast turns travel and slow turns aim; without it, you'll turn hundreds of notches.
What it left out
An FM radio, a recording function, an equaliser on the main screen, on-device file management, a removable battery, and, at launch, any way to load music other than syncing from a computer. Moving playlist editing and library management to iTunes on a big screen with a keyboard let the device do one thing with one control.
Limits and criticism
Early iPods were Mac-only and FireWire-only, and the non-replaceable battery drew criticism and a class action in the United States. Acceleration overshoots; with very large libraries, browsing alphabetically by wheel still beat search only because the device had no keyboard. When touch screens and search arrived (iPod touch, iPhone), the wheel's job largely moved to flicking with momentum, a different solution to the same problem.
Don't
Linear stepping. Fine for ten items, punishing for a thousand. No way to move fast.
Do
Coarse and fine in one gesture. Momentum scrolling plus an index lets one movement travel far and land precisely. The click wheel's lesson, in touch form.
Steal this for your software
Coarse and fine with one control. Any large space (a long list, a timeline, a big document) needs both fast travel and precise landing. Momentum scroll, an alphabet index, a minimap, a scrubber that slows as you move vertically (like iOS video scrubbing speeds).
One pattern for every screen. If every level of your hierarchy behaves the same way, people learn it once.
Move complexity to where it's easy. Heavy editing on desktop, consumption on mobile; bulk setup in a web dashboard, daily use in the app. Don't force every task into every device.
Feedback at the speed of the hand. Haptic ticks on a picker, a subtle sound, a counter changing as you drag: feedback tells people the control is alive and how fast they're moving.
Search when there's a keyboard. The wheel existed because there was no keyboard. If your users have one, type-to-filter beats any wheel.
Do
Give long lists both a fast and a precise way to move.
Keep navigation identical across levels.
Decide which device each task belongs on.
Don't
Paginate long lists with small next/previous buttons.
Draw a click wheel on a touch screen.
Cram desktop-level management into a phone screen just because you can.
In the wild
iOS momentum scrolling and the alphabet indexApple, 2007 onward
Flick to travel, touch to stop, slide the side index to jump to a letter in Contacts. The wheel's coarse/fine idea, rebuilt for glass.
Apple Watch Digital CrownApple, 2015
A small wheel for scrolling and zooming on a screen too small for fingers, with haptic detents. When the screen is tiny, a physical wheel returns.
Video scrubbers in YouTube and iOS players2010s
Scrubbing gives a coarse jump, with finer seeking available on many players. Any long timeline needs coarse and fine.
For the solo creator
You can't build custom hardware, but you can build keyboard shortcuts, which are your click wheel. J/K to move, Enter to open, Esc to go back: three keys that make any list-based app feel as fluent as an iPod. It's a weekend's work and power users notice immediately.
Common mistakes
Only fine control
You test with ten items in development; real users have two thousand.
Seed your test data with realistic volume (thousands of rows) and design for travel.
Only coarse control
Fast-scroll features overshoot and there's no precise mode.
Let speed decide precision: slow movement should always be exact.
Check yourself
Your photo-journal app shows ten years of entries in a single scrolling timeline. Users complain it takes forever to reach 2019. What's the iPod lesson?
The problem is travel across a large space. c adds coarse travel while keeping fine scrolling. a makes travel worse, b only solves one destination, d copies the surface.
Exercise 12.1 45 minutes · on your own product
Stress-test your biggest list
Load your product with ten times the data a typical user has (generate it).
Time how long it takes to reach an item near the end, and to find a specific item.
Add one coarse control (index, jump-to, filter, search) and one fine-control improvement (keyboard navigation, precise scroll).
Time again.
You're done when: you have before/after times for two tasks on a large dataset.
Beginner
Competent
Strong
Large data loaded, problems noted.
Coarse and fine controls added; times improved.
Also keyboard shortcuts and a remembered position when returning to the list.
13
Teenage Engineering OP-1 and the Pocket Operators: constraints and play
Taught by Teenage Engineering (Jesper Kouthoofd and team, Stockholm)
A small portable synthesiser and sampler that deliberately limits you (four tracks on a simulated tape, four colour-coded knobs, a tiny screen full of playful animations) and in doing so makes making music feel like play instead of engineering.
Teenage Engineering was founded in Stockholm in 2005. The OP-1 went on sale in 2011 after being shown in prototype form, and became a cult instrument. Instead of copying a studio, it borrowed the limits of a four-track tape recorder. Its screen shows cartoon-like graphics (a cow, a tape reel, abstract shapes) that represent sound parameters, and its four knobs are colour-coded to match on-screen elements. From 2015 the company also made the Pocket Operators: inexpensive, calculator-sized instruments with exposed circuit boards and a segment display. The OP-1 field followed in 2022.
MakerTeenage Engineering
YearOP-1 2011; Pocket Operators 2015; OP-1 field 2022
CategoryPortable synthesiser, sampler and recorder
Study it forCreative constraints, colour mapping, personality in a tool
Four colours tie knobs to screen. The white, yellow, green and red knob each changes the on-screen element of the same colour. Schematic: layout and colours simplified (the real OP-1 knobs are blue, green, white and orange).
A small screen with playful, abstract graphics. Instead of numeric parameter lists, each sound engine and effect has a visual metaphor that moves as you play. You learn by watching what changes. Cost: less precise than numbers; some graphics are more charming than clear.
Four colour-coded encoders. Each knob has a colour, and whatever it controls on screen is drawn in that colour. You never read a label to know which knob does what on the current screen. The mapping changes per screen; the colours stay. It's the ET 66 lesson applied to dynamic controls.
Mode keys with icons, not menus. A row of buttons jumps straight to synth, drum, tape, mixer and other modes. Flat navigation, one press to anywhere.
A four-track tape as the recorder. The OP-1 simulates a four-track tape machine, with limited tracks and tape-like editing. Limits force decisions (bounce, commit, move on), which many musicians found freeing. Cost: power users hit the ceiling; that's the point and the frustration.
Transport controls borrowed from tape decks. Record, play, stop: familiar symbols from cassette machines. Borrowed behaviour again.
A personality throughout. Typography, sounds, tiny animations and even the packaging share a cheerful, engineered character. Personality makes people forgive limits and want to explore.
Constraint taken to the extreme. The Pocket Operators remove the case entirely; the circuit board is the product. Schematic.
What it left out
A large screen, unlimited tracks, a full-size keyboard, deep menus, realistic skeuomorphic graphics of studio gear, and the assumption that a professional tool must look serious. The Pocket Operators left out the case.
Limits and criticism
Price: the OP-1, and even more the OP-1 field, are expensive for what they do, and the price rose over time. Some functions hide behind button combinations you must memorise. Playful graphics can obscure the actual value of a parameter. Constraints are freeing for sketching and frustrating for finishing.
Don't
Detached controls. Four identical sliders; you must read and remember which changes what.
Do
Colour-mapped controls. Each control and its effect share a colour; the canvas shows what each one touches.
Steal this for your software
Colour-map dynamic controls. When the same physical or on-screen controls change meaning per mode, tie them to their targets by colour or by drawing the link.
Constraints as a creative feature. A daily writing app limited to 750 words, a sketch app with only three brushes, a 15-second video format. Pick a limit that makes starting easier, and say why.
Show parameters as pictures. Where users tune something abstract (audio, colour, timing), show a visual that reacts in real time instead of a number alone, and keep the number available.
Personality in the margins. A small animation on export, a playful empty state, a sound on completion. Keep the work area serious and let personality live at the edges.
Flat modes, one press each. If your app has five modes, put them one tap or one key away, never in a menu.
Do
State your constraints openly as part of the product's idea.
Link controls to their effects visually.
Let personality show where it doesn't slow work.
Don't
Impose limits that only serve your convenience and call them "creative".
Make playful graphics the only way to read a value.
A technical limit (SMS length) turned into a writing style. Constraints shape what people make.
Figma's multiplayer cursorsFigma, 2016
Each collaborator's cursor and selection share a colour with their name. Colour as a live link between actor and effect.
PlaydatePanic, 2022
A small, yellow, one-bit-screen handheld with a crank, designed with Teenage Engineering. Personality plus constraint as a whole product idea.
For the solo creator
Constraints are a solo developer's best friend: they cut scope and give the product a story. "Four tracks" is a feature on a box. "Only plain text", "one project at a time" or "works offline, no account" can be yours. Choose the limit, then design the delight around it.
Common mistakes
Whimsy in the work area
Playful animations spread into every interaction and slow down repeated tasks.
Put play at moments of completion, not during the hundredth repetition.
Arbitrary limits
You limit something because it's hard to build, then market it as philosophy.
A good constraint must help the user start or decide. If it only helps you, say so honestly or remove it later.
Check yourself
Your journaling app's users rarely write more than a sentence and often abandon entries. Which OP-1-style constraint might help?
A clear, small constraint lowers the barrier to start and gives a sense of completion. a keeps the blank-page problem, c adds options, d puts whimsy in the work area.
Exercise 13.1 30 minutes · on your own product
Design one creative constraint
Find the moment in your product where people hesitate or quit.
Brainstorm five constraints that would make that moment smaller or more decisive.
Pick one, sketch how it's shown (a frame, a counter, a fixed number of slots), and write the one-line reason you'd put on your website.
You're done when: you have one constraint with a sketch and a public one-line reason.
Beginner
Competent
Strong
Constraint chosen.
Sketched with visible framing and a reason.
Prototyped and tried by two people, with notes on whether it helped them start.
14
Leica M and Fujifilm X100: state you can see without switching on
Taught by Leica (from Oskar Barnack's lineage to the M series) and Fujifilm
On a Leica M or a Fujifilm X100, shutter speed is a number on a dial, aperture is a number on a ring, focus distance is a mark on the lens. You can read every important setting with the camera switched off, in your hand or across the room. No menu needed.
The Leica M3 (1954) set the pattern for the M rangefinder line: a compact body, an optical viewfinder with a rangefinder patch for focusing, and manual controls each doing one thing. Digital M cameras kept that pattern. Leica's motto Das Wesentliche, "the essential", became most literal in variants that remove things: the "-P" models such as the M9-P (2011) dropped the red dot logo for discretion, and the M-D (2016) removed the rear screen entirely. In 2011 Fujifilm's X100 brought the dial-based approach to a fixed-lens digital camera with a hybrid viewfinder, and a whole category of "dial cameras" followed.
Study it forVisible state, one control per variable, removing to focus
RelatedFujifilm X-Pro, X-T series
Every variable has its own control, and every control shows its value. Shutter on top, aperture and distance on the lens. Pins match decisions.
A shutter speed dial with printed numbers. The dial's position is the setting. Read it from above at a glance, set it before raising the camera, even with the power off. Cost: discrete steps, and a dial takes space on the top plate.
Aperture and focus on the lens itself. The aperture ring and distance scale sit where those variables physically act. Mapping is direct: turn the lens to change what the lens does. Experienced photographers pre-focus by the scale without looking through the viewfinder.
A focus tab under the finger. Many M lenses have a small tab on the focus ring; its position tells you roughly the focus distance by touch alone. A state readable by feel.
An optical viewfinder you look through, not at. The rangefinder window shows the world directly, with frame lines, and you can see outside the frame (what is about to enter). Cost: parallax at close range and no exact preview of the image (the X100's hybrid finder adds an electronic overlay to address this).
Removing the brand mark. The "-P" models left off the red dot to make the camera less conspicuous for street photography. A product that takes its own logo off to serve the user's purpose.
Removing the screen (M-D). No rear display, no chimping (checking every shot). Just an ISO dial on the back where the screen would be. Extreme, controversial, and a clear statement: you're here to look at the world, not at the camera.
Where does the state live?
SHOOTING MENU 2/7 Image quality › Drive mode › > Exposure › Mode: P* Shutter: AUTO Aperture: AUTO ISO: AUTO (max 6400) Custom 3 ›
To know what the camera will do, switch it on, open a menu, go to page 2, open Exposure. The "*" means a shifted program. You must remember what that means.
In a menu: the camera knows its state, but you don't until you go looking. The same is true of apps whose important settings hide three levels deep.
On the controls: one control per variable, each showing its value. You can predict the photo before you take it. In software: show the active filter, the current mode, the selected account on the surface where people act.
What they left out
Mode dials with twelve scene modes, deep menu trees for basic exposure, autofocus (on the M), zoom lenses (on the X100, a fixed lens), the red dot (M-P), and the screen (M-D). Each removal made the remaining controls more legible and the camera more about looking.
Limits and criticism
Manual focus rangefinders are slow for fast action and hard for close-ups. Leica prices are extreme; you pay a lot for less. Dials can be knocked accidentally (some have locks for this reason). And dial cameras still have menus; they just keep the essential variables out of them, which is the real lesson.
Don't
Hidden state. A filter is active, shown only by a tiny icon. People think data is lost.
Do
State on the surface. The active filter is a visible, removable chip, with a count. Like a dial, you read the setting where you act.
Steal this for your software
Show the important variables at rest. Active filters, sort order, current account, sync state, draft or published: visible on the working surface without opening anything.
One control per variable, with its value on it. A segmented control showing "Week" is a dial; a hamburger hiding "View: week" is a menu.
Put controls where the effect happens. Formatting near the text, crop on the image, column sort on the column header. The lens-ring principle.
Remove to focus. Consider a "Wesentliche" mode: a variant of your app without the screen that distracts (stats, feed, notifications), for people who want only the core act.
Take your logo off the work. Exports, shared links and embeds should carry the user's content, not your branding, unless they choose otherwise.
Do
List the three variables that most change outcomes, and make them visible at rest.
Show non-default states loudly (filters, modes, overrides).
Keep advanced settings in menus; keep essential ones out of them.
Don't
Hide modes that change behaviour behind icons with no label.
Draw skeuomorphic dials for things a segmented control would show better.
Brand users' exports by default.
In the wild
HalideLux, 2017
Shows exposure and focus state on screen while shooting, with manual controls reachable by thumb. Camera-app state on the surface, not in settings.
Gmail's search chipsGoogle
Filters appear as visible chips under the search field, each removable. Active state as a readable, removable object.
macOS menu bar mode indicatorsApple
Focus modes, recording and microphone use show as icons in the menu bar while active. Important states stay visible while they're on.
For the solo creator
"Where did my data go?" bugs are often hidden-state bugs: a filter left on, a different account selected, an archived view. Making state visible fixes a whole class of support tickets for the price of a chip and a count.
Common mistakes
Icon-only modes
An icon changes slightly to show a mode, which only you notice.
Pair modes with text and a distinct visual state, like a dial position.
Settings that act globally but live locally
A sort order set once silently affects every list.
Show the active setting on every surface it affects.
Check yourself
Your invoicing app supports multiple businesses. Users sometimes create invoices under the wrong one. What's the dial-camera fix?
The problem is invisible state. c puts the variable on the surface where people act, readable at a glance. a adds friction without information, b hides state further, d removes value.
Exercise 14.1 30 minutes · on your own product
The power-off test
Take a screenshot of your main screen in a non-default state (filtered, sorted, in a mode).
Show it to someone and ask what state the app is in.
List every state they missed.
Make each visible on the surface: a chip, a label, a segmented control showing its value.
You're done when: a stranger can name every active state from a single screenshot.
Beginner
Competent
Strong
Missed states listed.
All made visible on the main screen.
Also removable in place, with a count of what's hidden.
15
Nintendo Game Boy and Wii: lateral thinking with withered technology
Taught by Gunpei Yokoi, with Nintendo (Satoru Iwata, Shigeru Miyamoto) carrying the idea forward
The Game Boy beat technically superior colour handhelds by using mature, cheap, power-efficient technology in a new way, and putting battery life, price, durability and great games ahead of specifications.
Gunpei Yokoi, head of Nintendo's R&D1, described his approach as kareta gijutsu no suihei shikō, usually translated "lateral thinking with withered technology": use technology that is mature, well understood and cheap, and find a new use for it. The Game Boy (1989) had a small greenish monochrome screen with no backlight when rivals such as the Atari Lynx and Sega Game Gear offered colour. But it ran for many hours on four AA batteries while the Game Gear drained six in a few, it was cheaper, it survived drops, and it came with Tetris in many markets. The Game Boy family went on to sell well over 100 million units. Yokoi died in 1997; years later the Wii (2006) applied the same thinking, using an inexpensive motion controller and modest graphics hardware to bring in people who had never played games.
MakerNintendo
DesignerGunpei Yokoi and Nintendo R&D1 (Game Boy)
YearGame Boy 1989; Wii 2006
CategoryHandheld and home game consoles
Study it forMature tech, battery and price as features, play first
Cheap, tough, long-lasting. A reflective monochrome screen, a cross-shaped pad, two action buttons, and a speaker. Pins match the decisions.
A monochrome reflective screen. Mature, cheap LCD technology with no backlight. It drew little power and kept the price down. Cost: blur on fast motion, hard to see in poor light, no colour, criticised at launch as outdated.
The cross-shaped directional pad. Yokoi's team had already used the "plus" pad on Game & Watch handhelds. A flat, thin, durable control that the thumb operates without looking, far better than a small joystick in a pocket device.
Two action buttons, angled. A and B sit at a diagonal matching the natural arc of the right thumb. Few buttons kept games simple to learn.
A battery light. A small red LED by the screen dims as batteries run low. One honest indicator of the one resource that mattered.
Four AA batteries for many hours. Battery life was a headline feature: a long journey's worth of play, with batteries available in any shop. Rivals with colour screens needed more batteries and lasted a fraction as long.
Cartridges and a killer game. Tetris, bundled in many markets, was perfect for a small monochrome screen and short sessions. Hardware and software designed for each other.
A link cable for play together. Two Game Boys connected for two-player games. A cheap cable created a social feature, years before online play.
Losing on the spec sheet, winning in the pocket. The Game Boy chose which column to win. Bar lengths are illustrative of the trade-off, not measurements.
What it left out
Colour, a backlight, a TV tuner add-on as a core feature, extra buttons, and the race for specifications. The Wii, later, left out high-definition graphics (at launch) and the complicated many-button controller that intimidated non-players.
Limits and criticism
The screen really was poor in dim light, spawning an industry of clip-on lights and magnifiers. "Withered technology" can become an excuse for being behind; Nintendo later had periods where hardware lagged too far. The Wii's motion controls were imprecise for some games and novelty faded for many owners.
Steal this for your software
Use boring technology. A proven database, a server-rendered web app, plain HTML forms, a mature framework. Mature tech is cheap to run, well documented and rarely breaks at 3 a.m. Spend your novelty on the product, not the stack.
Compete on the column you can win. You can't beat big companies on features. You can beat them on speed, price, battery, privacy, offline use, simplicity. Pick one or two and make them headline features.
Show the one resource that matters. Like the battery light: storage left, credits left, words left. One honest indicator, not a dashboard.
Design software and "hardware" together. If your product runs on phones, design for one-thumb sessions of two minutes, like Tetris for the Game Boy.
Play first. Get people doing the fun or useful thing in the first minute, before accounts and settings. The Wii's tennis took seconds to understand.
Don't
Fresh technology everywhere. Every layer is novel, so every failure is novel too, and you're the only engineer.
Do
Withered technology. A boring stack, and the novelty goes into what users actually touch.
Do
Pick technology you understand deeply.
Choose and advertise the trade-off you win.
Get people to the core experience in under a minute.
Don't
Adopt new tech for its own sake.
Compete on feature count with funded teams.
Gate the first experience behind sign-up and setup.
Argues each team has a few "innovation tokens" to spend and should use proven tech elsewhere. Yokoi's idea, restated for software teams.
Pieter Levels's productsNomad List, Photo AI and others
A solo maker known for building profitable products on a very simple, mature stack. Withered tech lets one person ship and maintain many things.
WhatsApp's early years2009 to 2014
A small engineering team served hundreds of millions of users on a mature platform (Erlang), with a deliberately simple product. Proven technology plus focus scales further than novelty.
For the solo creator
This may be the most important chapter for you. Every hour you spend fighting a new framework is an hour not spent on design. Write down your stack, mark anything younger than three years, and ask whether it earns its place. Your "innovation tokens" belong in the parts users see.
Common mistakes
Spec-sheet envy
Competitors list fifty features, so you feel you need fifty-one.
List the two dimensions you'll win (speed, price, simplicity) and put them in your headline.
Mistaking old for good
"Withered" gets read as "outdated is fine".
Yokoi used mature tech in a new way. The lateral thinking matters as much as the withered part.
Check yourself
You're starting a habit-tracker as a solo developer. Which plan is most Yokoi?
d uses mature tech in a focused way and competes on columns a small team can win. a and b spread one person too thin; c waits for technology instead of thinking laterally.
Exercise 15.1 40 minutes · on your own product
Your withered-tech audit and winning column
List every technology in your stack and its age.
Mark each as "proven" or "innovation token". Allow yourself at most two tokens.
Name the two dimensions where you can beat bigger competitors.
Rewrite your landing-page headline around those two.
You're done when: you have a marked stack list, a plan to retire one unneeded token, and a new headline.
Beginner
Competent
Strong
Stack listed.
Tokens limited to two; headline rewritten.
Also measured your winning dimension (load time, price, battery) and put the number on the page.
Connect the ideas: Part four recap
The Kindle, iPod, OP-1, Leica and Game Boy all accept a weakness on the spec sheet. What's the pattern?
Each sacrifices deliberately in service of one experience. This is "less, but better" applied to positioning, and it connects to choosing problems worth solving in Problems Worth Solving.
Part five
Public objects and inclusive objects
Four designs used by everyone, many of them strangers, often in a hurry: a station clock, a kitchen peeler, a school pen and a subway map. They teach what software for "everyone" really requires: legibility at a distance, systems that behave predictably, comfort for the hands that struggle most, and diagrams that tell the truth that matters.
16
The Swiss railway clock: legibility and system behaviour
Taught by Hans Hilfiker (SBB)
A station clock designed to be read from a moving train or across a platform: black bars on white, no numerals, and a red second hand shaped like the guard's signalling disc that sweeps round, pauses at the top, and waits for the signal from the master clock before the minute moves on.
Hans Hilfiker, an engineer at Swiss Federal Railways (SBB), designed the clock in 1944. The red second hand was added in 1953. Its tip is a disc like the Kelle, the signalling paddle a station guard raised to let a train go. Every clock in the network was driven by a central master clock sending a pulse each minute. The second hand is made to go round slightly faster than a minute, in about 58 to 59 seconds, then pause at twelve until the pulse arrives, so all the clocks restart together and the minute hand jumps. Swiss watchmaker Mondaine produces licensed watches and clocks in the design, and in 2012 Apple, after using a strikingly similar face in the iPad Clock app in iOS 6, reached a licensing agreement with SBB.
MakerSwiss Federal Railways (SBB CFF FFS)
DesignerHans Hilfiker
Year1944; red second hand 1953
CategoryStation clock, networked
Study it forLegibility at distance, synchronised system behaviour, one accent
A face built for distance, a hand built for the network. Pins match decisions.
Bars, not numerals. Thick black bars for hours and thinner ones for minutes read faster at distance and from any language than small numbers. Everyone knows where three o'clock is. Cost: precise reading of a single minute takes a moment longer up close.
Black hands shaped as simple bars. No ornament, no tapering tips; maximum contrast and weight on white. The hour hand is wider and shorter, the minute hand longer.
A single red accent, shaped like a signal. The second hand is the only colour, and its disc tip borrows the guard's signalling paddle: a cultural sign of "departure" built into the clock. Cost: none worth naming; it's one of the best accent decisions in design history.
A white face with a black rim. Maximum contrast in daylight on open platforms. The rim frames the clock against busy backgrounds.
Stop-to-go: sweep, pause, release. Because every clock waits for the master pulse, small mechanical differences never accumulate. The pause is visible, and it makes the system's synchronisation something you can see. Passengers learn that the minute changes exactly when the red hand restarts.
One design everywhere. Every station, every platform, the same clock. You learn to read it once. The clock becomes part of the network's identity and trust.
Lab: three ways to move a second hand
Press Run (the clock starts paused if your system asks for reduced motion). Watch the top of the face in stop-to-go mode: the red hand arrives early, waits, and leaves with the minute. Ticking is busy; a smooth sweep never tells you when the minute turns. Which one would you trust to catch a train?
What it left out
Numerals, brand names on the face, decorative hands, a date, and independent timekeeping. Each clock gave up being accurate on its own in exchange for being exactly as accurate as all the others.
Limits and criticism
Without numerals the face is slightly slower for children and for anyone who learned to read time digitally. The stop-to-go mechanism only makes sense inside a synchronised network; a standalone watch that pauses is charming, not functional. And the design is so recognisable that its use without permission became a legal matter.
Don't
Clocks that drift. Each device keeps its own state; people stop trusting all of them.
Do
A master clock. One source of truth; every surface shows the same state, and shows that it's synced.
Steal this for your software
One source of truth, visibly synced. All devices and views should agree, and say so ("Synced just now"). If they can't agree, show which is newer rather than pretending.
Make system behaviour visible. The pause at twelve shows the network working. A subtle "updating" state before refreshed numbers appear, or a timestamp on live data, does the same.
Design for the distance it's read from. A status page, a TV dashboard, a watch face: test at the real viewing distance and speed. Bars and big shapes beat small text.
An accent with cultural meaning. If your accent can borrow a meaning users already have (red for stop or live, green for go), it does double work.
Same design everywhere. Your timestamp format, status badge and date picker should be identical on every screen. Consistency is how strangers learn your system once.
Do
Show "last updated" on any live data.
Test glanceable screens at real distance.
Use a single, consistent format for time across the product.
Don't
Let devices quietly disagree.
Animate continuously when a discrete change is the information.
Use a different status style on each screen.
In the wild
iPad Clock appApple, iOS 6, 2012
Used a face very close to Hilfiker's design, which led to a licensing agreement with SBB. Great public design is also intellectual property; borrow ideas, not faces.
Status pages (for example, GitHub Status)2010s
One public, consistent view of system state with timestamps and history. The station clock of a software service.
Google Docs' "Saving… / All changes saved"Google
A small visible pulse of system behaviour that builds trust in autosave. Show the network working, briefly and quietly.
For the solo creator
Sync is where solo-built apps most often lose trust. Before adding features, make sure every device shows the same state and a "last synced" time. It's unglamorous and it's the difference between a toy and a tool people rely on.
Common mistakes
Silent staleness
Cached data looks current, so nobody knows it's old.
Show age on live data; dim or label anything older than a threshold.
Copying an icon
A famous public design looks free to use.
Learn the principles, design your own form. Check rights before using recognisable designs.
Check yourself
Your stock-portfolio app updates prices every few seconds with a smooth counting animation. Users can't tell whether a number is fresh or stuck. What's the railway-clock fix?
The pause-and-release makes system behaviour visible. b shows when data changes and how fresh it is, and flags failure. a keeps ambiguity, c hides the system, d copies the surface.
Exercise 16.1 30 minutes · on your own product
Make your system's heartbeat visible
Find every place your product shows data that can change or go stale.
For each, decide how a user knows it's current.
Add a quiet timestamp or synced state, and a visible "stale" treatment.
Open your product on two devices; check they agree.
You're done when: every live value has a freshness signal and two devices show identical state.
Beginner
Competent
Strong
Places listed.
Freshness signals added; devices agree.
Stale and offline states designed and tested by switching off the network.
17
OXO Good Grips peeler: design for the hardest hands
Taught by Sam Farber, with Smart Design
A vegetable peeler with a fat, soft, oval handle and flexible fins for the fingers, designed because the founder's wife had arthritis and couldn't grip a thin metal peeler comfortably. Everyone else found it better too.
Sam Farber had retired from the cookware business when he watched his wife Betsey struggle to hold a standard peeler because of arthritis in her hands. He worked with the New York consultancy Smart Design to create a range of kitchen tools with large, soft, non-slip handles. OXO launched in 1990 with a small set of Good Grips tools, the peeler among them. The handle is made of a soft, rubbery plastic (Santoprene), oval so it doesn't turn in the hand, with ribbed flexible fins where thumb and finger press. It's a textbook case of what's now often called the curb-cut effect: design for people with the greatest need and you often improve the product for everyone.
MakerOXO
DesignersSam Farber (founder) with Smart Design
Year1990
CategoryKitchen utensil
Study it forInclusive design, extreme users, the curb-cut effect
Same blade job, different hand. The handle is where the design happened. Schematic.
A large-diameter handle. A wider handle spreads force over more of the hand and needs less grip strength to control. Cost: takes more drawer space and looked clumsy to some buyers at first.
An oval cross-section. A round handle rotates in a weak grip; an oval one stays aligned, so the blade angle stays where you put it.
Flexible fins where the fingers press. Soft ribbed fins give under the thumb and forefinger, providing grip even with wet hands. The handle meets the hand rather than the reverse.
A soft, non-slip material. Santoprene is comfortable, grippy when wet and dishwasher-safe. Cost: more expensive than plain hard plastic or metal.
A hanging hole. A large hole at the end lets you hang it, and it doubles as a visual end-stop. Small, practical, everyday.
A sharp swivelling blade. All the grip comfort is wasted if the blade is dull. Inclusive design still needs excellent core function.
Design for the edge, help the middle. Solving for the hardest case often solves for everyone in a hurry, tired or distracted.
What it left out
The assumption that "assistive" products must look medical. OXO tools are sold as ordinary, attractive kitchen tools; nothing marks them as being "for" anyone. It also left out thinness as a value: many classic utensils prized slim metal elegance over comfort.
Limits and criticism
Big soft handles take up more space and cost more to make. The look, widely copied, became a generic "ergonomic" style that sometimes adds rubber without the research. And for some severe disabilities even a good mainstream tool isn't enough; inclusive design complements, not replaces, specialist assistive products.
Don't
The thin metal peeler. Fine for steady hands and sharp eyes; hard for tremor, low vision, cold fingers or a bumpy bus.
Do
The Good Grips form. Larger targets, clearer labels, more contrast. Better for everyone, essential for some.
Steal this for your software
Design for the extreme user first. Test with a screen reader, with 200% text, one-handed, with a slow network. Fix those and the average experience improves.
Make the handle big. Tap targets at least 44 by 44 points (iOS) or 48 by 48 dp (Android), with spacing between them.
Don't let it rotate in the hand. Stable layouts that don't shift as content loads (no layout jumps); controls that stay where they were.
Grip when wet. Forgiving inputs: accept many date formats, trim spaces, tolerate typos in search, undo mistakes.
No "assistive" ghetto. Don't build a separate "accessible version". Make the main product good for everyone.
Do
Recruit or simulate users with the greatest need.
Raise minimum sizes and contrast across the board.
Keep core function excellent; comfort can't excuse a dull blade.
Don't
Treat accessibility as a final checklist.
Create a separate, lesser version for disabled users.
Prioritise slimness and elegance over use.
In the wild
Captions and subtitlesAcross streaming and social video
Built for deaf and hard-of-hearing viewers, now widely used by people watching in noisy places or quietly in public. The curb-cut effect in software.
Dynamic Type on iOSApple, 2013
System-wide text size that well-built apps respect; useful for low vision, tired eyes and older users. One setting for a need, honoured everywhere.
Frames disability as permanent, temporary and situational (one arm, an injured arm, a parent holding a baby). Extreme users stand in for many everyday situations.
For the solo creator
Accessibility done from the start is cheap; retrofitted, it's expensive. Use semantic HTML or native controls, set minimum target sizes in your components once, and test with a screen reader for ten minutes each release. See Accessible & Inclusive for the full method.
Common mistakes
Designing for yourself
You have good eyes, a new phone and fast internet.
Test with old devices, slow networks, large text and assistive tech every release.
Ergonomic decoration
You add rounded, soft-looking UI and call it friendly.
Comfort comes from size, contrast, stability and forgiveness, not from softness of style.
Check yourself
You're redesigning a medication-reminder app. Which approach best follows the OXO lesson?
Design for the hardest hands and ship it to everyone. a creates a ghetto, b is decoration, d is the thin metal peeler.
Exercise 17.1 45 minutes · on your own product
The hardest-hands test
Set your phone to the largest text size and turn on the screen reader.
Complete your product's core task. Note every failure.
Now try one-handed, standing, with your non-dominant thumb.
Fix the three worst issues in your shared components so the fix spreads everywhere.
You're done when: you have a failure list and three component-level fixes shipped.
Beginner
Competent
Strong
Failures listed.
Three fixes at component level.
Core task fully works with screen reader and largest text, verified after the fix.
18
Lamy Safari: guidance built into the grip
Taught by Wolfgang Fabian, for Lamy
A tough, inexpensive fountain pen designed for young people learning to write, with a triangular grip that places the fingers correctly, a big springy wire clip, and a window that shows how much ink is left.
The German pen maker Lamy introduced the Safari in 1980, designed by Wolfgang Fabian. It was aimed at students: robust ABS plastic (the same family of plastic used in toy bricks), bright colours, and a shape that teaches. The moulded grip section has two flattened faces and a third side, so thumb, index and middle finger fall into a comfortable tripod. The nib is steel and easy to swap. More than four decades later it remains in production with a yearly special colour, and it is many people's first fountain pen.
MakerLamy (C. Josef Lamy GmbH, Heidelberg)
DesignerWolfgang Fabian
Year1980
CategoryFountain pen
Study it forGuidance through form, visible resource, durability, a beginner's tool done properly
Every part teaches or tells. The grip shows where to hold, the window shows ink, the clip shows how it carries. Pins match decisions.
A big wire clip. A bent spring-steel clip, large and visibly springy, grips thick fabric and notebook covers and doesn't snap off. It's also the pen's most recognisable feature. Cost: some find it oversized; it's a deliberate trade of elegance for robustness.
An ink window. A cut-out in the barrel shows the cartridge or converter, so you see ink running low before you run out mid-sentence. The pen shows its own resource.
A triangular grip section. Flattened faces guide fingers into the tripod grip teachers recommend. The shape quietly corrects technique without instructions. Cost: people with unusual grips (including many left-handed writers or those who rotate the pen) find it awkward; the guidance excludes some.
A steel nib that swaps in seconds. Nibs slide on and off, so you can change width or replace a damaged one cheaply. Repair and customisation at the price of a coffee.
Tough ABS plastic in bright colours. A pen for school bags, not display cases. It survives drops and loss is not a tragedy. Colours make it personal and easy to find.
A shape designed around the hand, not tradition. Classic fountain pens copied cigar-like forms. The Safari's form starts from how fingers hold a pen.
What it left out
Gold nibs, precious materials, a smooth round grip, a hidden ink reservoir, and the idea that a fountain pen is a luxury object. It made a beginner's tool without making it a toy.
Limits and criticism
The triangular grip is the main complaint: it helps the intended grip and fights others. It uses proprietary cartridges unless you buy a converter. Some find the plastic look too casual for professional use. Guidance through form is powerful, but whoever sets the guide decides who it fits.
Don't
No ink window. The resource runs out with no warning, at the worst moment.
Do
An ink window. A quiet, always-visible gauge where you work, before it becomes a problem.
Steal this for your software
Guide through form, not instructions. A field shaped for a phone number, a template that shows where things go, a placeholder that models the answer. The interface itself places the fingers.
An ink window for every limited resource. Storage, credits, free-plan limits, words remaining: show a quiet gauge before the wall, never a surprise error.
Swappable nibs. Let people change one part (theme, export format, keyboard shortcut set) without changing everything, and make it cheap to recover from mistakes.
Beginner's tools done properly. A free plan or starter mode should be robust and complete for its scope, not a crippled demo.
Let guidance be escapable. The Safari's grip excludes some hands. Your guided flows need an "I know what I'm doing" path.
Do
Shape inputs to their content.
Show limited resources where people work.
Make the beginner's version durable and honest.
Don't
Rely on onboarding text to teach correct use.
Surprise people with hard limits.
Force one "correct" way with no alternative.
In the wild
Notion and Craft templates2010s to 2020s
Pre-shaped pages that guide structure (a meeting note with headings ready) without a tutorial. Form that places the fingers.
iCloud and Google storage metersApple, Google
Visible usage bars in settings and on some main surfaces, with warnings before the limit. The ink window; best when shown where you work.
Credit-card fields that format as you typeStripe Elements and others
Spaces appear in groups of four, the card brand icon updates. The input's shape guides correct entry.
For the solo creator
An ink window prevents the angriest support emails you'll ever get: "I lost my work because I hit a limit I didn't know about." Add a gauge to any paid or limited resource before you add the next feature.
Common mistakes
Guidance that traps
A wizard teaches beginners but forces experts through every step.
Offer a skip, keyboard shortcuts, or a direct edit view.
Gauges only in settings
Usage meters are easy to put on an account page and forget.
Surface the gauge at the moment of consumption (upload, generate, send).
Check yourself
Your AI writing tool has a monthly word allowance. Users complain about being cut off mid-draft. What's the Safari move?
An ink window where people act, plus graceful behaviour at the limit. b and d move the information away from the moment; c changes the business, not the design problem.
Exercise 18.1 30 minutes · on your own product
Ink windows and finger guides
List every limited resource in your product and where it's visible now.
Add (or sketch) a quiet gauge at the point of use for the most important one.
Find one input where people often make mistakes; reshape it so its form guides the right entry.
You're done when: one gauge and one reshaped input exist in your product or a prototype.
Beginner
Competent
Strong
Resources listed.
Gauge and reshaped input built.
Also tested graceful behaviour at the limit, and the input accepts messy entry.
19
Harry Beck's Tube map and Vignelli's New York: the truth that matters
Taught by Harry Beck, with Massimo Vignelli and Bob Noorda (Unimark)
A transit map doesn't need to show where things are. It needs to show how to get from one to another. Beck's 1931 London Underground diagram threw away geography to show connections; Vignelli's 1972 New York map pushed the idea further and met the limits of how far you can push it.
Harry Beck was an engineering draughtsman who, in his spare time in 1931, drew the Underground as a diagram: lines only horizontal, vertical or at 45 degrees, stations evenly spaced, the crowded centre enlarged and the sparse suburbs compressed. London Transport published it in 1933 after initial scepticism, and passengers took to it at once. In New York, Massimo Vignelli and Bob Noorda of Unimark created a signage system for the subway from the late 1960s, codified in the 1970 Graphics Standards Manual: consistent sans-serif lettering, coloured route discs and a black band at the top of each sign. Vignelli's 1972 diagrammatic subway map was beautiful and logical but drew complaints for its geographic liberties (a beige sea, a square Central Park); it was replaced in 1979 by a more geographic map.
MakersLondon Transport; New York City Transit Authority
DesignersHarry Beck; Massimo Vignelli and Bob Noorda (Unimark)
Study it forAbstraction, choosing which truth to keep, systems of signs
Same network, two maps (a fictional city)
Geographic: accurate, and almost useless for the question "how do I get from Docks to Airport?". The centre is crowded, interchanges are ambiguous, and distances that don't matter dominate.
Diagram: Docks to Central on blue, change, red to Airport. Distance is gone; connection is everything. Beck's trade: give up one truth (geography) to make another (topology) obvious.
A sign as a system. Every sign uses the same parts in the same order. Pins match decisions 4 to 8 below (1 to 3 are on the map).
Map: only three angles. Beck restricted lines to horizontal, vertical and 45 degrees. The eye follows straight lines effortlessly; the diagram reads as ordered. Cost: real routes curve, and some distortions mislead walkers.
Map: even spacing and an enlarged centre. Stations are spaced for legibility, not distance. The dense centre gets room; the outskirts shrink. Cost: two stations that look far apart may be a short walk.
Map: interchanges made obvious. Distinct symbols where lines meet make changing trains the visual focus, because that's the decision travellers make.
Signs: a band and a fixed order. In the New York system, signs share a consistent structure (the band, then route symbols, then words, then direction), so you learn where to look once.
Signs: routes as coloured discs. Each route gets a symbol and a colour, used identically on maps, signs and trains. Colour is backed by number or letter, so it still works without colour.
Signs: one plain sans-serif. Consistent, legible lettering across the system (at first a typeface called Standard, later Helvetica). Uniformity is how a chaotic system looks trustworthy.
Signs: arrows and information at the decision point. Signs say what you need where you need to choose, not before or after.
Map (Vignelli 1972): abstraction pushed further. Every station a dot, every line a clean coloured stroke, the city reduced to a diagram. Cost: New Yorkers know their streets and parks, and the map's geography felt wrong. It was replaced within seven years.
What they left out
Beck left out geography, scale, streets and most landmarks except the river. The New York signs left out the decades of mixed lettering and ad-hoc notices that had grown on the system. Vignelli's map left out almost all geography, which was one step too far for that city.
Limits and criticism
Diagrams shape behaviour: people ride trains between stations that are quicker to walk because the map makes them look far apart. Vignelli's map shows the limit of abstraction: you can remove the truth people don't need, but not the truth they already hold strongly (here, the shape of their own city). Later maps of both systems have negotiated between diagram and geography ever since.
Steal this for your software
Choose the question, then the truth to keep. A dashboard, settings page or onboarding flow should show the relationships people decide with, not every fact. Write the question first.
Make the decision points the visual focus. Interchanges in a map; in software, the step where users choose a plan, a path or an option.
Few angles, few sizes. Constrain your layout grid and type sizes like Beck's three angles. Order reads as trustworthy.
One sign system. Status badges, labels and icons used identically everywhere, in a fixed order, backed by text. Learn once, use everywhere.
Don't abstract away what users already know. If people have a strong mental model (their calendar, their folder structure, their city), respect it. Abstraction that fights a known truth loses.
Do
Name the decision a diagram supports before drawing it.
Back colour codes with letters, numbers or labels.
Put information at the point of decision.
Don't
Show everything because it's accurate.
Abstract away a model users already hold strongly.
Commits drawn as stations on coloured lines, merges as interchanges. Beck's diagram language for version history.
CitymapperCitymapper, 2011
Journey results show legs, changes and walking time as a compact diagram rather than a map first. Answer "how do I get there", then show where.
Progress steppers in checkout flowsMany e-commerce sites
Steps shown as evenly spaced stations regardless of how long each takes. Topology over distance, the right truth for the question "how much is left?".
For the solo creator
When a screen feels confusing, try drawing its "Beck version": boxes and straight lines showing only what connects to what. If you can't draw it simply, the structure is the problem, not the styling. See Information & Data and Structure & Interaction.
Common mistakes
Accuracy as a virtue in itself
Showing everything feels honest.
Honesty is about not misleading on the question asked. Remove what doesn't serve the decision.
Over-abstraction
You simplify past what users recognise.
Keep anchors people know (a river, a familiar label, a known order).
Check yourself
Your project-management app has a timeline view drawn to scale. Users mainly ask "what's blocking what?". What's the Beck move?
Answer the question with the truth that matters (dependencies), and keep the geographic view for a different question (dates). a improves the wrong truth, b adds noise, c removes a valid view.
Exercise 19.1 40 minutes · on your own product
Draw your product's Tube map
Write the top question a user brings to your most complex screen.
Draw the screen's content as a Beck diagram: three angles, even spacing, decision points enlarged.
Compare with the current screen. List what the current screen shows that doesn't answer the question.
Redesign one section to lead with the diagram's truth.
You're done when: you have the question, the diagram, and one redesigned section.
Beginner
Competent
Strong
Diagram drawn.
Section redesigned around the question.
Tested: a user answers the question faster with the new section.
Connect the ideas: Part five recap
The railway clock, OXO, Lamy Safari and the transit maps are used by strangers. What do they share that your public-facing software should copy?
Hard conditions plus consistency equals no instructions. This connects to Accessible & Inclusive and to Words, where consistent labels do the same job as consistent signs.
Part six
Synthesis
Seventeen objects, seven lenses. This part lays them side by side, gives you one master table that turns physical lessons into software patterns, and ends with the exercise that matters most: breaking down an object from your own desk and changing your own product because of it.
20
All objects, seven lenses, one translation table
Taught by all the designers in this guide
Across very different objects, the same few moves repeat: rank by importance and make the ranking visible, show state at rest, borrow behaviour people already have, spend one accent, design a system with a fixed interface, and leave out whatever doesn't serve the one experience you must win.
Read the comparison table by row to remember an object, and by column to see a lens across objects. Columns are where patterns appear: notice how often "what was left out" is the most distinctive cell in a row.
Where each object teaches most. Yellow marks the two lenses where an object is most instructive (our judgement); grey means the lens applies but is less distinctive. Seven of seventeen rows light up "Left out".
The master translation table: physical to software
Thirty translations from this guide, each in the form "physical lesson, software pattern, example". Use it as a lookup when a design problem feels familiar.
#
Physical lesson (object)
Software pattern
Example in software
1
Clear lid shows the machine (SK 4)
Show progress through the content itself
Rows appearing during import; "Saved 3 s ago"
2
All controls in one field (SK 4)
Group a task's controls beside its content
Inline formatting toolbar near selection
3
One warm material (SK 4)
One warm element in a neutral UI
A serif for reading text; a friendly empty state
4
Biggest control = most used (T3)
Size and position by frequency
Shazam's single big button
5
Scale printed on the dial (T3)
Merge control and readout
Slider showing its value on the thumb
6
Keys coloured by role (ET 66)
Colour tokens by role, backed by position
iPhone Calculator's operator column
7
One accent key (ET 66)
One accent per screen, on the completing action
A single primary "Send" button
8
Domed keys feel pressable (ET 66)
Large targets with instant pressed state
44 pt minimum targets, pressed feedback under 100 ms
9
Fixed hole pitch (606)
A spacing scale every component uses
4/8 px spacing tokens
10
Parts that fit since 1960 (606)
Backward compatibility as a promise
Old files open, old URLs redirect
11
Combine or separate (TP 1)
Composable features and surfaces
App + CLI + API working together
12
Accent on the moving hand (Braun clocks)
Accent marks the live, current thing
Calendar's "now" line
13
Alarm hand on the face (Braun clocks)
Show scheduled future state where people glance
"Sends tomorrow 9:00" on the draft
14
Pull cord, borrowed behaviour (MUJI CD)
Map main actions to behaviours users already have
Pull-to-refresh; type to search
15
Pulling is the whole interface (MUJI CD)
Launch performs the main action
Resume last document or track on open
16
"This will do" (MUJI)
Excellent defaults, few settings
iA Writer's tuned typography
17
Emptiness, the open vessel (MUJI)
Neutral chrome, user content as the colour
A blank note with only a cursor
18
Labels instead of logos (MUJI)
Plain information over branding in the product
Prices and limits stated plainly
19
The groove, not the stand (Super Normal)
Change the context instead of adding a tool
Smart default file names and locations
20
Judged after long use (Super Normal)
Evaluate designs after weeks of dogfooding
A "day 30" friction diary
21
Nothing else on the device (Kindle)
Protect the "while" state from interruptions
Focus modes, hidden chrome while reading
22
Battery for weeks (Kindle)
Energy and performance budgets
No polling; light pages; offline first
23
Buttons where the thumb rests (Kindle Oasis)
Core action in the natural hand position
Edge tap zones; keyboard arrows
24
Wheel with acceleration (iPod)
Coarse and fine control in one gesture
Momentum scroll plus an alphabet index
25
iTunes does the heavy lifting (iPod)
Put each task on the device that suits it
Setup on web, daily use on phone
26
Colour-coded knobs (OP-1)
Link controls to their targets by colour or line
Figma's coloured collaborator cursors
27
Four tracks is enough (OP-1)
A stated creative constraint
Three-line journal; 15-second clips
28
Dials readable with the power off (Leica)
Important state visible at rest
Filter chips with counts
29
No red dot, no screen (Leica M-P, M-D)
Remove your brand and distractions from the user's work
Unbranded exports; a distraction-free mode
30
Withered technology (Game Boy)
Boring, proven stack; spend novelty on the product
Server-rendered app on one database
31
Battery light (Game Boy)
One honest indicator for the scarce resource
Storage or credits gauge
32
Stop-to-go sync (Railway clock)
One source of truth, visibly synced
"Synced just now" on every device
33
Bars readable from a train (Railway clock)
Design for the real viewing distance and speed
Big-number dashboards for TVs and watches
34
Fat soft handle (OXO)
Design for the hardest user, ship to all
Large type support; big targets; captions
35
Ink window (Lamy Safari)
Show limited resources where they're consumed
Words remaining beside "Generate"
36
Grip that places the fingers (Lamy Safari)
Inputs shaped to guide correct entry
Card fields that format as you type
37
Topology over geography (Beck)
Show the relationships the decision needs
Dependency views; journey summaries
38
One sign system (Vignelli)
Identical badges, labels and order everywhere
A single status component across the app
Surface
Copies the surface. Recognisable, often worse to use.
Constraint
Re-imposes useful limits. Discipline you chose.
Reason
Translates the reason. Frequency-sized action, visible state, one accent.
Do
Use the master table as a lookup when a design problem feels familiar.
Pick three translations per month and ship them.
Keep adding rows from your own breakdowns.
Don't
Try to apply all thirty-eight at once.
Treat the table as rules; it's a set of tested moves, each with a cost.
Forget lens 7 when you break down new objects.
In the wild: software built from object lessons
Things 3Cultured Code, 2017
Neutral canvas, sparing colour, one obvious add button, careful details. Reads like a Braun and MUJI collaboration in software. Several translations combined coherently.
iA WriterInformation Architects, 2010
Empty vessel, excellent defaults, a "while" state, plain files as the rail. MUJI, Kindle and 606 lessons in one writing app.
HalideLux, 2017
State on the surface, controls under the thumb, a camera's logic without its costume. Leica and T3 lessons translated to glass.
For the solo creator
Print the master table, or keep it as a pinned note. When you plan a release, pick one row from each of three different parts of this guide. Small, varied, steady improvements compound far faster than one big redesign every year.
Common mistakes
Collecting instead of applying
Breakdowns are enjoyable; shipping changes is harder.
Every breakdown ends with one change in your product, dated, or it doesn't count.
Mixing incompatible lessons
You apply OP-1 playfulness to a Kindle-like reading state.
Choose lessons that fit your product's one experience. Play at the edges, calm in the core.
Only famous objects
The canon feels safer.
Your next breakdown should be an ordinary object you use daily. That's where your users' habits live.
Check yourself
Users of your recipe app say it's "busy" and they lose their place while cooking. Which combination of translations fits best?
The problem is focus and reading at distance with messy hands. b combines exactly those lessons. a and c add stimulus; d copies surfaces.
Check yourself
Which statement about the seven lenses is most accurate after this guide?
Absence defines many of these objects (the Kindle's missing apps, the Leica's missing screen, Beck's missing geography). Comparison makes absences visible.
The final exercise
Exercise 20.1 2 hours over two days · an object on your desk and your own product
Break down, translate, ship
Choose. Pick an object on your desk you use daily and have never thought about (a charger, a mug, a notebook, a lamp, a keyboard).
Use it. Do its job three times, slowly, noting every touch, glance and sound.
Compare. Find a cheaper or different version (in a shop, online) to make absences visible.
Break down. Fill the one-page template from chapter 1: seven lenses, five to eight numbered decisions with reasons and costs, one criticism.
Draw it. A schematic sketch with numbered pins matching your decisions.
Translate. Write three translations in the master-table format: physical lesson, software pattern, where in your product.
Ship one. Build the smallest of the three in your product within the week.
Reflect. After a week of use, write three sentences: what changed, what it cost, what you'd do next.
You're done when: you have a one-page breakdown with a pinned sketch, three translation rows, one shipped change, and a three-sentence reflection.
Breakdown with costs and absences; three specific translations; one shipped.
Sketch is clear; translations cite a specific screen; the shipped change measurably helped (time, errors, feedback); reflection names the cost honestly.
Checklist: object lessons, run on your own product
Hierarchy and state (Braun, Leica)
Colour and accent (ET 66, Lubs, railway clock)
Behaviour and defaults (MUJI, Fukasawa)
Focus and resources (Kindle, Game Boy, Lamy)
Systems and the public (606, railway clock, Beck, OXO)
Wrap-up
Ten things to remember
A breakdown names decisions, reasons and costs. If you can't name the cost, you haven't understood the decision.
Translate the reason, re-impose useful constraints as budgets, leave the surface behind.
Size and place controls by frequency of use (T3, iPod, Kindle).
Show state at rest: through clear lids, dials, chips and timestamps (SK 4, Leica, railway clock).
Colour by role; spend one accent, on the live or completing thing (ET 66, Lubs clocks, Hilfiker).
Borrow behaviour people already have; let opening the app be the pull (MUJI CD player, pull-to-refresh).
Aim for "this will do": excellent defaults, few settings, room for the user (MUJI, Super Normal).
Design the system's fixed interface and keep your promises for decades (606, transit signage).
Use mature technology and compete on the column you can win (Game Boy).
Design for the hardest hands and the hardest conditions; everyone benefits (OXO, Lamy, railway clock, Beck).
Self-assessment: I can…
Reflection prompts
Which object in this guide is closest in spirit to your product? Which is furthest? What would your product look like if it moved one step toward the furthest?
What is your product's "left out" column today? What should be in it?
Where do you copy surfaces in your current design, and what reason were you really after?
Practice assignment for the next two weeks
Days 1 to 2. Write your constraint budget (Exercise 2.1) and your settings purge table (Exercise 9.1).
Days 3 to 4. Frequency map and redesign of your main screen (Exercise 4.1), plus the colour-role audit (Exercise 5.1).
Days 5 to 6. Power-off test for visible state (Exercise 14.1) and the hardest-hands test (Exercise 17.1).
Day 7. Ship the smallest three improvements from the week. Write a changelog entry for each, naming the object that inspired it.
Days 8 to 11. Keep the day-30 diary (Exercise 10.1). Meanwhile, do the final exercise (20.1) on an object from your desk.
Days 12 to 13. Protect your "while" state (Exercise 11.1) and add one ink window (Exercise 18.1).
Day 14. Run the "object lessons" checklist in chapter 20. Note your score, and book a weekly 20-minute breakdown in your calendar from now on.
Reading list
Dieter Rams: As Little Design as Possible
Sophie Lovell, 2011, foreword by Jony Ive · the most complete visual record of Rams's Braun and Vitsœ work, with the products in this guide photographed properly.
Less and More: The Design Ethos of Dieter Rams
Klaus Klemp and Keiko Ueki-Polet (eds.), 2009 · exhibition catalogue with many drawings and prototypes; good for seeing decisions in progress.
Designing Design
Kenya Hara, 2007 · MUJI, emptiness and the Horizon campaign in Hara's own words.
White
Kenya Hara, 2010 · a short, beautiful book on emptiness and the colour white; read it before you design your next empty state.
Super Normal: Sensations of the Ordinary
Naoto Fukasawa and Jasper Morrison, 2007 · the ordinary objects they chose, and why. Trains your eye for "settles in" over "stands out".
Naoto Fukasawa
Phaidon monograph, 2007 · the CD player, ±0 and "without thought" projects explained.
The Design of Everyday Things
Don Norman, revised edition 2013 · the vocabulary (mapping, feedback, signifiers) you need to describe what these objects do right.
Mr Beck's Underground Map
Ken Garland, 1994 · the story and evolution of Beck's diagram by a designer who knew the material well.
Helvetica and the New York City Subway System
Paul Shaw, 2011 · a careful history of the subway signage, correcting popular myths about the typeface.
Game Over: How Nintendo Conquered the World
David Sheff, 1993 · a history of Nintendo that includes Gunpei Yokoi and the Game Boy; read it for the trade-offs behind a winning product with a losing spec sheet.
"Choose Boring Technology"
Dan McKinley, essay and talk, 2015 · Yokoi's lesson restated for software teams; essential for a solo creator choosing a stack.
"The Curb-Cut Effect"
Angela Glover Blackwell, Stanford Social Innovation Review, 2017 · why designing for the margin helps everyone; the OXO idea at policy scale.