UX Design Frameworks: Which to Use and When

A UX design framework is a structured way to reach one kind of decision: what problem to solve, what to build first, whether the experience improved, how the interface should be assembled. Pick the framework for the decision and the uncertainty you actually have, not because its diagram looks good in a deck. A framework organises thinking. It does not bring the evidence, it does not set the priorities, and it has never shipped a product on its own.

We have been fixing products for 15 years, and every few years the industry discovers a new diagram. Diamonds, loops, pyramids, hearts. The diagrams change. The mess underneath does not: a team that cannot say what it is deciding, with no evidence for its key assumptions, and a budget quietly draining while everyone argues about which stage they are in.

Here is how it usually looks. Someone reads a list of the top ten UX frameworks. The team buys a two-day workshop. Eight people spend sixteen person-days producing a wall of sticky notes, a persona with a stock-photo name and a poster of the process. Three months later the product is the same, activation is the same, and the users you paid ads and sales calls to acquire are still leaving in week one. The framework did not fail. It was hired for a job nobody defined.

A framework costs next to nothing to adopt. Running the wrong one for a quarter costs a quarter, and the users who churned while the team was busy.

What a UX design framework is — and what it is not

A UX framework is a repeatable structure for a specific product decision. A useful one tells you four things before you start: which decision it clarifies, what input it needs, what artifact it produces, and when to stop using it. If you cannot fill in those four lines, you do not have a framework. You have a poster.

Think of a framework as scaffolding. Scaffolding lets builders reach the parts of the house they could not reach otherwise. It is essential while the walls go up. Nobody moves into scaffolding, and a building that still wears it two years later is not under construction. It is abandoned. Teams do exactly this with frameworks: they erect the structure, forget what they were building and start charging rent for the scaffolding.

It also helps to be clear about what a framework is not:

• Not a UI framework. React, Bootstrap and Tailwind are code frameworks for building interfaces. They say nothing about which problem the interface should solve. A search for “UX framework” that ends in a component library has taken a wrong turn.
• Not a process by itself. A product still needs the baseline sequence of research, flows, prototypes, testing and delivery. If your team has not got that sequence working, start with our guide to the UX design process from problem to validated product, then come back and choose frameworks to strengthen specific steps.
• Not a guarantee. No framework makes a product succeed. It makes the team’s reasoning visible, so bad assumptions get caught earlier and cheaper. That is the whole value, and it is plenty.

Sort frameworks by the job they do

Most lists of UX frameworks mix things that have nothing in common. A process model sits next to a metrics model, next to a psychology model, next to a way of naming interface components. It is like a school timetable that lists “Maths”, “Wednesday”, “Room 4” and “Pencils” as four subjects.

Sorted by the job they actually do, the common ones fall into six groups:

• Process frameworks decide the order of work: explore, define, build, test. Design Thinking, Double Diamond, User-Centered Design, Lean UX and Agile UX live here.
• Research frameworks decide what to learn about people and how to describe it. Jobs to Be Done is the one that earns its keep.
• Evaluation frameworks decide whether the experience got better. HEART is the common one.
• Prioritisation frameworks decide what goes first. They turn a long list of problems into a short, ranked one, and every other framework on this page feeds them. RICE is the common example.
• Behaviour frameworks explain why people repeat an action. Hooked is the best known, and the most abused.
• Design-system frameworks decide how an interface is assembled from reusable parts. Atomic Design is the reference.

This split matters for money. When a team with a retention problem adopts a second process framework, it pays for new rituals and gets the same churn. When a team that cannot agree what to build adopts a metrics framework, it gets beautiful dashboards of the wrong product. Horses for courses: match the group to the problem first, then pick the framework inside it.

UX design frameworks compared

Here is the comparison we run when a team asks which framework to use. Read it by row, and look hardest at the last column. Every framework fails in a predictable way, and the failure is usually cheaper to prevent than to discover.

Two things jump out. First, no row says “use for everything”. Second, every “input” column needs something the framework does not provide: users, evidence, a baseline, a known product. The framework is the gym membership. You still have to lift the weights.

Design Thinking: for problems nobody has framed yet

Design Thinking is a process for problems where the team is not sure what the problem is. Stanford’s d.school, which popularised the model, describes it as five modes: empathize, define, ideate, prototype and test (d.school Design Thinking Bootleg, as of 2026). The team goes out to understand people, narrows down a problem worth solving, generates options, makes cheap versions of them and puts them in front of users.

When it earns its keep. A new product idea, a new audience, or a live product where nobody can explain why a key journey fails. Its strength is that it forces the team to meet users before deciding anything.

Where it breaks. Design Thinking gets sold as a workshop format, and a workshop is a cooking class where everyone chops vegetables beautifully and nobody serves dinner. The team leaves energised, the sticky notes are photographed, and on Monday nobody owns the next step. The workshop invoice is paid. The problem is still unframed.

The other trap: “empathize” done from the meeting room. Imagining users is cheaper than meeting them, which is exactly why the output is worthless.

Double Diamond: for teams that jump straight to solutions

The Double Diamond comes from the UK Design Council, which now presents it inside its wider Framework for Innovation (Design Council, as of 2026). It has four stages: discover, define, develop and deliver. The first diamond opens up to understand the problem and closes on a definition. The second opens up to explore solutions and closes on one that works.

When it earns its keep. When the team has a habit of starting with a solution. Its real gift is a simple question at any meeting: which diamond are we in? If the answer is “the second” and nobody can show the output of the first, stop.

Where it breaks. Almost every team says it uses the Double Diamond. Most of them skip the first diamond, because “we already know the problem”. That is buying a train ticket before deciding which city you are going to. You will travel fast and comfortably, and you will arrive somewhere. Then comes the second trip, paid for with the same budget you were supposed to spend on growth.

The other failure is treating the diagram as a straight line. Real projects loop back when evidence arrives. The Design Council’s own framework allows for it. Teams that refuse to go back because “we are in deliver now” are not being disciplined. They are being stubborn with someone else’s money.

User-Centered Design: the standard behind the others

User-Centered Design (UCD) is less a method than the principle most other process frameworks borrow from. Its best-known formal definition is ISO 9241-210:2019, the international standard for human-centred design of interactive systems. It describes four linked activities: understand and specify the context of use, specify the user requirements, produce design solutions and evaluate them against those requirements (ISO, as of 2026).

When it earns its keep. Regulated and high-stakes products, enterprise tools with complex roles, anything where “we tested it” needs to be demonstrable. It gives you the vocabulary to prove users were involved and that the design was evaluated against something written down.

Where it breaks. UCD is the Hippocratic oath of product design: everyone swears it, and it does not tell anyone which treatment to prescribe. Plenty of teams say they are user-centred because they once ran a survey. The standard asks for more: a written context of use, explicit requirements, evaluation with users. Without those, “user-centred” is a word on the About page, and the product is still designed around the loudest person in the room.

The evidence it should leave behind is dull and valuable: a description of who uses the product, where and under what pressure; a list of requirements that design can be checked against; and evaluation results that say which requirements were met. When a big enterprise buyer or an auditor asks how you know the product works for its users, that paper trail is the answer. Without it, the answer is a shrug and a demo.

Lean UX: for turning opinions into testable bets

Lean UX, set out by Jeff Gothelf and Josh Seiden, treats every requirement as a hypothesis. Instead of “build the export feature”, the team writes a statement in the shape they recommend: we believe this outcome will be achieved if these users get this benefit from this change, and we will know we are right when we see this signal (Gothelf and Seiden’s Lean UX materials, as of 2026). Then it finds the cheapest way to learn whether the belief is true.

When it earns its keep. Early products and new features, where the team is carrying more guesses than facts. Lean UX converts arguments into experiments. The founder’s favourite idea and the engineer’s objection become two hypotheses, and the users settle it instead of seniority.

Where it breaks. An experiment without an agreed success signal is a darts match where nobody writes down the score. Everyone remembers hitting the bullseye. Teams launch “an MVP”, look at the numbers afterwards, and find something that went up. That is not learning, it is reading tea leaves with analytics.

The other failure is organisational. Lean UX needs a team allowed to kill its own ideas. If every experiment must end in a launch because the roadmap already promised it, the method is a costume worn by a roadmap that was never going to change. Once an idea survives cheap tests, put it in front of people in structured usability testing before engineering commits to the full build.

Agile UX: for keeping design ahead of the sprint

Agile UX is less a single framework than a set of practices for fitting research and design into iterative delivery. The pattern that matters most is running design ahead of development. Desirée Sy described giving design work lead time one cycle ahead of implementation in the Journal of Usability Studies in 2007, and product teams still use variations of that dual-track idea (Journal of Usability Studies, as of 2026).

When it earns its keep. Teams already running sprints, where design keeps arriving late or half-finished. Dual tracks give research and design the lead time they need without stopping delivery. That is how we ran DAP: each flow build-ready while engineers built the previous one.

Where it breaks. It is a construction crew laying bricks while the architect is still drawing the floor above. Works fine as long as the architect stays one floor ahead. When the discovery lane is squeezed, design turns into a ticket factory: screens delivered on time for features nobody validated. The velocity chart looks great. The product fills up with features users never open, each of them paid for in full.

The artifacts that keep it honest are small: a discovery board showing what is being shaped for the next sprint and what evidence it rests on, acceptance criteria that include the unhappy states, and a short usability check on what shipped last sprint. If the discovery board is empty, the design team is not ahead. It is just typing faster.

HEART: for measuring whether the experience got better

HEART is an evaluation framework from Google researchers Kerry Rodden, Hilary Hutchinson and Xin Fu, published at the CHI conference in 2010. It stands for Happiness, Engagement, Adoption, Retention and Task success, and it comes with a companion process, Goals-Signals-Metrics: agree the goal, find the user behaviour that signals progress, then choose the metric (Kerry Rodden, as of 2026).

When it earns its keep. Live products, when the team argues about whether a release helped. HEART moves the argument from “users seem happier” to a small set of numbers everyone agreed on before the release.

Where it breaks. You don’t fatten a pig by weighing it. HEART measures, it does not improve anything. Teams build a dashboard with all five categories, three signals each, fifteen charts, and act on none of them. The other classic screw-up is measuring what is easy instead of what the goal needs: page views standing in for engagement, a satisfaction pop-up standing in for happiness, and nobody checking whether users complete the task they came for.

Pick the one or two categories tied to the decision you need to make. Adoption for a new feature. Task success for a redesigned flow. Retention when the business model depends on renewals. Leave the rest for a quarter when they matter.

Jobs to Be Done: for knowing what users are really hiring you for

Jobs to Be Done (JTBD) is a research framework. Its core idea, set out by Clayton Christensen and colleagues in Harvard Business Review in September 2016, is that people “hire” a product to make progress in a particular situation, and “fire” it when something else does the job better (HBR, as of 2026). A practical way to write it down is the job story popularised at Intercom: when a situation happens, I want to do something, so I can reach an outcome.

When it earns its keep. Positioning a new product, deciding what onboarding should lead with, and understanding why users switch to you or away from you. Nobody wants a washing machine. They want clean shirts by Monday morning. JTBD keeps the team designing for Monday morning.

Where it breaks. JTBD is only as good as the interviews behind it. The method depends on talking to people about real, recent decisions: what happened, what they tried, what made them switch. Teams skip that and write job stories at their desks, which produces fiction with a strong format. If you do not have that evidence yet, focused UX research is the input the framework is waiting for.

The money line here is direct. Every signup you paid for arrived with a job in mind. If onboarding shows them your feature list instead of that job, you have spent the acquisition budget to deliver a brochure.

Hooked: for habits — handle with care

Hooked is a behaviour framework from Nir Eyal’s book of the same name. It describes four phases: a trigger, an action, a variable reward and an investment that makes the next loop more likely (Nir Eyal, as of 2026). It explains why some products become part of a daily routine while others are forgotten after the free trial.

When it earns its keep. Products where frequent use is the point and serves the user: a team inbox, a daily planner, a finance tool someone opens every morning, a rehab program where relief comes from repetition. It is also a good diagnostic: find which phase of the loop is broken when users never come back.

Where it breaks. Hooked is powerful, and teams handle it the way a toddler handles a permanent marker: enthusiastically, everywhere, and with consequences for the walls. Variable rewards bolted onto a product with no real repeat job produce short-term engagement and long-term resentment. Worse, in products where compulsion hurts people or the business model does not need daily use, habit mechanics are a slot machine installed in a tax office.

For most B2B products the honest question is not “how do we make users come back more?” but “does the job come back, and are we there when it does?” If the job is monthly, a monthly habit is a success.

Atomic Design: for systems, not for discovery

Atomic Design is Brad Frost’s methodology for building interface design systems in five stages: atoms, molecules, organisms, templates and pages (Brad Frost, Atomic Design, as of 2026). Buttons and inputs combine into a search field, search fields and navigation combine into a header, headers sit in templates, and templates filled with real content become pages. Frost himself stresses it is a mental model, not a linear process.

When it earns its keep. A product whose screens and flows are known, where several designers and engineers keep rebuilding the same parts slightly differently. It gives everyone a shared vocabulary, and it stops you paying five times for five nearly identical date pickers.

Where it breaks. Atomic Design is a design-system framework, not a UX process. It tells you how to assemble an interface, not which interface to assemble. Teams that start with it build a warehouse of perfect components before anyone knows what the product does. The library is immaculate. The product is still a rumour.

Prioritisation frameworks: where the evidence gets cashed in

Research, experiments and metrics all end in the same place: a list of problems and ideas longer than the team can ever build. Prioritisation frameworks turn that list into an order. The one most product teams know is RICE, developed at Intercom and described by Sean McBride in 2018: score each idea for reach, impact, confidence and effort, then divide reach × impact × confidence by effort (Intercom, as of 2026).

When it earns its keep. A backlog where the loudest stakeholder usually wins. A scoring model makes everyone write down how many users an idea touches and how sure they are, and “the CEO mentioned it at dinner” stops counting as evidence.

Where it breaks. A score filled in by the idea’s own author is a school report written by the pupil. Reach gets guessed, impact gets inflated and confidence is handed out for free. The spreadsheet then launders opinion into arithmetic. Police the confidence factor: tie it to evidence from the other frameworks, such as interviews for the problem, a Lean UX test for the solution and a HEART baseline for the size of the gap. No evidence, low confidence, however strongly the founder feels.

That is why prioritisation is its own group. It does not produce insight. It is the till where the other frameworks cash in their evidence, and the place where the team finally says no, which is the cheapest design decision there is.

Which frameworks combine, and which collide

The useful combinations take one framework from each job, not three from the same one. A process framework, a research framework and an evaluation framework cover different ground, so they reinforce each other. Two process frameworks on one team compete for the same meetings, the same vocabulary and the same calendar.

Running Design Thinking and the Double Diamond on the same project is two traffic lights on one pole. Both are right in theory. The team spends the week negotiating which one it is obeying, and the vocabulary war costs more than either framework saves.

Combinations we see work, depending on the situation:

• New product, unclear problem. Double Diamond for the order of work, Jobs to Be Done for the research, Lean UX for the first experiments.
• Live product losing users. HEART to agree what “better” means, Jobs to Be Done to understand why people leave, Lean UX to test fixes before building them in full.
• Scaling product, growing team. Agile UX for the delivery rhythm, Atomic Design for the system, HEART to check each release against its goal.

Belt and braces is fine for trousers. For frameworks, three is usually the ceiling, and one well-run framework beats three half-run ones every time.

How to choose a minimal framework set

Choosing a framework is like choosing a treatment: diagnosis first, prescription second. Here is the order we work in.

1. Name the decision. One sentence: “which onboarding problem do we fix first”, “should we build the export feature”, “did the new checkout help”. If the team writes three different sentences, that is your first finding.
2. Name the biggest uncertainty. Is it the problem, the solution, whether it works, or how to scale it? That points to the job group.
3. Check the evidence you already own. Analytics, support tickets, sales-call notes, churn reasons. Many teams sit on half the answer. The framework should fill the gap, not repeat what you know.
4. Check the team. Who will run it, how much time do they have, and who can act on the output? A framework needing weekly user sessions will die in a team with no researcher.
5. Pick the smallest framework that answers the decision. One, maybe two. Write down its input, its output and its stop condition.
6. Set the stop condition before you start. “When we have a problem definition backed by twelve interviews.” “When the hypothesis is confirmed or killed.” A framework without an exit becomes a department.

Then put it on one page. The framework brief below takes twenty minutes to fill in and saves weeks of arguing about why the team is doing what it is doing.

Make the framework run on a Tuesday

A framework earns its keep on an ordinary Tuesday, not at the kickoff. A recipe only matters if someone is cooking tonight. Turning a framework into work means four boring, decisive things:

• An owner per artifact. The problem statement, the hypothesis backlog, the metrics sheet, the component library: each has one named person who keeps it current.
• A rhythm. Which meeting reviews the evidence, how often, and who decides. A hypothesis reviewed “when we have time” is never reviewed.
• A route to action. Every output ends in a backlog item, a design change or an explicit decision not to act. Research that ends in a slide deck ends.
• A stop condition. The moment the decision is made, the framework steps aside. You keep the artifacts and drop the ceremony.

This is also where the framework meets validation. A direction produced by Lean UX or Design Thinking is still a hypothesis until real users complete real tasks with it. Test before engineering commits the quarter.

Signs your framework is theatre

Framework theatre is easy to spot from outside and nearly invisible from inside. Check your team against this list:

• The process poster is on the wall, and nobody can say which stage the project is in.
• Workshops end with photos, not decisions.
• Personas have names and hobbies, and nobody can say which evidence they came from.
• Every experiment “succeeded”.
• The metrics dashboard has fifteen charts and no owner.
• The design system has more components than the product has screens.
• The team adopted a new framework this year because the old one “did not work”, and nobody wrote down why.

Three or more ticks mean the framework is papering over the cracks. The cost is not the workshop fee. It is the quarter spent looking busy while activation stays flat and the users you paid for leave through the same door as last year.

Why ANODA turns frameworks into delivery

A framework is valuable when your team can move from a decision to a complete product flow. In DAP, the developer was already building a live networking app. ANODA mapped missing screens, decision points, empty states and plan gating, then delivered wireframes and UI together flow by flow. The UI kit and handoff matched the client’s engineering rhythm.

We connect the method to the blockage: discovery for an unclear customer problem, a flow map for a broken journey, a prototype for a disputed interaction, and component rules for repeated UI work. You leave with decisions embodied in the product and a team ready to build them, rather than another workshop your roadmap has to absorb.

How we use frameworks at ANODA

ANODA starts with the decision your team needs to make and assembles the smallest useful method around it. The work has a clear destination: a prioritised product direction, complete flows and a design your engineering team can act on. Our process fits your product, deadline and existing work, so progress does not depend on adopting a new ritual.

We start with the decision the team needs to make, look at the evidence already in the building, and pick the method that fills the gap: sometimes interviews and job statements, sometimes a two-week hypothesis test, sometimes a metrics reset, sometimes simply a user flow nobody drew. Then we adapt it to the team’s size, data and deadlines, and drop it once the decision is made. You can see how that sequence of research, decisions, design and delivery runs in practice in how we work.

When the job is bigger than a method, when the team needs research, flows, prototypes and delivery together, that is a complete UI/UX design engagement, and the frameworks sit inside it where they help.

Name the decision. Select the smallest framework that answers it. Test the assumptions with evidence. Turn the result into actions someone owns. Everything else is a diagram, and diagrams do not pay back the acquisition budget.