Designing command palettes for product work

A command palette can make a product feel fast. It can also become a novelty drawer: a place where every team adds a shortcut because the surface exists.

The difference is whether the palette is designed around repeated work.

I like command palettes for products where users already know the system and need to move between objects, actions, and views without losing context. Admin tools, design tools, knowledge bases, CRMs, and developer products can all benefit. A simple marketing site probably does not need one.

Start with intent, not inventory

The first version should not include every route and every button. It should include the things people already hunt for.

Useful commands often fall into a few groups:

• Go to a known object.
• Create a common object.
• Run a frequent action.
• Change the current view.
• Open help for the current surface.

That is enough. If the palette starts as a mirror of the whole sitemap, the user has to search through product structure instead of product intent.

Make results explain themselves

A command result needs more than a label. "Settings" is weak if the product has workspace settings, billing settings, notification settings, and integration settings.

I prefer results with a title, a small type label, and context. "Invite teammate" can show "Action - Workspace". "Acme Corp" can show "Customer - Enterprise plan". "Payment failures" can show "Report - last 30 days".

The context keeps the palette from becoming a guessing game.

Keyboard behavior is the product

If the keyboard interaction is bad, the palette is bad.

The basics matter: focus the input on open, close on Escape, preserve the previous focus target, move through results with arrow keys, select with Enter, keep the highlighted result visible, and avoid trapping the user when results are empty.

The empty result should still be useful. It can offer "Create new project named ..." or "Search docs for ...". But it should not pretend that no result is the user's fault.

Scope commands to the current page

The best palettes understand context. On a customer page, show customer actions. In a dashboard, show dashboard filters and reports. In a design system, show components and contribution docs.

Global commands are useful, but page-scoped commands make the palette feel like part of the product instead of a floating launcher.

Keep destructive actions out of the fast path

I am careful with commands that delete, send, publish, charge, or change permissions. The palette can initiate those actions, but the confirmation should make scope and consequence clear.

Speed is not the same thing as safety. A command palette should reduce repetitive navigation, not make dangerous actions easier to trigger accidentally.

What I would ship first

For most products, I would ship:

• Open with Command-K or Control-K.
• Search navigation, objects, and common create actions.
• Show recent objects before the user types.
• Add page-scoped actions where they clearly help.
• Track searches with no results.

That last point is important. No-result searches are product research. They reveal language gaps, missing shortcuts, and workflows the product does not support well yet.

A good command palette does not make the product look advanced. It makes the user's next move obvious and fast.