UX Design Models Explained - From User Problems to Better Products

The UX pipeline - problem, understanding, ideas, design, validation, delivery - with eight design models placed along it according to the question each one answers: Jobs To Be Done and Design Thinking at the problem end, Double Diamond spanning understanding to design, User-Centred Design and Service Design across the middle, Lean UX at validation, and Agile UX and Atomic Design at delivery

Good UX is not about making screens look attractive.

It is about understanding a problem, designing the right experience, validating that experience, and continuously improving it.

That is where UX design models become useful. A UX design model gives teams a structured way to move from:

Problem → Understanding → Ideas → Design → Validation → Delivery

There are many UX models, but most modern product teams end up combining several of them rather than following one methodology religiously.

Here are some of the most useful ones.

1. Double Diamond

The Double Diamond is one of the clearest ways to explain the UX process. It consists of four stages:

Discover → Define → Develop → Deliver

The first diamond focuses on understanding the problem. The second focuses on finding the right solution.

Two diamonds side by side. The first opens out from a starting point through Discover and narrows to Define at the problem statement. The second opens out through Develop and narrows through Deliver to the shipped solution. Widening phases are labelled divergent thinking, narrowing phases convergent thinking

Discover

Start by exploring broadly. Talk to users, review existing workflows, analyse support requests, study competitors and observe how people currently solve the problem.

The goal is not to validate an idea you already have. The goal is to understand what the actual problem is.

Define

Now narrow the problem down.

Instead of saying:

We need an AI-powered dashboard.

A better problem statement might be:

Users cannot quickly determine what action they should take next.

That distinction matters. One describes a technology. The other describes a user problem.

Develop

Once the problem is understood, explore multiple solutions. A team might consider:

A recommendation card
A guided workflow
A conversational assistant
A notification
A progress dashboard

UX design is strongest when teams explore alternatives rather than immediately building the first idea.

Deliver

Prototype, test, refine and eventually ship the solution.

The Double Diamond is useful because it reminds teams to alternate between divergent thinking and convergent thinking. Explore broadly. Then narrow down.

2. Design Thinking

Design Thinking follows a similar philosophy but places stronger emphasis on understanding the user. The typical flow is:

Empathise → Define → Ideate → Prototype → Test

The key idea is simple: start with people, not technology.

Imagine designing software for teachers. The technical team might immediately think about analytics, AI recommendations and dashboards.

Design Thinking starts somewhere else. What does the teacher actually need?

Perhaps the real question is:

Which students need my attention before today's lesson?

Once that is understood, the product becomes much easier to design. Instead of building twenty charts, the UX might simply surface three students who require intervention.

Good UX often comes from reducing complexity rather than exposing more capability.

3. User-Centred Design

User-Centred Design, or UCD, is less of a single process and more of a philosophy.

The system should be designed around how users think and work. Not around how the database is structured.

A backend system might contain concepts such as:

events
entities
permissions
evidence
scores
states
relationships

The user should not need to understand any of them. The interface should translate complexity into something meaningful.

System language on the left - events, entities, permissions, evidence, scores, states, relationships, and a raw skill_mastery_score of 0.63 - passing through an interface labelled translation and arriving on the right as human language: 'Needs more practice', 'Three students need attention today', 'You can invite people to this organisation'

For example, instead of exposing:

skill_mastery_score = 0.63

the interface might say:

Needs more practice

That translation from system language to human language is a fundamental part of UX.

4. Lean UX

Traditional product development sometimes looks like this:

Requirements → Design → Build → Launch

The problem is that teams can spend months building something before discovering that users do not actually want it.

Lean UX changes the process to:

Hypothesis → Experiment → Measure → Learn

A straight line from requirements through design and build to launch, with the first user feedback arriving only at the end after months of work, compared with a tight loop of hypothesis, experiment, measure and learn, where each turn of the loop is small and evidence arrives every cycle

Instead of saying:

We will build a personalised recommendation engine.

A Lean UX team might say:

We believe showing one recommended next action will increase engagement.

Then they build the smallest version capable of testing that assumption. If the behaviour improves, invest further. If it does not, change direction.

Lean UX is particularly useful for startups because it reduces the cost of being wrong.

A hypothesis has to be falsifiable

"We will build a recommendation engine" cannot be wrong - it is a plan, and plans either get done or they don't. "Showing one recommended next action will increase engagement" can be wrong, which is precisely what makes it useful. If the experiment cannot fail, it is not an experiment, and the team learns nothing from running it.

5. Agile UX

Agile UX integrates design directly into the software-development process. Rather than completing all UX work upfront, design and engineering move together.

For example:

Sprint 1
  Designers explore Feature B while engineers build Feature A.

Sprint 2
  Designers explore Feature C while engineers build Feature B.

UX remains slightly ahead of development without becoming disconnected from it.

This approach works particularly well for modern product teams using short release cycles. The design system, product behaviour and implementation evolve together.

6. Jobs To Be Done

Jobs To Be Done, often abbreviated as JTBD, asks a different question.

Instead of what features does this user want? ask what is this user trying to accomplish?

A useful format is:

When ______, I want to ______, so I can ______.

For example:

When I finish today's lesson, I want to know what to practise next, so I can continue making progress.

Or:

When I open my class dashboard, I want to immediately see which students are struggling, so I know where to focus my attention.

These statements are powerful because they describe outcomes rather than interfaces.

A button is not a job. A dashboard is not a job. AI is not a job.

They are simply possible ways of helping the user complete a job.

7. Atomic Design

Atomic Design approaches UX from the implementation side. It breaks interfaces into increasingly larger reusable structures. The hierarchy is usually:

Atoms → Molecules → Organisms → Templates → Pages

Five tiers from left to right. Atoms - button, input, badge, icon, type. Molecules - a search input combining an input, an icon and a button. Organisms - a student progress card. Templates - page structure with placeholder regions. Pages - the template filled with real content

Atoms might include:

Buttons
Inputs
Badges
Icons
Typography

Molecules combine atoms. For example: search input + icon + button.

Organisms combine molecules into larger reusable areas. For example: a student progress card.

Templates define page structure. Pages populate those templates with real content.

This model becomes extremely useful when building products with a shared UI library, design tokens and reusable components. Instead of individually designing every screen, teams create a design language that can scale across the entire product. Atomic Design names the pieces; the tokens underneath them are what keep every atom consistent across every page.

8. Service Design

Sometimes the user interface is only a small part of the experience.

Consider something as simple as: invite a user to an organisation.

Behind that button might be:

Invitation generation
Email delivery
Identity creation
Organisation membership
Role assignment
Permissions
Audit logging
Notification handling

Service Design looks at the entire experience rather than just the screen.

A common technique is the service blueprint. It separates the system into layers:

User actions - what the person does.
Frontstage - what the person sees.
Backstage - what happens behind the interface.
Supporting systems - databases, authentication, notifications, APIs and infrastructure.

For complex platforms involving multiple roles, organisations and workflows, Service Design becomes just as important as traditional UI design.

These models are not competitors

One of the biggest misconceptions about UX methodologies is that a team has to choose one. In reality, good product teams combine them.

A practical workflow could look like this:

Jobs To Be Done
  Understand what users are trying to accomplish.
        ↓
Double Diamond
  Explore and define the real problem.
        ↓
Design Thinking
  Generate and test user-centred solutions.
        ↓
Service Design
  Understand how the entire system supports the experience.
        ↓
Lean UX
  Validate assumptions before investing heavily.
        ↓
Agile UX
  Build and improve continuously.
        ↓
Atomic Design
  Turn the experience into a scalable design system.

Each model answers a slightly different question.

Do not run all eight as a checklist

The list above is a shape, not a process. A two-person startup will lean on Jobs To Be Done and Lean UX and barely touch a service blueprint. A platform with four user roles and organisation-level permissions cannot skip Service Design. Pick the models that answer the questions you actually have open.

UX is ultimately about reducing uncertainty

UX design is sometimes mistaken for visual design. Colours, typography, spacing and components matter, but they come later.

The deeper purpose of UX is to reduce uncertainty.

Before building, we want to know: are we solving the right problem?

Before shipping, we want to know: can users actually use the solution?

After shipping, we want to know: did it improve the behaviour or outcome we expected?

That is why UX models exist. They give product teams a repeatable way to move from assumptions to evidence.

And perhaps the most important principle is this:

Do not start with the screen. Start with the problem the screen is supposed to solve.

The best UX is rarely the interface with the most features.

It is usually the one that makes the user's next decision obvious.