A field laboratory of the principles your textbook describes. Every section below is a working instrument — drag the targets, race the menus, fix the broken UI, narrate a screen reader. The site itself is the proof you understood the material.
┌──────────────────────────────────────┐
│ ╱╲ ╱╲ ╱╲ ╱╲ ╱╲ ╱╲ │
│ ╱ ╲ ╱ ╲ ╱ ╲ ╱ ╲ ╱ ╲ ╱ ╲ │
│╱ ╲╱ ╲╱ ╲╱ ╲╱ ╲╱ ╲ │
└──────────────────────────────────────┘
MT = a + b · log₂(D/W + 1)
Big targets, close by, are cheap. Small targets, far away, cost dearly. Place the most-used buttons where the user already is.
RT = a + b · log₂(n + 1)
Click START. A target tile will glow — tap it as fast as you can. Try every n. Watch your time grow.
Mint dashes = predicted (log₂). Amber dots = you. Long menus aren't free — group, hide, chunk. A 3-deep menu of 4 beats a flat menu of 64.
the handle says grab me · the sign says push. they disagree. which one will you trust?
flat plate · nothing to grab · no sign needed. the design itself answers the question.
Click a glowing burner. Then click the knob that controls it. Bad mapping forces you to read labels. Good mapping is invisible.
Both buttons "work." One leaves you wondering.
Every interaction with software decomposes into five primitive operators. Tap one below to add it — or run a guided scenario on the right to see a real task play out, step-explanation and tokens in view at the same time.
The point of KLM: you can predict expert task time before you build a single screen. If your design needs five M-operators just to get to the user's goal, the design is asking too much. Strip mental steps with sensible defaults, recognition over recall, and consistent placement.
Computed from WCAG 2.x relative luminance. Aim for AAA on body whenever the design allows.
What a real user hears. If it sounds like nonsense to you, fix the labels — not the screen reader.