Design self-service support that resolves problems

Why most help centres don’t help

Many support sites grow one article at a time. Each article answers a question someone once asked, and over the years you end up with hundreds of pages organised by product line or internal team. Customers arrive with a problem (“my internet’s down”), and the site hands them a catalogue.

Good self-service starts from the opposite end: what is this person trying to sort out, and what’s the quickest reliable route to sorting it?

Our founder spent six months on this problem with a major UK broadband provider, restructuring its support experience into guided journeys across the help website and mobile app. The work is in the broadband self-service case study. These are the principles we’d apply to any support journey.

Organise around intent

Start by grouping support topics by what the customer is trying to do: diagnose a connection, finish a self-installation, find missing equipment, improve Wi-Fi at home, report a fault. Those are intents. They cut across products and internal teams, and that’s the point.

The team built a progressive structure with five levels, from the help homepage down to a service area, a specific topic, a setup task and the detailed guidance. Each level narrows the problem without making people read everything along the way.

Treat each journey as a decision system

A troubleshooting journey isn’t a sequence of pages. It’s a set of decisions. For a connection problem, that meant identifying the service, running automated checks, and then branching on the result: success, failure, or “we need more help”.

Mapping it this way exposes the questions a static article never answers. What if the check passes but the customer still has no connection? What if they’re halfway through installing and the router hasn’t arrived? What if their line isn’t suitable at all?

Design the failure branches properly

The branches where things go wrong are where customers most need help, so they deserve the most design attention. For self-installation, the design covered incomplete setup, missing or delayed equipment, unsuitable connections, and customers who still couldn’t continue after trying everything.

For each branch, define three things:

• What the customer sees and understands at this point.
• What they can try next, in plain language.
• When to stop trying and hand over to a person.

That last one matters. Self-service without a clear way out frustrates customers and undermines confidence in the service.

Keep a clear route to a person

A visible route to assisted support isn’t a failure of self-service. It’s part of it. Make it easy to find from every journey, and pass along what the customer has already tried, so they don’t have to repeat it all to an agent. Nothing erodes trust faster than explaining the same problem twice.

Write for someone who’s stressed

People using support content are often frustrated, in a hurry and not technical. Use short steps, one action each. Say what they should see after each step, so they know whether it worked. Avoid internal jargon, and test the wording with real customers if you can. GOV.UK’s guidance on writing for interfaces is a great reference here.

Document it for the teams who’ll build it

Decision logic, content structures and error states need to be written down in a way design, content and engineering can all use. On the broadband project, those maps and state definitions became the shared definition of the service, and that’s a big part of why it made it into production on both web and mobile.

If your support journeys aren’t reducing contacts the way you hoped, a UX Audit of one key journey will show where people get stuck. To redesign the journey end to end, look at Complex Workflow Design.