Contents
Design framework definition
| Framework part | What it controls |
|---|---|
| Problem framing | How the team decides what problem is worth solving. |
| Methods | How the team researches, prototypes, tests, and reviews work. |
| Principles | What tradeoffs the product should make consistently. |
| Patterns | Which solutions should repeat across screens, services, or channels. |
| Standards | Quality requirements for accessibility, content, UI, brand, and implementation. |
Main types of design frameworks
| Type | Best for | Examples |
|---|---|---|
| Process framework | Guiding work from discovery to delivery. | Double Diamond, Lean UX, design sprint. |
| UX framework | Making product experience decisions repeatable. | Journey maps, HEART, Jobs To Be Done, accessibility-first rules. |
| Design system | Keeping UI, visual language, and code consistent. | Material Design, Apple HIG, Carbon, GOV.UK Design System. |
| Service framework | Designing an end-to-end service across channels and teams. | GOV.UK Service Manual, service blueprints. |
| Brand framework | Connecting positioning, voice, identity, and touchpoints. | Brand architecture, messaging hierarchy, identity system rules. |
What design frameworks are useful for
| Use | What improves |
|---|---|
| Starting a project | The team aligns on the problem before jumping into screens. |
| Scaling a product | Patterns repeat, quality stays more stable, and decisions are easier to explain. |
| Working across disciplines | Product, design, engineering, content, and research share the same language. |
| Using AI in production | Generated outputs have clearer constraints and less room to drift. |
| Auditing quality | The team can compare work against known principles and standards. |
How to choose one
| If the problem is | Use this kind of framework |
|---|---|
| We do not understand the problem yet. | Discovery or process framework. |
| Our product flows feel inconsistent. | UX framework and journey rules. |
| Our UI keeps being rebuilt differently. | Design system with components, tokens, and contribution rules. |
| Our service breaks across departments or channels. | Service design framework. |
| Our brand feels fragmented across product, marketing, and sales. | Brand framework and architecture rules. |
Where frameworks go wrong
| Mistake | Better move |
|---|---|
| Using a famous framework because it is familiar. | Use the framework that matches the product decision. |
| Treating the diagram as the work. | Use the diagram to structure evidence, decisions, and tradeoffs. |
| Making every project follow the same path. | Keep the core rules, adjust the method to risk and scope. |
| Documenting too much. | Write the smallest rule that changes behavior. |
| Ignoring maintenance. | Assign ownership and review the framework when the product changes. |
