Software as an instrument

Bell Labs structure, Model M feedback and radio-grade control. How to turn named UX "laws" into instructions a coding agent can follow and check, where applying them blindly makes an interface worse, and 44 principles for tools people can depend on all day.

The gap: finished-looking, still confusing

An agent can produce an interface that looks done: tidy spacing, a nice palette, cards with rounded corners. Then a person sits down to use it and cannot tell which order is blocked, whether the payment went through, or what pressing the big button will change. The screen passed a visual review and failed the job.

Giving Claude a list of UX laws supplies vocabulary. It does not supply decisions. "Apply Hick's law" can mean almost anything, including removing the very controls a professional needs. What makes the vocabulary useful is turning each idea into a concrete design decision, its known exceptions, and a check you can run afterwards that would fail if the decision were wrong. That is the same discipline our testing standards ask for everywhere else: write down what must be true, then prove it.

Not all "laws" are laws

The list mixes things with very different evidence behind them. Treating them as equally universal is the first mistake an agent will make, because the list presents them that way.

Most of these names are collected on Jon Yablonski's Laws of UX. Four on the video's list are not among its thirty entries: visual hierarchy, progressive disclosure, recognition over recall and feedback loops. Recognition over recall is one of Nielsen's ten usability heuristics (NN/G); progressive disclosure is described by Nielsen, 2006. The original research behind each one is in where each principle comes from.

The twenty, decoded

Names are normalized from the video's abbreviations and spelling, and grouped by the problem a person is having. The right-hand column is proposed engineering guidance for an agent, not a claim that the change always improves outcomes.

Finding: where am I, what matters here?

Choosing: what can I do, and which one?

Acting: can I do it quickly and correctly?

Understanding: did it work, how far along am I?

Recovering: what happens when it goes wrong, and how it ends

The peak–end rule rests on a well-known experiment: people held a hand in painfully cold water for 60 seconds, and for 90 seconds where the last 30 were slightly less cold, and most chose to repeat the longer trial (Kahneman and others, 1993). It is about how an episode is remembered, which makes it a reason to get the ending and the worst moment right, not a license to make the middle long.

Recovery has only one entry because the original list barely covers it. That gap is the subject of the engineering layer below.

Five corrections

These are where a literal reading of the list produces worse interfaces.

1. Miller's law does not mean "seven menu items"

George Miller's 1956 paper, "The Magical Number Seven, Plus or Minus Two" (Psychological Review 63, 81–97), is about how much people can hold and judge in their heads at once. Scanning a visible menu is a different task: nothing has to be remembered, because it is all on screen. Laws of UX itself warns against using the "magical number seven" to justify unnecessary design limits (Miller's law). The useful lessons are meaningful grouping (chunking) and reducing what people have to remember, which is recognition over recall again.

Seven is not even the best current number. Nelson Cowan's review of the evidence reads Miller's seven as "a rough estimate and a rhetorical device" and puts the real limit nearer four chunks, under conditions that stop people grouping items (Cowan, Behavioral and Brain Sciences, 2001). Either way, the number describes memory in a lab task, not how many links a menu may have.

2. Attractive is not the same as usable

The aesthetic–usability effect comes from Kurosu and Kashimura's 1995 study at Hitachi: 252 participants rated 26 ATM interface variations, and how attractive they found a design tracked how easy they thought it was more closely than how easy it actually was. NN/G notes that a pleasing design can hide usability problems during testing; in one session a participant struggled through a task and still rated the site easy, commenting on its colors (Moran, NN/G, 2024). The original is a two-author paper in the CHI '95 conference companion, "Apparent usability vs. inherent usability" (ACM). Its full text sits behind the ACM library's bot wall, so we still know its numbers only through NN/G.

The later research is more mixed than the "law" suggests, and it points in both directions:

• Noam Tractinsky repeated the ATM study in Israel (CHI '97), then asked people before and after using a simulated ATM. Aesthetics still shaped how usable they said it was after use, while the system's actual usability did not (Tractinsky, Katz and Ikar, 2000).
• Marc Hassenzahl found the opposite kind of stability: after use, perceived usability moved with real usability problems, while beauty stayed put and tracked identity rather than ease (Hassenzahl, 2004).
• With 88 people completing real tasks on a phone prototype, the aesthetics didn't affect perceived usability at all; usability raised perceived beauty instead, "what is usable is beautiful" (Hamborg, Hülsmann and Kaspar, 2014).

So the effect shows up in some studies and is absent or reversed in others, even among those where people used the system before rating it. That is the strongest argument for the instruction: polish is worth doing, and worth measuring separately, with task completion, mistakes and comprehension on one side and preference on the other.

3. "Under 400 milliseconds" is not a performance spec

The Doherty threshold is usually quoted as "productivity soars" when response is under 400 ms, from a 1982 IBM Systems Journal paper by Doherty and Thadani (Laws of UX). We found the 1982 text, and it doesn't quite say that.

• It is an IBM brief, "The Economic Value of Rapid Response Time", which a retired IBM consultant has posted in full with IBM's permission (Jim Elliott's copy). We found no Systems Journal record of it. The Systems Journal paper behind it is Thadhani's 1981 "Interactive user productivity" (IBM Systems Journal 20(4)), which we did not read.
• The text never mentions 400 ms. It argues for "sub-second" response, and its headline example is IBM's: a programmer completing about 180 transactions an hour at 3 seconds and 371 at 0.3 seconds. The 400 ms figure may be in the brief's charts, which we didn't check. If it isn't, it has no source here.
• It is a case for buying faster IBM systems, built on IBM's own measurements of programmers and engineers at terminals in the early 1980s. Useful history; not a modern benchmark.

Jakob Nielsen's long-standing guidance is more useful for engineering because it separates three different moments (NN/G, from Usability Engineering, 1993):

• About 0.1 s: the response feels instant; showing the result is enough.
• About 1 s: the user's flow of thought stays intact, though they notice the delay.
• About 10 s: the limit for keeping attention on the task. Longer waits need progress feedback, ideally percent-done, and a clear way to interrupt.

So an agent's instruction is not "make it fast" but: acknowledge input within a tenth of a second, deliver something useful within a second where you can, and for anything long, show real progress. A long operation needs honest feedback, never a pretend success state.

4. Progressive disclosure must not hide the essentials

Nielsen describes it as showing the few important options first and the specialized ones on request, and names the hard parts: getting the split right, making the way to the secondary options visible and clearly labeled, and avoiding more than two levels (NN/G, 2006). Hiding a frequent action is not progressive disclosure, it is a different bug. For a busy professional screen, keeping the common controls visible usually beats an exceptionally sparse layout.

5. Treat the rest as hypotheses

Don't turn Hick's law into "always remove choices", the serial-position effect into "put every important thing at the end", or Postel's law into permission to silently guess amounts, dates, recipients or intent. Each is a reason to try something and then check it, not a license to skip the check.

Where each principle comes from

The original research behind each name, what it actually tested, and how far that is from a screen. Most of these were lab tasks: reaction to lights, recall of word lists, dot patterns, cold water. That distance is the reason to treat each one as a hypothesis for your interface. We read the abstracts or the original text where we say so; where we only found the record, the row says that too.

For the three influences: the Bell Labs maxims are quoted from the 1978 Bell System Technical Journal foreword itself. For the keyboard, IBM's 1978 patent for a "buckling spring torsional snap actuator", Richard H. Harris, filed 1977 (US 4,118,611), describes the mechanism's goal in nearly our words: a "non-teasible, snap action, tactile feedback" key, where the sudden drop in force tells the operator the press happened and a click confirms it. The patent doesn't name the Model M, and we found no IBM document tying the two; that link is common knowledge we haven't checked. For the radios, see what the radios actually do, checked against Icom and Yaesu operating manuals.

The engineering layer the list leaves out

The twenty principles are mostly about perception and decision. A tool people depend on also needs these, and an agent should treat them as requirements, not polish:

• Accessibility: full keyboard operation, visible focus, semantic controls, labels, contrast, screen-reader announcements and alternatives to motion. For target size, WCAG 2.2 success criterion 2.5.8 (Level AA) asks for pointer targets of at least 24 by 24 CSS pixels, with exceptions for spacing, an equivalent control, inline text, browser-drawn controls and essential presentation (W3C). The often-repeated 44 by 44 figure is 2.5.5, the stricter Level AAA criterion (W3C), not a blanket rule. See also our accessibility page.
• Recovery: keep what people typed, explain errors in plain words next to the field, support retry, and offer undo where the action allows it.
• Resilience: handle slow connections, partial failures, stale data and interrupted work.
• User control: say what automation will do before it does it, and make consequential actions reviewable.
• Measurement: judge by completion rate, time on task, error rate and recovery, not clicks or visual appeal.

The U.S. Web Design System frames UX as this kind of ongoing practice. Its five principles are: start with real user needs, earn trust, embrace accessibility, promote continuity, and listen (USWDS).

Three design influences

The list above tells you what to avoid. For what to aim at, we borrow from three kinds of equipment that skilled people used all day and trusted under pressure. These are design inspirations we have chosen, read in our own words. We are not claiming that Bell Labs, IBM, Icom or Yaesu shared a doctrine, or that the principles below are a checklist any of them used.

The Model M lesson for software is dependable feedback, not a keyboard click sound on a website. A button responds at once, focus stays where expected, a saved record is actually saved, and pressing a key twice doesn't charge someone twice. The Bell Labs lesson is that a polished interface should rest on mechanisms an engineer can explain when they fail, so an operator knows what to do next. The radio lesson is that an operator should never lose sight of what is happening while changing it.

What the radios actually do

We checked the radio principles against two operating manuals: Icom's IC-7300 full manual, an HF and 50 MHz base station (Icom download page, August 2024 edition), and Yaesu's VX-5R operating manual, a triband handheld (Vertex Standard, 2004). Both are paraphrased here, not reproduced; Icom's terms allow individual use only, so get the manual from Icom.

So the radio column is no longer only our reading: seven of its sixteen principles are features both makers built and documented, a dozen years apart and in very different radios. The rest (semantic color, quiet normal operation, readable legends and the others) remain our interpretation.

Principles for tools worth depending on

The governing idea: make the system understandable, the action unmistakable, and the result dependable. Principles 1 to 28 come from the Bell Labs and Model M side; 29 to 44 add the radio panel.

Correct and predictable

Built from understandable parts

Radio-grade control

Visually, this should feel like a well-made instrument: disciplined alignment, compact but readable spacing, strong numeric typography with tabular numerals for values that change, explicit units, restrained color, and clear boundaries between controls and readings. It should not become a decorative radio dashboard. An on-screen rotary knob earns its place only if it controls better than a slider, a number field or the keyboard; density earns its place only when it helps the operator decide.

Tensions, and how to resolve them

Several principles pull against each other, and so do several of the UX laws. Name the tension instead of letting the agent pick a side silently.

Running example: a service-department route sheet

A service adviser at a dealership spends the day on one screen: a route sheet of today's repair orders, each with a status, a technician, customer messages, approvals for extra work, and payment. Here is how the ideas above become something an agent can build and check.

What not to tell Claude

Apply Hick's law and progressive disclosure to the repair-order screen.

This invites the agent to hide actions and strip the screen down, which is exactly wrong for an adviser who uses it eight hours a day.

What to tell Claude instead

On the repair-order screen, make the next action appropriate to each order's
current status easy to find. Keep frequent actions visible, group uncommon
actions under labeled controls, and show approval and payment status without
opening another panel.

Verify that a service adviser can find the next blocked order, understand
the blocker, and take the correct action.

What the screen looks like as an instrument

• Persistent overview (29, 41): the route sheet stays on screen, one row per order, with status, promised time, technician, waiting-on, approval and payment in fixed columns with tabular numerals.
• A clearly selected order (34): the selected row is unmistakable, and the detail pane names the order it is acting on.
• Detail beside, not instead of (32, 41): selecting an order opens its detail alongside the sheet, so the overview survives investigation.
• Visible communication state (10, 35): last customer message, when it was sent, and whether it was delivered, read or answered, with stale readings marked as stale.
• Semantic, quiet status (37, 42): "waiting on customer approval" has one color and one label everywhere; only genuinely overdue orders get the urgent treatment.
• Frequent actions direct, rare ones layered (43, correction 4): send update, request approval and take payment are always one keystroke or click away; reassigning or voiding sits behind a labeled menu.
• Deliberate, truthful payment (5, 23): taking payment shows pending until the processor confirms, cannot be submitted twice, and never shows "paid" for an acknowledged request. Our services page covers the billing side.
• Postel, carefully (correction 5): a phone number typed with dashes is normalized; an approval amount that doesn't match the estimate is flagged, never guessed.

Acceptance checks, written before the code

• From a fresh load, an adviser using only the keyboard reaches the oldest blocked order and opens its blocker in a small, fixed number of keystrokes. A design that hides "blocked" behind a filter fails this.
• Approval and payment status for every visible order is readable without opening anything.
• Submitting payment twice in quick succession creates one charge.
• When the messaging provider is down, the route sheet still loads and says plainly that messages can't be sent right now (19).
• A half-written customer message survives a page reload (16).
• Every target meets WCAG 2.2 at Level AA, including 2.5.8's 24 by 24 CSS pixels or its spacing exception.
• In a short session with real advisers, measure completion, time and errors on "find and resolve the next blocked order", separately from whether they like how it looks.

A repeatable workflow

1. Observe the task. Who uses the screen, how often, under what pressure, and what they are trying to get done.
2. Identify the friction. Where people hesitate, misread, mis-click, lose work or lose their place. Name the principle only after naming the problem.
3. Propose a change as a design decision plus the check that would prove it wrong.
4. Implement the smallest change that passes the check.
5. Evaluate with real tasks: completion, time, errors and recovery. Keep what helped, and revert what didn't.

Here is a block you can paste into an agent's instructions, the closest thing on this page to the Markdown the video promised. The full version, with a check for every rule, is instrument-design.md.

## Interface work

- Start from the user's task and the friction you observed, not from a named UX law.
  Name a principle only as the reason for a specific, checkable decision.
- Treat UX "laws" as hypotheses. Don't remove controls a frequent user needs,
  don't hide essential actions behind disclosure, don't guess ambiguous input.
- Every action shows pending, success and failure honestly. Acknowledge input
  within ~0.1 s; show real progress past ~10 s; never show success before it happened.
- Keep the operating context visible: what is selected, what mode, what the next
  action will affect. Keep the overview while showing detail.
- Full keyboard operation with visible focus. WCAG 2.2 AA, including 2.5.8
  target size (24x24 CSS px or its exceptions).
- Preserve the user's work through errors, reloads and failed dependencies.
- Consequential actions are deliberate, reviewable, and can't fire twice.
- Write acceptance checks before the code, as tasks a real user performs,
  and report completion, errors and recovery separately from appearance.

The standard to hold the result to: Could a skilled person use this eight hours a day, trust it under pressure, see what is happening, make a precise intervention, verify its effect, and know how to recover when it breaks?

How we checked

Every factual claim on this page links to the source we read on 20 October 2026, using our own research toolkit, apps/intel, with honest sources only: official APIs and pages whose robots.txt allows reading.

• Citations: all 12 pages the first version cited were fetched again and checked, phrase by phrase, for the facts we took from them (target sizes and levels, the five USWDS principles, the response-time limits, the disclosure-depth warning and the rest). All matched.
• Underlying studies: Crossref and OpenAlex for the original paper behind every principle that has one (27 papers, 1923 to 2014), with abstracts read where OpenAlex has them; RFCs 760, 761, 793 and 9413 from the RFC Editor; Wertheimer in the York University classics translation; Nielsen's 2000 and 1994 articles; IBM's buckling-spring patent on Google Patents. Each row of the sources table says whether we read the text, the abstract, or only the record.
• Links: all 47 outside links on the page were checked on 20 October 2026: every web page answered 200 and every DOI resolves in Crossref.
• The 400 ms claim: a web search through our SearXNG found the full 1982 IBM brief; we searched its text for every mention of 400, tenths of a second and its publication details.
• Source grades: bin/grade put the peer-reviewed papers and USWDS at B and everything else at E, because it grades by domain and doesn't know these sites. Re-graded by hand: the W3C pages are the standard itself (A); the Crossref records and the Internet Archive copy of the Bell System Technical Journal are faithful copies (B); NN/G and Laws of UX are expert summaries, not the research (C); the IBM brief is a copy on a personal blog, posted with IBM's permission (C). bin/trace wasn't useful with 20 records and no repeated stories.
• Challenge: bin/challenge ran on the page's main conclusion with a small local model (qwen3:4b), since hosted credit is used up. Its counter-case cited a 2018 study with precise percentages that we could not find and believe it invented, so that was discarded. One point survived: saying later work "reversed" the aesthetic–usability effect would overclaim, so the page says the findings point both ways.

Still not verified, and labelled where used: the numbers from the Kurosu and Kashimura study (full text behind the ACM library's bot wall, which we don't get around); the charts in the IBM brief; Thadhani's 1981 paper; the German originals of Wertheimer and von Restorff; Ebbinghaus; the Tesler interview; and nine of the sixteen radio principles, which have no counterpart we checked in the two manuals. We have added no conversion figures, and no historical claims about how Bell Labs, IBM, Icom or Yaesu designed things beyond what the BSTJ foreword, IBM's patent and the two radio manuals say; the three influences are our own design reading. The effect sizes quoted are each study's own, and IBM's 180 versus 371 transactions an hour is IBM's own claim. We did not see the video creator's promised Markdown instructions.