Command palettes: patterns for the Cmd-K era

Every product tool of the last five years eventually gets the request: "can we have Cmd-K, like Linear?" Sometimes it's the right feature. Sometimes it's a fuzzy search box over six page titles wearing a power-user costume, shipped because the founders use Raycast and the demo looks good. The palette is not the shortcut. The palette is the visible tip of a much deeper commitment: your product has a complete, ranked, keyboard-addressable registry of everything a user can do. Teams that build the registry get a great palette almost for free. Teams that build the palette without the registry get a modal that lies.

Here's how we decide whether to build one, and the patterns that separate the palettes people live in from the ones people open once.

When a palette earns its keep

Three tests, and we ask them in order. Fail one, and a palette is premature:

Action surface area. Count the verbs: create, invite, export, archive, assign, refund, run, publish. If a daily user has fewer than ~25 distinct actions available, your existing menus can hold them all without depth, and a palette adds a second place to maintain the same list.
Cross-entity navigation. Palettes shine when users constantly jump between things — projects, customers, documents — not just pages. If your product is a single long workspace, there's nothing to jump to.
Return frequency. Palettes are a returning-user feature. They reward muscle memory, and muscle memory needs repetition. A monthly-reporting tool will never build it; don't pretend otherwise.

The Northwind Ledger dashboard passed all three — ninety-plus actions across ledgers, dozens of client entities, and accountants who log in before their coffee. The palette we shipped there is the second-most-used input method after the tables themselves. A wellness app we audited the same year failed test one by a factor of ten; we talked the client out of the palette and into better navigation, which is the outcome you want when the renderer is honest.

Ranking is the product (fuzzy match is not ranking)

The most common failure mode: the team wires a fuzzy-find library across page titles, ships it, and wonders why adoption stalls at 4%. Fuzzy match answers "does this string approximately contain those characters". Ranking answers "what did this user almost certainly mean". The second question is the product.

A ranking function we keep returning to has four factors, multiplied:

Match quality — where the match lands (word-start beats mid-word), and how much of the label it covers.
Recency — commands and entities the user touched recently. Time-decayed, not binary.
Frequency — per-user command frequency. The accountant who runs "reconcile" forty times a week should get it from typing "re".
Context — where the user is. Inside a project, "invite" should mean "invite to this project", not the global invitation screen. Context weighting is the single biggest jump in perceived intelligence and the one most palettes skip.

Two rules on top. Determinism: identical queries from identical state return identical orderings, always — a palette that re-ranks under your fingers teaches users to read instead of trust, and reading is the opposite of flow. And destructive demotion: irreversible commands (delete workspace, void invoice) never rank above safe ones on ambiguous queries. A user who typed "del" hunting for a deliverable should never, under any ordering, have delete-client one Enter away.

This is the same discipline as good product search, compressed into milliseconds and keystrokes — the relevance-vs-recency trade-offs in our search UX notes apply verbatim, just with a harsher latency budget.

A grammar, not a flat list

Weak palettes are a flat list of links. Strong palettes have a grammar, and users pick it up without being taught:

Nouns find things: "acme", "q3 report", "invoice 1042" — typed as naturally as thought.
Verbs do things: "create", "invite", "export". Verbs without arguments resolve to sensible defaults or prompt for the missing one inline ("Create invoice… for which client?").
Verb-on-noun chains once a noun is in context: select the project, then the palette offers "rename", "archive", "add member" — the same secondary pattern as macOS's Services menu or Slack's message-context commands.

Results should be sectioned, not blended: Actions first (they're the user's intent more often than not when a verb was typed), then matching entities (clients, projects, documents), then navigation last. Three sections with visible labels beat one perfect-blend ranking, because blending makes sections invisible and users need to know the grammar exists to trust it.

One craft detail that pays for itself: every command shows its scope ("Archive — this project") and, where it exists, its keyboard shortcut — which turns the palette into the product's own shortcut tutor. The palette teaches the shortcuts that eventually replace it. That's a feature, not a leak.

Keyboard ergonomics, because that's the point

A palette that's sluggish or fidgety is worse than none. The non-negotiables we test on real hardware, not a plugged-in MacBook Pro:

Focus discipline. The query field is focused on open, fully selected state preserved on reopen, and Esc closes from anywhere without side effects. Reopening a palette to yesterday's stale query is a small betrayal users notice and never mention.
Arrow keys traverse, Enter executes, Tab completes partial chains ("create…" Tab into argument entry). Enter-on-destructive requires the query to have matched the destructive command exactly — no accidental first-hit execution.
Latency you can feel. Open-to-first-paint under 50ms, results under 100ms per keystroke, and the palette must work against a locally cached command list — the registry is static-ish and should never wait on the network. Entity results can stream in; commands must be instant.
Zero-mode value. An empty query should show recent commands and context-relevant actions, not a blank void. The empty state is teaching surface, as always — we make the same argument about empty states elsewhere.

The broader engineering checklist for keyboard-first products — focus traps, roving tabindex, shortcut scoping, screen-reader announcements for live result counts — lives in our keyboard-first interfaces piece; the palette is where every one of those disciplines collides in one component.

Discovery for the 90% who'll never press Cmd-K

Here is the uncomfortable adoption truth: in most products, 5–15% of users ever trigger the palette, and they overlap heavily with the users who needed it least. So why build it? Because of what it does for everyone else — if you use it as teaching surface rather than a secret society.

The pragmatic moves: print the shortcut in the search placeholder ("Search or command — ⌘K"). Badge menu items with their ⌘K-typed equivalent on hover. After a user repeats a three-click navigation sequence three times in a session, surface a single, dismissible hint ("⌘K then 'billing' does that"). One hint per session, ever. The moment palette evangelism becomes nagging, you've built the Clippy of productivity features.

And the deeper benefit: the palette forces the registry, and the registry upgrades everything. Once every action lives in a typed command registry — with id, label, keywords, scope, permission requirement, handler — the menus, the keyboard shortcuts, the palette, the context menus and the mobile quick-actions all render from one source. The palette is just the most demanding consumer. We've seen teams discover entire permission bugs this way: the palette listed an action the UI had forgotten to gate.

Mobile equivalents

There is no Cmd on a phone, so teams drop the pattern entirely — which throws away the registry's value precisely where screen space makes deep navigation most painful. The equivalents that work: a persistent quick-action bar contextual to the current entity, long-press on tab icons for top actions, and a bottom-sheet command sheet triggered from a search field that shares the palette's ranking. The registry and ranking logic port across whole; only the chord is different. Design the registry once and the mobile surface is a renderer.

Implementation in one paragraph

One typed command registry. Handlers shared with the buttons and menus they mirror — idempotent, permission-checked, tested once. Palette state (recency, frequency) stored per-user, locally first. Results streamed in two lanes: instant local commands, async entities. Fuzzy match as a scoring input, never as the ranking. And instrumented from day one: queries typed, results selected, abandonment rate — the progressive disclosure argument holds here too, because a palette is disclosure by query, and you can only tune what you measure.

A command palette done properly is the moment a product admits its users are better at their jobs than your IA is at describing them. Build the registry. Respect the ranking. Everything else is a modal.

Key takeaways

Build a palette only when action count, cross-entity navigation and return frequency all justify it — otherwise invest in navigation.
Ranking (match × recency × frequency × context) is the product; off-the-shelf fuzzy match is a false start.
Give the palette a grammar — nouns, verbs, verb-on-noun — with sectioned results and deterministic ordering; demote destructive commands on ambiguous queries.
Commands must be instant and local; only entity results may touch the network.
Use the palette as teaching surface (shortcut badges, one-hint-per-session) — its real value is the command registry every other UI renders from.
Mobile gets the same registry through quick-action bars and bottom sheets; only the trigger changes.

FAQ

Should every B2B SaaS have a command palette now? No — it's table stakes only where the three tests (action surface, entity jumping, daily return) pass. An invoicing tool? Absolutely. A booking widget? Never. Shipping one where it doesn't fit adds a second, weaker menu that drifts out of sync with the first.

Do we need natural-language or AI command parsing? Keyword-ranked commands cover the overwhelming majority of intent, deterministically, at zero latency. LLM parsing earns its place when commands take rich arguments ("invoice Acme for March, net 30") — and even then it should sit behind the typed grammar as a fallback lane, never replace it. A palette that hallucinates an action is worse than one that shrugs.

How many commands is too many? Past ~120 commands, maintainability of labels and keywords becomes the bottleneck, not the UI. If everything is a command, ranking carries the weight — which is fine, provided recency and frequency weighting are per-user. Audit quarterly for dead commands the way you'd prune a nav.

What's the fastest honest version to ship? Commands only (no entity search), local registry, four-factor ranking minus context weighting, Esc/arrow/Enter ergonomics, one teaching hint. That's two focused weeks for a senior pair — and it's genuinely useful, which "palette-shaped object" full of unranked page links never is.