Keyboard navigation
The composer a power user can drive without touching the mouse.
The fastest users of your product never see your cursor. They press keys. They jump from turn to turn without the visible apparatus you designed for the click-first user. If your product makes them reach for the mouse, it is slower than a worse product with a richer keymap.
Keyboard navigation is not a setting. It is a statement about how much you respect the attention of the person using your product. A good keymap is a second interface, laid quietly under the first, visible only when asked.
"Every pointer-only affordance is a tax on attention. Charge it sparingly."
Three layers, one question mark.
The discipline I'd ship has three layers. A global layer for cross-surface actions (focus the composer, open the cheatsheet, switch workspaces). A composer layer for in-box actions (send, insert slash, attach). A transcript layer for moving between turns (next turn, edit, fork). And one key that explains all of it: a question mark that opens the cheatsheet with the currently-active bindings.
The cheatsheet is not an afterthought. It is the interface. A user who knows the cheatsheet exists and how to reach it is a user who will learn twenty shortcuts in their first week.
Press a shortcut above. Nothing captured yet.
Keys are the muscle memory of trust.
A shortcut is a promise. Press this, and this predictable thing will happen. Products that keep that promise at the keyboard layer inherit a particular kind of loyalty — the loyalty of people who never have to look where their hands are going.
Products that break it — by moving a key, overloading a meaning, silently adding a modifier — erode the single most durable form of user-product intimacy there is.
The keymap I'd ship.
- One key per verb. Do not overload a single chord across contexts. ⌘ Enter sends. ⌘ Shift Enter sends with a different route. ⌘ Option Enter does not exist unless you have a fourth route worth remembering.
- Show the keys on focus. A dim keycap next to an element on focus is worth a dozen tooltips. It teaches shortcuts the way a good menu teaches commands — by showing them next to where the action would happen anyway.
- Record and surface. A macro recorder that watches a short sequence and offers to bind it to a key is the fastest way to learn your own keymap. It also exposes the parts of your product you use the most.
Shortcut rot.
The single most common failure of a keyboard-first product is that the keymap stops being true. Someone ships a new feature, the shortcut they pick collides with an existing one, and quietly, the old binding is demoted without telling anyone. The cheatsheet still lists it. The product no longer honors it.
A keymap is a public contract. Own its versioning.
What this pattern gets wrong when it gets wrong.
- Ambiguous state
- Running, done, errored, paused all look the same. The user has to infer from context.
- Empty disclaimer
- A legal-feeling warning that carries no specific information about this particular response.
Three shipping variants worth copying.
- A discoverable cheatsheet behind ? that lists every active binding
- Per-field shortcuts shown as dim keycaps on focus
- A key-recording macro that teaches new verbs back to the user