Problem

Start with the problem.

Research

Find out what's true.

Synthesis

Decide what matters.

Ideate

Design the right thing.

Test

Break what you designed.

Implement

This is only the beginning.

One more thing

The process starts with you

Interested in working together?

Book a call (opens in a new tab)

Problem

Start with the problem.

Most projects begin with a solution.

That's backwards.

Every product exists to solve a problem for someone. Until you know exactly what that problem is, every decision is based on assumption instead of evidence.

The first thing I do is define the problem, who owns it, and who experiences it. Customers have goals. Businesses have goals too. The best products solve both.

Everything that follows depends on getting this right.

If you can't explain the problem in one sentence, you don't understand it well enough yet.

That sentence becomes the problem statement. It keeps the team aligned and gives every design decision something to measure itself against.

Example:

Mortgage origination is too slow, creating uncertainty for customers and unnecessary friction throughout the application process.

The situation:
I joined Mortgage Hub when the product was already close to launch. The research had happened before I arrived, but nobody could show it to me.
Everyone assumed we already understood the problem.
I wasn't convinced.
What I chose:
Instead of treating research as finished, I ran usability sessions with mortgage brokers. I wasn't looking for opinions. I was looking for evidence. Within minutes, people were struggling to navigate cases. The real problems appeared almost immediately.
What it revealed:
The product hadn't failed because of poor design. It had drifted away from the original problem. The personas, jobs to be done, and research insights had gradually disappeared from the conversation. Once we rebuilt that shared understanding, the right design decisions became obvious.

View the case study

Define what we know

Before talking to customers, I learn everything the business already knows.

Analytics. Support tickets. Slack conversations. Emails. Research. Reviews. Strategy documents.

Every organisation already has clues.

I gather them, connect them, and look for patterns. The goal isn't to find answers. It's to decide what questions need asking next.

Symptom vs cause

People don't abandon products for no reason. "Users are dropping out halfway through" isn't the problem. It's evidence that a problem exists.

The real question is why.

  • Do they not understand?
  • Can they not complete the task?
  • Or have they decided it's no longer worth the effort?

Until you know which one it is, you're solving symptoms instead of causes. That's why research comes next.

What people sayWhat it usually means
Users want a dashboard.They want to answer a question faster.
We need Feature X.We haven't understood the problem yet.
Our competitors all do this.We don't know if it's the right thing to do.
Users drop out at step three.We know where, not why.
The flow is confusing.Something deserves a closer look.

Research

Find out what's true.

The fastest way to build the wrong thing is to assume you already understand the problem.

You don't.

Customers rarely describe their problems accurately. Businesses fill in the gaps with assumptions. Teams mistake confidence for certainty. Research exists to replace opinions with evidence. That means talking to people, watching what they actually do, and staying curious for longer than everyone else wants to. Competitor reviews, market reports and AI summaries are useful.

They explain the market.

They don't explain your users.

Markets tell you what people buy. Users tell you why.

Example:

Users are abandoning EcoVadis' sustainability assessment at the corrective action plan.

The situation:
Companies received a sustainability score but didn't know what to do next. Analytics showed the drop-off but they couldn't explain it.
What I chose:
I interviewed customers to understand their thinking and then I watched different customers complete the same journey through a usability study. What people said and what they actually did weren't always the same.
That's where the interesting part started.
What it revealed:
The assessment wasn't the problem. The guidance was. People understood their score but had no clear path to improve it. They were being told what was wrong without being shown how to make it better.
The solution:
Instead of presenting a score, I designed a roadmap with step-by-step actions and clear priorities. People also needed progress people could measure over time. Once people knew what success looked like, they finally knew how to reach it.

Listen

People will tell you what's frustrating them. But they'll also tell you what they expect, what they've been taught, and what they believe is normal. Those expectations matter, and sometimes you're designing around a misconception that's been reinforced for years.

Listen carefully. Not just to the answers. Listen to the language people choose.

Ask

Good interviews aren't about asking better questions, they're about asking fewer. The more you lead people, the more they'll try to help you. I always say that the best moments usually arrive after an awkward silence, when someone stops giving the answer they think you want and starts telling you what actually happened.

Watch

If you want the truth, watch people use your product. People forget, simplify, rewrite history. Behaviour doesn't.

Where someone hesitates, where they click first, what they ignore, and the workaround they've stopped noticing will tell you more than any interview ever will. This is proof that when what people say and what people do don't match… Believe what they do.

Method by question:
QuestionEvidence
Why?Interviews
Can they?Observation
How many?Analytics
Which?Experiments
What else?Market research

Synthesis

Decide what matters.

Research gives you facts. Synthesis gives you direction.

This is where you stop collecting evidence and start making decisions. You look for the patterns that keep repeating, separate the important from the interesting, and decide which problems are actually worth solving. Every project reaches a point where you know enough, but the hard part is having the confidence to stop researching and start deciding.

Insight isn't what people said. It's what their behaviour meant.

Example:

People weren't seeing an error.They were being told they had one.

The situation:
Everyone claiming through Glacier Drop encountered the same "null transaction" message. Technically, nothing had gone wrong, but that's not how people interpreted it. Instead, many assumed their wallet had failed and abandoned the process.
What I chose:
The synthesis wasn't "improve the error message", it was recognising there wasn't an error at all, so I redesigned the journey so the same state was explained as the next expected step instead of a failure.
The result:
Technically, nothing had changed. It actually changed psychologically, and once the language matched reality, people kept going.

View the case study

Find the pattern

One interview proves nothing and neither does ten. What matters is repetition, and when different people in different sessions struggle with the same thing, you're no longer looking at opinions, you're looking at a pattern.

Write the insight

A good insight changes how you see the problem, not "people want it to be faster", but "people abandon the address step because they don't know why an unused address matters".

One describes a wish, while the other explains behaviour.

Turn insight into action

Insights don't ship. Products do. Every insight should point towards a decision and that decision becomes an opportunity which eventually becomes an experiment. It's the experiment that becomes a product.

If you can't trace a feature back to an insight, you should question why you're building it.

Start with…Example
What happened?People stopped at the warning screen.
Why did it happen?They believed their wallet had failed.
What does that mean?The state was normal. The language made it feel like an error.
What should change?Explain the state as the next step, not a failure.
How do we build it?How might we reassure people without interrupting their progress?

Ideate

Design the right thing.

I have a lot of ideas. The difficult part is deciding which ones are worth building. I go wide with rapid sketching, and workshops with people outside the design team. Some ideas will be practical, other ones will be completely bonkers, but they all help reveal how far we should go to solve the problem.

Then, I narrow down the options by measuring them against the problem, the research and the opportunities identified during synthesis. This is where constraints become useful. Freedom gives you more possibilities, but a good constraint removes the weak ones.

Generating ideas is easy. Choosing one over 20 other good ones is the hard part.

Example:

Let the constraints shape the product.

The situation:
Squared Online had to work within Moodle and feel like a Google product. Neither constraint was mine to change. Every custom interaction required additional plugin development, while every unfamiliar pattern risked making the experience feel less like Google.
What I chose:
I treated those constraints as part of the product rather than problems to work around. Moodle's data model defined how the course was structured, Material Design established the visual and interaction language, and the bespoke design effort was reserved for the moments students would actually notice and value.
The trade-off:
The result was less distinctive than a completely bespoke platform, but that was the right compromise. Assessment, enrolment and chat worked from the beginning, and the course team could continue improving the content without creating a design or development bottleneck.

View the case study

Ideate with volume and range

I love to generate lots of ideas quickly, and there's nothing like a bit of time pressure to stop anyone becoming attached to the first concept. The crazy ideas stay on the wall too, because they show us where the boundaries are.

Narrow down

I judge concepts against the opportunity areas and jobs to be done defined during synthesis, not against personal taste. Feasibility and effort enter the conversation once we have explored the space properly. They should help us choose and refine ideas, not prevent us from considering them in the first place.

Decide

I record every rejected idea with the reason it was rejected. Someone will almost always ask months later why the team didn't choose the apparently obvious option. I could choose to run with one or two ideas but always reject hundreds that I would have loved to have shipped. That's just part of the job.

Diverge, then converge
Opening upNarrowing down
Generate for range and quantityScore against the opportunity areas
Suspend the feasibility filterWeigh feasibility, effort and value
Bring different disciplines into the roomBring engineering into the decision
Allow unrealistic ideasRecord rejected ideas and the reasons why

Test

Break what you designed.

I don't make prototypes to impress people. They're there to expose issues before they become expensive problems. I build only enough to answer the question in front of me so I can quickly put it in people's hands and watch them fail. The most useful moments are the pauses, the wrong turns and the rereading that people barely notice.

Early testing is uncomfortable and makes me deeply insecure, because the work is unfinished and every weakness is on show. That is precisely why it's valuable. A problem found in a sketch might cost a few minutes to fix; the same problem found after launch can cost weeks of development, customer trust and even an extra release.

When testing changes nothing, either the design is bloody good or the test wasn't demanding enough. It's usually the latter.

Example:

Familiar patterns only take you so far.

The situation:
For Dyson's resource request journey, I used established e-commerce patterns. Teachers were requesting classroom resources rather than buying products, but the structure of the task appeared similar enough that a familiar pattern seemed like the right starting point.
What I chose:
I trusted that familiarity would reduce the need for explanation. Much of the pattern translated well, and people understood the basic journey without needing to learn a new interface.
Solution:
The way teachers discovered the right resource and how they selected them all in their own form did not translate as cleanly as expected. Another round of testing revealed that teachers wanted one form for all resources, and a pre-selection of the resource from which they entered the journey browsing saved on cognitive load.

View the case study

Only test what you need to

A prototype should be only as true to the real thing as the questions need it to be. Paper is enough to find out whether an idea makes sense. A clickable wireframe can reveal whether the structure works. Realistic content and interactions become necessary when you need to understand completion, confidence or trust. Anything beyond that is often polish disguised as progress.

Watch behaviour, not commentary

I like to give people a task, not a tour. I let the design explain itself and let them try and figure it out. I tend to stay totally silent in usability studies and watch for where they paused, backtracked, misread a label or failed to continue. I'm always humbled.

Report what failed

I'm very rarely interested in what went well from testing, it's all about what broke, how often it happened and what the outcome was. I score on severity, one person being completely blocked may be more important than five people experiencing mild friction. After testing, the next version is always better.

Build only what you need to learn
The questionWhat I build
Is this the right idea?Paper sketches or a storyboard
Does the structure make sense?A greyscale, clickable wireframe
Can people complete the task?An interactive prototype with realistic copy
Do people understand and trust it?A high-fidelity prototype with real states and representative data
Does it work in the real world?A built, instrumented experience released in stages

Implement

This is only the beginning.

I've never once, in 14 years in the game, felt finished on launch day. Launch day is the day I finally get real information. Everything before that, that's all still opinion dressed up as evidence. It's good evidence. It's the best evidence you can get before the thing exists in the world. But it isn't the truth.

The truth shows up the moment real people, thousands of them, with their own eyes and habits, start using it in ways you never could have predicted.

If a launch changes nothing about what you build next, then you built the whole thing right first time, which never happens.

Example:

A demo built for two, run by one.

The situation:
Marlowe Run shipped with a demo wallet, so anyone could run a full smart contract risk-free before ever touching real ADA. It did exactly what it was built to do: teach the mechanic without the fear of losing real money on something unfamiliar.
What happened:
Once it was live, a lot of contracts were starting and then being left sat waiting for a second person who never showed up. In a moderated test session there's always a second person in the room, that's the whole setup. Out in the wild, most visitors were on their own, trying the product cold, with nobody lined up to play the other side.
Solution:
That gap only showed up at scale, once thousands of solo visitors hit the same dead end. The next release let anyone run a contract solo with a simulated counterparty, so the full agreement could still play out and settle even when nobody else was taking part.

View the case study

Scale changes what happens

A handful of people will find your obvious mistakes. Fifty thousand real people will find the ones you never even thought to look for. You only see that once the thing is out there being used.

Watch patterns, not individual complaints

I don't care who shouts loudest. I look at how often something happens and how bad it is before I look at any single message. One person completely stuck matters more than a hundred people mildly annoyed. But neither matters as much as the same problem repeating across thousands who never say a word.

The questionWhat I track
Is anyone using it?Activation in the first days and weeks
Are they coming back?Repeat use over time
Where does it break?Drop-off by cause
What matters most?How often and how bad
What ships next?A backlog built from real behaviour