By Mehdi HassanHow do you design for power users and beginners at the same time?
You design for both by layering, not by choosing. The default interface is clear and labeled so a first-time user can succeed, and a second layer of shortcuts, commands and bulk actions sits on top for people who use the product every day. Nothing a beginner needs is hidden, and nothing an expert wants is slow.
The mistake is building two products: a simple mode and an advanced mode. Modes split your design effort, confuse support and strand users in the middle. A single interface with layered paths lets people move from novice to expert gradually, at their own pace. Our SaaS product design guide explains how this fits into the wider product structure.
Think of it as three layers that every important action can have:
Layer | Who it serves | Examples |
|---|---|---|
Visible | Everyone, especially beginners | Labeled buttons, menus, clear empty states |
Disclosed | Intermediate users | Advanced settings, more options menus, filters |
Accelerated | Power users | Keyboard shortcuts, command palette, bulk edit |
What is progressive disclosure in SaaS and how do you apply it?
Progressive disclosure in SaaS means showing the few options most people need first and revealing advanced options only when a user asks for them. It reduces the number of decisions on a screen without removing capability. Done well, beginners never feel overwhelmed and experts never feel limited.
Rank options by frequency
List every control on a screen and mark how often each is used. Analytics helps if you have it. If not, ask five real users which options they touch weekly.
Keep the top tier visible
The few options most people need stay on screen with clear labels. Everything else moves one step away.
Group the rest behind one clear entry point
Use an 'Advanced' section, a 'More' menu or an expandable panel. One entry point per screen, named for what's inside.
Remember what users open
If someone expands advanced filters every visit, keep them expanded. Disclosure should adapt to behavior.
Never hide destructive or critical states
Errors, billing problems and permission limits stay visible. Disclosure is for options, not for warnings.
Filters are the clearest test case. Our guide to search and filter UX shows how to start with three or four common facets and reveal the rest on demand. The same logic drives navigation depth, covered in our article on SaaS information architecture.
How should a command palette fit into a SaaS product?
A command palette is a keyboard-triggered search box, usually opened with Cmd+K or Ctrl+K, that lets users jump to any page or run any action by typing. It is the single most useful accelerator for power users, because it replaces memorizing dozens of shortcuts with one.
It works only as a second path. If an action exists only in the palette, beginners will never find it. Rules we follow:
- Mirror the visible UI. Every command should also exist as a button or menu item somewhere.
- Use the same words. If the button says 'Archive project', the command says 'Archive project', not 'Hide'.
- Show context first. On a project page, project actions appear above global navigation.
- Show shortcuts inside results. Each result displays its keyboard shortcut, so the palette teaches faster paths.
- Respect permissions. Don't list actions the user can't take. See our guide to roles and permissions UX.
Our dedicated guide to command palette design goes deeper on ranking, fuzzy search and empty results.
Which keyboard shortcuts should a SaaS app have?
A SaaS app should have shortcuts for the handful of actions experts repeat most, plus navigation and the command palette. Start small: a set you can teach is better than a long list nobody reads. Pick from frequency data, not from what feels clever.
Category | Typical shortcut | Notes |
|---|---|---|
Command palette | Cmd/Ctrl + K | Widely expected in modern SaaS |
Search | / | Common convention for focusing search |
Create new item | C or N | Pick one and use it everywhere |
Navigate lists | J / K or arrow keys | Support arrows even if you add J/K |
Open selected item | Enter | Matches expectations from lists and menus |
Close or cancel | Esc | Must work in every modal and panel |
Shortcut help | ? | Opens a sheet listing every shortcut |
How do you teach power-user features without annoying beginners?
You teach power-user features in context, at the moment a user does something the slow way. Tours and pop-ups that list shortcuts on day one get dismissed. A quiet hint that appears after someone clicks 'Archive' for the tenth time, showing the shortcut, actually changes behavior.
- Show shortcuts in tooltips and menus. Put the key next to the label, the way desktop apps do.
- Hint after repetition. After a user repeats a slow action several times, offer the fast path once, then stop.
- Offer bulk actions when selection grows. When someone selects multiple rows, show bulk edit right there.
- Make the help sheet one key away. A '?' sheet lets curious users explore on their own terms.
The words matter as much as the timing. A hint that reads 'Pro tip: press E to archive' respects the user. One that reads 'You're doing it wrong' doesn't. Our guide to UX writing for SaaS covers tone for hints and empty states.
How do you build shortcuts and a command palette in React?
Build both from one action registry. Each action is defined once, with an id, a label, an optional shortcut, a permission check and a handler. Menus, buttons, the command palette and the keyboard listener all read from that registry, so labels and behavior never drift apart.
- One registry. A typed list of actions, often grouped by page context, that components register and unregister as they mount.
- One global key listener. Attach a single keydown listener at the app root, check the event target to skip inputs, and look up the action by key.
- A proven palette component. Open-source React libraries such as cmdk handle filtering, keyboard navigation and accessibility, so you only design the content.
- Accessible semantics. A palette is a combobox with a listbox. Follow the WAI-ARIA combobox pattern so screen readers announce results.
- Platform-aware keys. Show Cmd on macOS and Ctrl elsewhere, using the KeyboardEvent metaKey and ctrlKey properties.
For example, suppose you add bulk archive to a project list
For example, suppose a project tool adds bulk archive. In a single registry, you define one action: 'Archive project', shortcut E, allowed only for editors, handler calls the archive endpoint with an optimistic update.
The row menu shows 'Archive project' with E beside it. The command palette lists the same label with the same shortcut when a project is selected. The keyboard listener fires the same handler when E is pressed outside an input. When a user selects five rows, the bulk bar shows 'Archive 5 projects', reusing the same action with a count. One definition, four entry points, zero drift.
What makes a SaaS product feel powerful but still simple?
A product feels powerful but simple when its defaults are opinionated, its visible surface is small and its depth is reachable in one step. Users judge simplicity by the first screen and power by how fast they can move after a month. You need both to retain a team as its members grow from first login to daily use.
Our B2B SaaS UX principles list the broader rules. For power users specifically, a quick check:
- Can a new user complete the core task using only visible, labeled controls?
- Can an expert complete the same task without touching the mouse?
- Does every shortcut have a visible equivalent?
- Do advanced options stay one click away, and remember when they've been opened?
- Are shortcuts discoverable through tooltips, menus and a help sheet?
