How to design one interface for novice and expert users

When beginners and experienced people do the same job in your product, build one interface on one model of the domain and change the order in which that model is revealed. Show a newcomer the consequence of an action before they commit, keep every expert control one deliberate step away, and never hide a condition that changes what the main figure means. Separate simple and advanced modes earn their place when people do different jobs, not when they do the same job with different amounts of experience.

That answer runs against the two usual responses, so this page sets out what each of them costs, what research says about how people move from novice to expert, how we applied the idea to a crypto trading form, and a test you can run on your own interface.

Two usual answers, and what each costs

The first usual answer is two modes: a "simple" view for newcomers and a "pro" view for everyone else. The second is one view with the advanced controls hidden or cut, in the hope that experts will find what they need.

Modes split the product. Every screen, state and rule either exists twice or exists in one mode and not the other, and someone has to keep the two consistent each time the product changes. The simple mode also teaches its own way of working, so a person who outgrows it has to learn a second interface rather than the next layer of the one they already know.

Removal takes precision from the people who use the product most. A control that is not on the screen may not exist as far as the person looking for it can tell: Microsoft's own guidance on progressive disclosure lists lack of discoverability as its first risk, because users may assume that what they cannot see is not there. The cost lands on frequent users, who rely on exactly the controls a simplification would tuck away.

What research says about novices becoming experts

The case against a separate beginner mode rests on a pattern that research has documented for decades: people keep using the methods they already know, even when faster ones are available.

• The paradox of the active user. John Carroll and Mary Beth Rosson named it in 1987. Wai-Tat Fu and Wayne Gray, examining three different data sets in Cognitive Science (2004), found that the less efficient procedures people preferred tended to be well practised and generic, built from interactive steps that give fast, incremental feedback, and that this bias, in their words, "often leads to a stable suboptimal level of performance".
• Expert features go unused. Andy Cockburn, Carl Gutwin, Joey Scarr and Sylvain Malacria open their survey of novice-to-expert transitions (ACM Computing Surveys, 2014) with the same observation: many expert interface components are seldom used, and there is a tendency for users to persistently fail to adopt faster methods.
• People want unused features tucked away, not removed. In Joanna McGrenere's doctoral research at the University of Toronto (2002), a study of 53 Microsoft Word users found that many would like unused functions out of the way, while most were uncomfortable with removing them completely.
• Letting the software decide did not work. Office 2000 introduced adaptive menus that showed the most popular items first, tucked the rest into an expanded menu and reshuffled both as each person used them. Jensen Harris, writing on Microsoft's Office UI blog in 2006, explains why, in his view, they were not successful: no default short menu suited everyone, because people use a wide range of functions, and items moving between menus made the interface feel unpredictable. The Office 2007 applications that kept the old menus turned them off by default.

At Tcules, we draw an inference from this, not a finding of any one study: a simple mode is likely to become permanent for many of the people who start in it, and a hidden control is likely to stay unused by people who would benefit from it. Design for the transition rather than assuming it will happen.

Change the sequence, not the model

Keep one domain model, with the same objects, rules and words for everyone, and decide the order in which it appears.

1. Show the consequence first. A newcomer's first need is to understand what will happen if they go ahead. Put the result in their own terms on the screen before the commit: the balance they have, what an amount means, what will change.
2. Keep every expert control one deliberate step away. Defer controls; do not delete them. The person chooses when to open the advanced settings, and those settings stay in the same place every time. The same Microsoft guidance names lack of stability as the second risk of progressive disclosure, and recommends remembering whether a person left a section expanded. The adaptive menus above are what happens when the system guesses instead.
3. Defer only what some people need. The GOV.UK Design System gives the rule for hidden content plainly: use its details component for information only some users will need, and not to hide information the majority of users will need. The same rule works for controls.
4. Never separate a headline from the condition that changes its meaning. At Tcules, we set this limit in our work on financial products: progressive disclosure can reduce cognitive load, but it should not separate the attractive headline from the condition that changes its meaning. An estimated amount shown without the fee or tolerance that could alter it is not simpler; it is incomplete.

How we applied it to a crypto trading form

At Tcules, we joined the design team for Phoenix, a decentralised exchange built by Ellipsis Labs on Solana, through Kopper, for about ten months. Phoenix needed one trading experience for traders with very different levels of experience, without splitting into two products or hiding the controls its most active users rely on.

The two sides wanted different things from the same form. A newer trader needed a familiar way to place an order and to understand what an amount meant before committing to it. A frequent trader needed order types, price detail and tolerance settings close at hand, and would notice at once if the product gave up precision for simplicity.

We handled experience levels by sequence, not by removal. Newer traders saw their balance up front, a small set of common controls and a calculator that showed what an amount meant before the order was placed. Experienced traders could open advanced settings when they needed them. The domain stayed intact; the form revealed it one step at a time.

We then held the approach against the hard cases rather than the easy one. A market order makes any design look good. A limit order that waits for a price, a recurring buy, a stop loss and a bracket order with both take-profit and stop-loss triggers each add fields, rules and states. Each order type was designed in empty and filled states, with review, success and timeout screens behind it, and the logic was defined once and expressed across variants rather than redrawn screen by screen.

One related decision shaped the form as much as experience level did: whether a trade reads as buying from a market (Buy/Sell) or swapping from a wallet (In/Out) decides which control leads the form. That comparison is a subject of its own.

What we can and cannot say: we completed the design and development handoff in January 2026, and work after that belongs to the in-house team. The user-test findings are not part of the material we hold, and we claim no usage or trading outcomes for this approach.

Test your interface against its hardest case

Pick the most demanding thing an expert does in your product, not the default action, and walk it through these questions.

If the answers expose a gap, fix the model before the screens. A sequence can only reveal what the model already holds.

When separate modes are the right call

Modes are not always wrong. Three situations justify them.

• Different jobs. When two groups do genuinely different work, such as an operator and an administrator, separate views follow the work rather than the person's experience. That is role design, a different problem from the one on this page.
• Different offers. Some products separate because the offer itself differs. As an illustration, described from its own documentation rather than assessed, Kraken describes its two platforms (30 September 2025) as one for beginners and individual investors and one for advanced and institutional traders, with different order types and different fee structures, and one login for both. When pricing and trading features differ, the split is a business decision as much as an interface one.
• A switch that reveals more of the same model. Ben Shneiderman's multi-layer interface design (2003) lets newcomers start with a limited set of features and move to higher layers when they need them; the paper also sets out the critics' objection that a single sequence of features is hard to identify when users with different experience and needs must be served. In McGrenere's field study of 20 Word users over about six weeks, participants with a one-click switch between a personal interface they built and the full interface felt better able to navigate the menus and toolbars and to learn the available functions than with Word's adaptive menus. Both keep one application and leave the full set within reach, with the person in control of the switch.

The line to draw is not between one screen and two. It is between one model revealed in stages and two models that drift apart.

Where this work sits

Tcules is a digital product design studio creating ambitious new software products and making established ones better. In our Interaction and UI Design work, the first of the four questions we ask of every consequential interaction is what the person knows before acting. For a product that serves newcomers and experts, that question decides what the newcomer sees first and where each expert control waits.

For the wider principles behind dense, high-frequency software, see our article on enterprise UX design for complex workflow software; for the financial context, fintech UX: designing for trust, compliance and speed.