Skip to content

UX & Design7 min read

Your users aren't confused. Your product is.

When usability testing shows people struggling, the instinct is to add help. Most of the time the product is asking them to hold a model of the system that the system itself never settled on.

By Product Practice, Product design & research

There is a sentence that comes up in almost every product review we sit in: 'users are confused by this.' It is usually followed by a proposal for a tooltip, an onboarding tour, or a help article. Occasionally a video.

Sometimes that is the right answer. More often the confusion is accurate. The user has correctly noticed that the product does not make sense, and is struggling to build a coherent picture of something that is not coherent.

Every product teaches a model, whether you design one or not

People use software by building a working theory of how it behaves: these things exist, they relate like this, this action does that. Good products make that theory easy to form and hard to get wrong. Struggling products make it impossible to form, because the product itself does not have one.

This happens naturally as products grow. A feature is added by one team and called a 'workspace'. Another team adds a similar thing and calls it a 'project'. A third adds 'spaces' to the mobile app. Engineering knows they are different tables in a database. The user sees three words that might mean the same thing, or might not, and has no way to tell.

Symptoms that the model is the problem

  • The same object is reachable from several places, with slightly different options in each.
  • Support tickets ask 'what is the difference between X and Y?'
  • Settings exist at more than one level and nobody can say which one wins.
  • Power users describe the product using their own vocabulary, not yours.
  • New features need a tour to explain where they fit.

If several of those are true, adding help will not fix it. Each help layer is one more thing to learn, laid on top of a structure that still does not hold together.

Fix the model before the interface

The work is unglamorous and very effective. List every concept the product exposes. Write one sentence defining each. Wherever two definitions overlap, decide whether they are genuinely different things or the same thing with two names, and merge or separate accordingly.

Then map where each action lives. One action should have one home. It can be reachable from several places, but it should always open the same thing and behave the same way.

When help is the right answer

Help text is right when the concept is genuinely complex and the user genuinely needs it: tax rules, regulatory constraints, statistical methods. It is wrong when it is explaining a decision the team could have made simpler.

If a feature needs a tour, ask what the tour is apologising for.

The best usability work rarely adds anything. It removes a name, merges two screens, settles an argument about what a word means. Users stop being confused because, finally, there is something coherent to understand.

Product Practice

Product design & research

The product practice covers discovery, research, interaction design and design systems. It writes about the structural decisions that sit underneath an interface, and what happens when they are made carelessly.