How Do You Design for Power Users Without Losing Beginners?

How Do You Design for Power Users Without Losing Beginners?

You stop treating them as two audiences and start treating them as two paths to the same action. Beginners get a visible, obvious route. Experts get a faster route to the identical outcome. The interface does not change. The number of ways to reach a result does.

Almost every SaaS team we work with hits this wall somewhere around year two. The product that felt clean at launch now has forty features, the daily users want to move faster, and the trial users are getting lost.

The instinct is to add a settings toggle called something like "advanced mode". That usually makes both groups worse off. Here is the framework we use instead.

Why Do Teams Treat This as a Trade-Off?

Because the two complaints arrive on the same day and sound opposite. Sales says the product is too complicated to demo. Your best customers say it takes too many clicks. It looks like one group has to lose, so teams pick a side and alternate every eighteen months.

The trade-off is real only if you assume there is one path through each task. Once you allow two paths, the conflict mostly dissolves. A menu item and a keyboard shortcut can do the same thing without competing for space.

What genuinely does not scale is surface area. Every control you put on the default screen costs every user something, forever. So the discipline is not about hiding things from beginners. It is about deciding what earns a permanent place on screen.

What Does the Research Say About How Expertise Grows?

Slower than product teams assume. Jakob Nielsen's 2013 article for Nielsen Norman Group, "User Expertise Stagnates at Low Levels", argues that users learn a basic set of features early, then plateau, and rarely expand much after that, even across years of use.

His summary of the cause is blunt and worth remembering: learning is hard work, and users do not want to do it. The article cites Steve Draper's 1984 research on Unix, which found it took at least seven years to become a skilled Unix system administrator.

The design implication is uncomfortable. Most of your users will never become power users, no matter how good your documentation is. So a plan that depends on people graduating into the advanced interface is a plan that will not run.

Nielsen's recommendations lean on making features visible and discoverable, using clear signifiers, offering just-in-time tips in context, treating error messages as teaching moments, and making exploration safe with undo and a working back button. Our piece on undo for destructive actions covers that last one in detail.

What Is Progressive Disclosure, Exactly?

It is deferring secondary options to a subsidiary screen so the primary options get the user's attention. Nielsen defined it for NN/g in December 2006, and the definition has aged well. Core options show by default. Advanced or rarely used ones live one level down.

NN/g claims it improves three of the five usability components: learnability, efficiency of use, and error rate. Note that efficiency is on that list. Hiding rarely used options helps experts too, because they stop scanning past controls they never touch.

That is the part teams miss. Progressive disclosure is usually pitched as a kindness to beginners. It is equally a service to experts, who lose time to visual noise more than they lose it to clicks.

It is also distinct from staged disclosure, which NN/g describes as presenting features sequentially through the steps of a task. Progressive disclosure is hierarchical and optional. Staged disclosure is linear and mandatory, like a checkout flow.

How Do You Decide What Goes on the Second Level?

By frequency, measured rather than guessed. NN/g recommends task analysis, field studies, frequency-of-use statistics, and observational usability testing to work out which features belong at each level. The key word is statistics. Most teams sort by how proud they are of a feature.

Our working rule is a rough one. If fewer than one in five sessions touches a control, it does not belong on the default screen. If more than half of sessions touch it, it must be visible without a click. The band in between is where judgement lives.

Two failure modes recur. The first is hiding something frequent because it is visually ugly, which quietly taxes everyone. The second is keeping something rare because one large customer complained once, which is how default screens become dashboards nobody understands.

The label on the disclosure matters as much as the split. NN/g stresses clear progression mechanics and labelling that sets expectations for what the secondary options contain. "More" tells a user nothing. "Advanced export options" tells them whether to click.

What Is an Accelerator and Why Do Experts Need One?

An accelerator is a UI feature that speeds up an interaction or process, as Rachel Krause and Aurora Harley defined it for NN/g in October 2024. It is an alternate route to a task that already exists, not a new capability. That distinction is the whole trick.

They group accelerators into three kinds. Keyboard shortcuts, such as the standard copy and paste bindings. Gestures, such as swipe to delete, right-click, double-tap and two-finger scrolling. And voice commands, such as telling an assistant to start a routine.

The reason experts need them is a ceiling. NN/g describes an efficiency plateau, where further repetitions of a task stop meaningfully reducing the time it takes. Practice alone will not make your power users faster after a point. Only a different route will.

This reframes a common request. When a customer asks you to "make it faster", they often mean their own throughput, not your load time. We covered the keyboard side of this in our guide to keyboard shortcuts in SaaS products.

How Do You Teach an Accelerator Without Nagging?

Put the shortcut next to the slow path, every time the slow path is used. NN/g's guidance is to display shortcuts inline with menu items using distinct styling. The user is already looking there, already doing the action, and the lesson costs them no attention.

They also recommend revealing accelerators gradually as users gain familiarity, rather than presenting the whole set at once. A modal listing forty shortcuts on day one teaches nothing. A hint after the fifth time someone does the same thing manually teaches one thing well.

Prioritise frequently repeated actions, keep behaviour consistent across platforms, give visual feedback and a way to recover from errors, and avoid overwhelming novices with too many shortcuts. Where it makes sense, let expert users customise their own.

The anti-pattern is the onboarding tour that explains power features to someone who has not yet completed a basic task. That is teaching the shortcut before the road exists.

Should You Build a Beginner Mode and an Expert Mode?

Almost never. A mode switch splits your product into two products you now have to design, test, document and support. It also forces users to self-classify, and the research above suggests most of them will pick beginner and stay there forever.

There are narrow exceptions. A genuinely bimodal audience, such as a tool used by both clinicians and administrators, can justify separate views because the tasks differ, not just the speed. That is not a skill toggle, it is a role.

The cheaper version of the same idea is adaptive defaults. Remember the columns someone chose, the filter they always apply, the view they always land on. That gives an expert a faster start without asking anyone to declare their skill level. Our guide to SaaS settings page UX covers where those preferences should live.

What Does This Framework Look Like in Practice?

Four steps, in order. First, measure feature frequency per session and sort honestly. Second, apply progressive disclosure so the default screen carries only the frequent controls, with clearly labelled routes to the rest.

Third, add accelerators for the repeated actions your heaviest users perform, and surface each one inline at the moment the slow path is taken. Fourth, add adaptive defaults so returning users land where they left off.

Notice what is not in the list. No new features, no mode toggle, no rebuild. This is mostly a rearrangement exercise, which is why we like it as a first move before anyone argues about a redesign.

How Do You Know If It Is Working?

Watch two numbers moving in opposite directions, and be suspicious if only one does. Time to first successful task should fall for new users. Actions per session should rise for your heaviest users, or time per repeated action should fall.

If beginner metrics improve and expert metrics flatten, you hid too much. If experts speed up while new users stall, you have probably moved something frequent behind a label nobody understands.

Qualitative checks catch what dashboards miss. Watch five people who have used the product for a year do a routine task. NN/g's recommendation of observational usability testing applies just as much to your veterans as to your trial users, and almost nobody does it with veterans.

Where Should You Start?

Start with the frequency data, because it settles arguments that opinion cannot. Most teams have never sorted their features by how often a real session touches them, and the first time they do, two or three obvious moves fall out immediately.

Then pick one repeated action your best customers perform many times a day and give it a proper accelerator with an inline hint. One well-taught shortcut buys more goodwill than a quarter of general polish.

If you want help running that audit, or designing the disclosure structure for a product that has outgrown its first interface, we are happy to walk through it. You can find us at phoenix.studio.