For the broader definition, types, and examples beyond product UX, read our guide to design frameworks.
Contents
UX framework definition
| Part | Meaning |
|---|
| Principles | The tradeoffs the product should make consistently. |
| Methods | How the team researches, maps, prototypes, tests, and reviews work. |
| Patterns | Reusable ways to solve repeated flow and interface problems. |
| Standards | Accessibility, content, visual, interaction, and quality requirements. |
| Metrics | Signals that show whether the experience is easier, clearer, safer, or more useful. |
Principles
- Meaning
- The tradeoffs the product should make consistently.
Methods
- Meaning
- How the team researches, maps, prototypes, tests, and reviews work.
Patterns
- Meaning
- Reusable ways to solve repeated flow and interface problems.
Standards
- Meaning
- Accessibility, content, visual, interaction, and quality requirements.
Metrics
- Meaning
- Signals that show whether the experience is easier, clearer, safer, or more useful.
UX framework vs design system vs process
| Term | Main job | Example output |
|---|
| UX framework | Guides experience decisions across flows and product moments. | Principles, journey rules, research inputs, measurement model. |
| Design system | Standardizes visual and UI implementation. | Components, tokens, patterns, documentation, code. |
| UX process | Defines the sequence of work. | Discovery, define, prototype, test, ship, learn. |
| Product strategy | Defines where the product should go and why. | Positioning, roadmap bets, customer segments, business constraints. |
UX framework
- Main job
- Guides experience decisions across flows and product moments.
- Example output
- Principles, journey rules, research inputs, measurement model.
Design system
- Main job
- Standardizes visual and UI implementation.
- Example output
- Components, tokens, patterns, documentation, code.
UX process
- Main job
- Defines the sequence of work.
- Example output
- Discovery, define, prototype, test, ship, learn.
Product strategy
- Main job
- Defines where the product should go and why.
- Example output
- Positioning, roadmap bets, customer segments, business constraints.
Common types of UX frameworks
| Framework type | Best for | Example |
|---|
| Discovery framework | Understanding the problem before solution work starts. | Double Diamond, Jobs To Be Done, interview synthesis. |
| Flow framework | Mapping tasks, states, risk, and user decisions. | Journey maps, service blueprints, task flows. |
| Measurement framework | Connecting UX goals to product metrics. | HEART: happiness, engagement, adoption, retention, task success. |
| Accessibility framework | Making products usable across abilities, devices, and input methods. | WCAG 2.2, internal accessibility checklists. |
| Design system framework | Keeping product UI consistent and reusable. | Component libraries, pattern rules, contribution models. |
Discovery framework
- Best for
- Understanding the problem before solution work starts.
- Example
- Double Diamond, Jobs To Be Done, interview synthesis.
Flow framework
- Best for
- Mapping tasks, states, risk, and user decisions.
- Example
- Journey maps, service blueprints, task flows.
Measurement framework
- Best for
- Connecting UX goals to product metrics.
- Example
- HEART: happiness, engagement, adoption, retention, task success.
Accessibility framework
- Best for
- Making products usable across abilities, devices, and input methods.
- Example
- WCAG 2.2, internal accessibility checklists.
Design system framework
- Best for
- Keeping product UI consistent and reusable.
- Example
- Component libraries, pattern rules, contribution models.
Choose a UX framework by the decision you need to make
Use a discovery framework when the team needs to understand a user problem before deciding what to build.
Use a flow framework when a key journey has unclear steps, states, handoffs, or failure points.
Use a measurement framework when the team needs to connect UX work to product outcomes such as adoption, task success, retention, or satisfaction.
Use an accessibility framework when teams need repeatable requirements for inclusive design across devices, content, and interactions.
Use a design system framework when the same UI decisions are being rebuilt inconsistently across screens, products, or engineering teams.
The right UX framework should make a recurring product decision easier to evaluate and repeat. If it only creates documentation, it is not yet improving the product experience.
What a UX framework gives a product team
| Benefit | What changes in practice |
|---|
| Clearer decisions | Teams know which evidence matters before debating interface options. |
| More consistent flows | Repeated product moments behave in familiar ways. |
| Faster handoff | Design and engineering share rules, not only screens. |
| Better accessibility | Accessibility is built into the decision model instead of checked at the end. |
| Better AI-assisted execution | AI-generated copy, UI, and documentation have clearer constraints to follow. |
Clearer decisions
- What changes in practice
- Teams know which evidence matters before debating interface options.
More consistent flows
- What changes in practice
- Repeated product moments behave in familiar ways.
Faster handoff
- What changes in practice
- Design and engineering share rules, not only screens.
Better accessibility
- What changes in practice
- Accessibility is built into the decision model instead of checked at the end.
Better AI-assisted execution
- What changes in practice
- AI-generated copy, UI, and documentation have clearer constraints to follow.
When a framework becomes too heavy
| Signal | What to fix |
|---|
| Designers ignore it. | Reduce it to the decisions that actually repeat. |
| Product managers see it as design-only documentation. | Connect rules to product risk, activation, support, conversion, or retention. |
| Engineers receive screens but not rationale. | Add flow rules, states, constraints, and acceptance criteria. |
| Every exception becomes a fight. | Define an exception process and document why rules were broken. |
| It looks polished but does not change behavior. | Add ownership, review cadence, and metrics. |
Designers ignore it.
- What to fix
- Reduce it to the decisions that actually repeat.
Product managers see it as design-only documentation.
- What to fix
- Connect rules to product risk, activation, support, conversion, or retention.
Engineers receive screens but not rationale.
- What to fix
- Add flow rules, states, constraints, and acceptance criteria.
Every exception becomes a fight.
- What to fix
- Define an exception process and document why rules were broken.
It looks polished but does not change behavior.
- What to fix
- Add ownership, review cadence, and metrics.
Related reading