5 steps to improve your user experience.

Good user experience is rarely one big idea. It is the accumulated result of many small, deliberate decisions — and a willingness to remove things rather than add them. The teams that ship products people find easy are not the ones with the most talented visual designers; they are the ones with habits that make the right small decision routine. This article is five of those habits, each with a concrete step you can take this quarter, written for product teams building web applications that need to convert visitors and keep them.

Step 1: Start with the job, not the screen

Before you design a single pixel, get painfully clear on what the user is trying to accomplish and what is currently in their way. Most UX problems are really clarity problems in disguise.

The useful question is not "what should this page have on it" but "what is this person trying to finish, and what is stopping them". Those produce very different artefacts. The first produces a list of features and a layout to hold them. The second produces a sequence, and a sequence can be tested against reality before anything is built.

In practice this means writing the top user journeys down as ordered steps — the person arrives with this intent, needs to do this, then this, and is done when this is true — and marking where people currently stall or leave. Analytics will show you where; a few conversations with users will tell you why. The design brief for each screen is then "move the person from step three to step four", which is a brief a team can execute and measure.

Step 2: Reduce, then reduce again

Every element on a page competes for attention, and a popup competes hardest. The fastest way to improve most interfaces is to delete what does not serve the primary task, not to polish what does.

This is harder than it sounds, because everything on the page got there for a reason and usually has an internal advocate. A useful reframe in those conversations: adding an element does not just add its own cost, it slightly degrades every other element by taking attention from them. The question is never "is this useful?" — almost everything is somewhat useful — but "is this more useful than the attention it takes from the main thing?"

Start with the busiest screen. Count the calls to action, the links, the badges and the notices. Pick one primary action and make it visually dominant; demote everything else to secondary styling or move it to where it is needed. Then remove one thing entirely and watch the metrics for a fortnight. In our experience, nobody notices the removal, and the primary action's completion rate goes up.

Step 3: Make consistency a feature

Users build a model of how your product behaves within the first few screens, and every inconsistency after that costs them a small re-learning. Two buttons that look the same should do the same kind of thing. A pattern that means "destructive" in one place cannot mean "primary" in another. This is the real argument for a design system, and it is not about efficiency for the design team — it is about not making the user relearn your product on every page.

Consistency extends beyond visuals to language and behaviour. The same action should have the same name everywhere — not "delete" here, "remove" there and "archive" somewhere else for the same thing. Forms should validate the same way. Navigation should be in the same place. The quickest audit is to screenshot every screen and lay them side by side; the inconsistencies are obvious in a way they never are one screen at a time.

Step 4: Design the unhappy paths

Most designs are made for the case where everything works: data present, network fine, user doing the expected thing. Real use is mostly the other cases. Empty states, loading states, partial failures, expired sessions, permission denials and validation errors are where products feel broken, and they are almost always designed last, by whoever is implementing them, under time pressure.

Designing them up front costs little and is disproportionately what users remember. An empty state that explains what goes here and how to add the first one is onboarding; the same screen left blank is a dead end. A loading state that shows the shape of what is coming feels fast; a spinner feels broken after three seconds. An error that says what went wrong and what to do next keeps the user; a generic "something went wrong" loses them.

• Empty: what this is for, and the one action that fills it
• Loading: a skeleton of the layout, not a spinner, for anything over a second
• Error: what happened in plain words, whether their data is safe, and what to try
• Partial: what to show when some of the data arrived and some did not
• Success: confirmation of what just happened and what comes next

Step 5: Test with people, not opinions

Internal debate about UX converges on whoever argues best or outranks the others, and neither correlates with what users do. Five people attempting a real task will settle arguments that have run for months, and the sessions are cheap enough to run on a design nobody has built yet. The discipline is watching without helping — the moment you explain the interface, you have replaced the thing you were trying to measure.

Remote sessions work as well as in-person ones and are far easier to schedule. Recruit from your own customers or sign-ups where you can; they bring real context. Pay participants for their time.

A session needs a real task ("find and book an appointment for next Tuesday"), a participant who resembles a real user, a prototype or the live product, and someone to take notes on where the participant hesitated, misread or gave up. Thirty minutes each, five participants, and the patterns are clear. Fix the worst two problems, and run it again next month. This rhythm, more than any single insight, is what separates teams with good UX from teams that talk about it.

Write the words before the layout

A surprising amount of UX is copy. The label on the button, the heading that tells someone where they are, the sentence that explains what a form is for, the error that says what to do next. Layouts designed with placeholder text get filled in later by whoever is available, and the result reads like a system talking to itself. Write the real words first — the headings, the labels, the confirmations — and design around them. If a screen cannot be explained in a sentence, the problem is the screen, not the sentence.

Measure what the changes do

UX work that is not measured becomes a matter of taste, and taste loses budget arguments. Pick a small number of metrics tied to the journeys from step one — completion rate of the core task, time to complete it, the drop-off at each step, support tickets about a specific screen — and watch them before and after every change. Some improvements will not move the numbers, and that is information too. The point is that a UX decision becomes something the whole team can see the effect of, rather than something the loudest person in the room decides.

Steps worth taking this quarter

• Map the top three user journeys end to end, including where people currently drop out
• Cut secondary actions from primary screens
• Make the primary action unmistakable on every screen — exactly one, visually dominant
• Write the empty, loading and error states for your three most-used screens
• Screenshot every screen and audit for inconsistent names, patterns and placements
• Watch five people attempt a real task without help, and resist explaining
• Remove one thing from your busiest screen and measure whether anyone notices

Frequently asked questions

UX strategy is the accumulation of many small right decisions. We help teams build the habits that make those decisions routine instead of heroic, on the web products we build with them.

Related: our UI/UX design services · our case studies.