Why ⌘K bars work
A ⌘K bar collapses navigation, search, and AI actions into one keyboard-driven surface. It works because users type intent, not categories — and the bar is the only surface that lets them.
Patterns that ship
- Unified ranking — local results first, AI streams in.
- Context-aware empty states — show top actions for the current page, not generic prompts.
- Inline confirmation — destructive actions pause for a single keystroke, not a modal.
- Result types as chips — Page · Doc · Action · AI — so the user knows what enter will do.
- Recents at the top — the same action twice in five minutes is the most common pattern.
Antipatterns
- Tabs across the top splitting search from actions. Users won't switch tabs; they'll close the bar.
- Blocking the panel on a slow AI call.
- Mouse-first design with tiny click targets.
- Showing 50+ results. Cap at 8-12; the rest are noise.
Latency budget
Open to first paint: 50ms. Keystroke to ranked update: 16ms (one frame). AI suggestion stream start: under 500ms.
FAQ
- Should the ⌘K bar do search or actions?
- Both, ranked together. Users don't separate 'find a thing' from 'do a thing' in their head — they type intent. The best bars unify navigation, search, and AI actions into one ranked list.
- How do I keep latency under 100ms when AI is involved?
- Render local results (recents, navigation, static actions) instantly, then stream AI suggestions as they arrive. Never block the panel on the model.
- What's the right empty state?
- Show 3-5 high-value actions specific to the user's current context — not a generic 'try asking…' list. Context-aware empty states convert 2-3× better than generic ones.
- Should results be keyboard-first?
- Yes. Arrow keys, enter to invoke, escape to dismiss, tab to filter. Mouse is a fallback. Power users live in the keyboard; designing for the mouse loses them.