UX Design & Research
Design decisions are better when somebody went and found out
Most sites do not need a redesign. They need four or five specific frictions removed, and somebody to establish which four or five. Research answers different questions depending on the method, and choosing the wrong method wastes the budget politely.
The position
Most sites do not need a redesign. They need four or five specific frictions removed, and somebody to find out which four or five those are.
A redesign is the most expensive way to test a hypothesis, and it changes so many things at once that afterwards nobody can say which decision helped. It is also the option that feels most like progress, which is why it keeps getting chosen.
The alternative is less impressive to present and considerably more useful: establish where people actually stop, understand why, fix those points specifically, and keep the ability to attribute the result to something.
Methods
Each method answers a different question
Choosing the method is most of the skill. Running the wrong one carefully produces a well-documented answer to a question nobody asked.
Moderated usability testing
Answers: can a person actually complete this task, and where do they get stuck? You give someone a realistic goal and watch without helping. It is the fastest way to find serious obstacles and the hardest for internal opinion to argue with, because everyone watched it happen.
Behavioural analysis
Answers: where do people stop, at what rate, and on which devices? Funnels, form field analysis and session recordings tell you where the losses are with real volume behind them. They never tell you why, and interpreting them as though they do is a common and expensive mistake.
Interviews and sales conversations
Answers: what were they trying to do, what did they compare you against, and what nearly stopped them buying? The people who answer your phones already know most of this. Fifteen structured conversations usually surface language you can put straight onto the page.
Tree testing and card sorting
Answers: does the structure match how customers think, and can they find things in it? Tested without any visual design at all, which is the point — it isolates the structure from how attractive the page is, and structural problems are the expensive kind.
Why it matters
Evidence changes who wins the argument
In most organisations, design disagreements are resolved by seniority, by whoever is most articulate, or by whoever most recently saw something they liked on another site. None of those methods correlate with what customers do.
Research changes the terms of the discussion. When six people out of eight failed to find the pricing information, the conversation stops being about whether pricing should be in the navigation and starts being about where to put it. That shift is worth more than any individual finding, because it persists after the project ends.
It also protects you from the opposite failure, which is redesigning things that were working. A site that converts reasonably well has earned some caution, and the honest outcome of a research phase is sometimes a very short list — which is a good result even though it makes for a thin presentation.
What we find
The frictions that recur across almost every site
- The form asks for things nobody needs yet.
- Company size, budget range, how they heard about you, a phone number for someone who wants an email. Each field is defensible individually and collectively they are the reason the form is not sent. The test is whether a human would ask that question in the first minute of a conversation.
- Navigation uses internal vocabulary.
- Menus named after departments, product names nobody outside the company recognises, or a category that made sense during a restructure four years ago. Customers search using their own words, and a tree test reveals within an hour whether yours match.
- The price question is avoided.
- Visitors want to know whether you are plausible before they contact you. A site that refuses any indication of cost sends them to somebody who gives one. Ranges, examples of what drives cost, or a starting point all work better than silence.
- Nothing confirms that anything happened.
- A form submits and the page barely changes. A filter is applied with no indication that it was. People repeat actions, then assume the site is broken. Feedback for every state — loading, success, error, empty — is unglamorous work that removes a surprising amount of abandonment.
- The mobile experience was designed second.
- Tap targets too small or too close together, tables that scroll off the screen, a sticky element covering the button, a menu requiring precision nobody has one-handed on a train. Most traffic arrives this way and most design reviews happen on a large monitor.
How it runs
From question to specification
Write down the question
Not "run some research" but a specific thing you do not know: why enquiries stall at the second step, whether people understand what the product does, whether the structure matches how customers group things.
You get: A research plan with the question and the chosen method
Look at what you already have
Analytics, recordings, search logs, support tickets, sales objections and reviews. A surprising amount of the answer is usually sitting unread, and it shapes what the research needs to cover.
You get: A summary of existing evidence and its gaps
Run the study
Recruit people who resemble your actual customers, give them a real task, and stay quiet while they do it. Sessions are recorded so findings can be shown rather than reported.
You get: Session recordings and raw observations
Synthesise into a short list
Group observations into a small number of problems, ordered by how many people hit them and how much they cost. A long list is a sign the synthesis has not been done yet.
You get: A prioritised friction list with evidence per item
Design the specific changes
Wireframes and interaction specifications for the agreed fixes, including the states everyone forgets: empty, loading, error, partially complete, and what happens on a small screen.
You get: Wireframes and behaviour specifications
Validate before building
Put the prototype in front of a few people from the same group. Finding a problem in a prototype costs an afternoon; finding it after release costs a release.
You get: Validation notes and a revised specification
Questions
What clients ask about research and design
What is the difference between UX and visual design?
Visual design decides how something looks: typography, colour, spacing, imagery, the feel of the thing. UX decides what exists, what it does, in what order, and what happens when it goes wrong.
They are not ranked against each other and a good interface needs both. The reason to separate them is that a site can be beautifully designed and still ask for a phone number three times, and no amount of visual work fixes that.
How is this different from conversion rate optimisation?
Conversion work is largely about measuring whether a change helped, usually through experiments run over enough traffic to be believable. Research is about generating the candidates worth measuring in the first place.
They fit together. Research produces a list of plausible problems; conversion work establishes which fixes actually moved anything. On a low-traffic site, research does more of the work because there is not enough traffic to test with.
How many people do you need to test with?
Fewer than most people expect. Watching five to eight people attempt a real task surfaces the majority of the serious obstacles, because the same ones recur quickly across participants.
Larger samples are for measuring — how many people fail, how long it takes — rather than for discovering. Confusing the two is how a research budget gets spent proving something you could have seen in an afternoon.
Do we need a full redesign?
Usually not, and we will say so. Most sites lose people at a handful of identifiable points, and fixing those is quicker, cheaper and far easier to learn from than replacing everything.
A redesign is genuinely warranted when the underlying structure is wrong, the brand has changed, or the technology can no longer support what the business needs. Those are architectural reasons, not aesthetic ones.
Can you research a product that does not exist yet?
Yes, with different methods. Interviews and contextual research tell you how people currently solve the problem and what they would have to give up to switch. Prototype testing puts something in front of them before it is built.
What you cannot do is ask people to predict their own future behaviour. What people say they would pay for and what they buy are different data, and only one of them is reliable.
Find out where people are actually stopping
Tell us which journey matters most and what you think is going wrong. We will tell you which method would answer it, roughly what it takes, and whether you need research at all or just a fortnight of fixes.
Related
Where to go next
- testing the changes afterwardsResearch finds candidates; testing establishes whether a change actually helped.
- designing for assistive technologyAccessibility failures are usually design decisions made without thinking about them.
- pages built for a single campaign
- a site that gets visits but no enquiriesThe symptom that usually brings people to this page.
- what the words on the page should say
- how we work with clients
Last updated · Reviewed by Zubair Afzal