{{ p.category }}

{{ t }}

{{ p.title }}

{{ p.excerpt }}

U{{ author.name }} {{ p.readMins }} min read

{{ p.category }}

{{ p.title }}

{{ mo.sub }}

{{ m.tag }}

{{ m.t }}

{{ m.d }}

{{ m.left.t }}

✕{{ x.t }}

{{ m.right.t }}

✓{{ x.t }}

{{ m.big }}{{ m.label }}

{{ x.t }}

{{ m.label }}

✓{{ x.t }}

{{ x.t }}

{{ m.label }}
{{ x.t }}
{{ m.status }}

{{ m.label }}

{{ x.t }}{{ x.n }}

{{ x.t }}

{{ m.label }}{{ m.stepTxt }}

{{ x.t }}

{{ m.btn }}

{{ x.t }}

{{ m.q }}

{{ m.a }}

{{ x }}

{{ k.n }}

{{ k.v }}

{{ m.label }}

{{ m.status }}

{{ m.label }}

{{ st.n }}{{ st.t }}

{{ m.hub }}

{{ nd.t }}

AaAaAaAa

ButtonInput fieldTag

THE SHORT ANSWER

{{ p.answer }}

KEY TAKEAWAYS

✓{{ k }}

RELATED SERVICES

{{ b.t }}

{{ g.t }}{{ g.t }}

{{ g.t }}

{{ b.label }}:{{ b.t }}

{{ c.ini }}

{{ c.t }}

{{ c.d }}

{{ s.n }}

{{ s.t }}

{{ s.d }}

{{ h }}
{{ c.t }}

{{ b.alt }}

{{ g.alt }}

{{ b.title }}

{{ c.t }}

{{ c.s }}

{{ i }}

{{ c.t }}{{ c.s }}

{{ b.caption }}

{{ s.v }}

{{ s.l }}

{{ s.s }}

{{ b.caption }}

{{ b.title }}

{{ b.unit }}

{{ r.l }}{{ r.d }}

{{ b.caption }}

{{ b.title }}

A{{ b.a.t }}

{{ i }}

B{{ b.b.t }}

✓{{ i }}

{{ b.caption }}

{{ b.title }}

{{ t.d }}

{{ t.t }}

{{ b.caption }}

“

{{ b.t }}

{{ b.by }}

{{ b.title }}

{{ r.d }}

{{ r.l }}

{{ b.caption }}

{{ b.title }}

{{ m.n }}

{{ b.lo }}{{ b.hi }}

{{ m.n }}

{{ m.l }}

{{ m.d }}

{{ b.caption }}

{{ b.cs.client }} case study

Case study · {{ b.cs.client }} {{ b.cs.title }} {{ b.cs.text }}

{{ f.v }}{{ f.l }}

View case study →

SOURCES AND FURTHER READING

Frequently asked questions

{{ f.a }}

U

Written by {{ author.name }}

{{ author.role }}

Keep reading

More articles from across design, AI and marketing.

All articles

{{ r.category }} · {{ r.readMins }} min{{ r.title }}

Special Offer

25% Off Your Startup’s First Project

No Obligation
Quick Response
Exclusive for Startups

How to find the right design solution, step by step

To find the right design solution, define the problem in one sentence, gather evidence from users and data, agree how success will be measured, explore several options, prototype the most promising, test with real users, and decide based on the results. Skipping the early steps is the most common reason solutions miss.

Why design solutions miss the mark

Most design projects that disappoint do not fail because the team lacked skill. They fail because the team solved the wrong problem, or solved the right problem in a way nobody tested. A stakeholder suggests a feature, the team designs and builds it, and only after launch does it become clear that users needed something else. The time and money spent cannot be recovered, and the original problem remains.

A structured method reduces this risk. By working through a fixed sequence of steps, teams make sure they understand the problem before discussing solutions, compare several options instead of committing to the first idea, and use evidence from real users to make the final decision. The seven steps below are simple enough for any team to follow and flexible enough for problems of any size.

The seven steps

Define the problem: One sentence: who is struggling, with what, and why it matters.
Gather evidence: Analytics, support tickets, interviews and usability tests.
Set success measures: The metric that should change, and by how much.
Explore options: At least three different approaches, sketched roughly.
Prototype: Build the strongest one or two as clickable prototypes.
Test: Watch five to eight users attempt the task.
Decide and measure: Ship the winner and track the success measure.

Step one in depth: defining the problem

The problem statement is the foundation of everything that follows. It should describe who is affected, what they are trying to do, what is getting in the way and why it matters. A useful test is whether someone outside the team could read it and understand the problem without further explanation. If the statement mentions a specific solution, such as "we need a new dashboard", rewrite it to describe the underlying need instead.

Solution disguised as a problem	Real problem statement
We need a chatbot	Customers wait too long for answers to simple questions about orders
We need a new homepage	First-time visitors do not understand what we offer within the first few seconds
We need more filters	Shoppers cannot narrow down large categories to products that fit their needs

Steps two and three: evidence and success measures

Gather evidence from several sources: analytics show what is happening and how often, user interviews and usability tests explain why, and support tickets reveal problems in customers’ own words. Then agree how success will be measured before designing anything. A clear success measure, such as reducing support calls about order status by a set amount, keeps the team focused and makes the final decision easier. Our guide to measuring user experience covers useful metrics.

Steps four to six: explore, prototype and test

Exploring at least three options prevents the team from fixating on the first idea. Options should differ meaningfully, not just in visual style. Rough sketches are enough at this stage. The most promising one or two options then become clickable prototypes, realistic enough for users to try. Testing these prototypes with five to eight users usually shows clearly which approach works best and what needs to change.

Diverge: Sketch many different approaches quickly.
Compare: Score options against the problem statement and evidence.
Prototype: Build only the strongest options.
Test: Watch real users attempt the key task.

Step seven: deciding and measuring

Once testing points to a clear winner, build it, release it and measure against the success measure agreed earlier. If results fall short, return to the evidence and iterate. Recording the decision, the options considered and the results helps future teams avoid repeating the same work. Our post on connecting insight to design explains how to keep a simple decision log.

A worked example

A clinic notices that many patients call to reschedule appointments, overloading reception staff. The problem statement becomes: "Patients who need to change an appointment cannot do it online, so they call reception, which creates long phone queues." Evidence from call logs and interviews confirms the issue. The success measure is a reduction in rescheduling calls. The team explores three options: a reschedule link in reminder messages, a self-service section in the patient portal and a WhatsApp booking assistant. Prototypes of the first two are tested with patients, and the reminder link performs best because it meets patients exactly when they need it. After launch, the team tracks call volumes to confirm the result.

Common mistakes

Mistake	What happens	Better approach
Starting with solutions	Debates about opinions	Write the problem first
One option only	No way to compare	Explore at least three
Polishing too early	Time wasted on the wrong idea	Test rough prototypes
No success measure	Nobody knows if it worked	Agree the metric up front

If you are not sure which kind of help you need, our guide to matching problems with design services is the companion to this one. For existing products, a UX audit supplies the evidence for step two.

Frequently asked questions

How many users do we need to test with?

For qualitative usability testing, five to eight per user group usually reveals the main issues.

How long does this process take?

For a focused problem, one to three weeks. Larger problems repeat the cycle in stages.

Who should be involved?

A product owner, a designer, an engineer and, ideally, someone who talks to customers, such as support or sales.

What if we have no time for user testing?

Even three quick sessions with colleagues outside the project or a short remote test is better than none, and usually takes less than a day.

Related articles