A framework is just a named way of working. Pick the lightest one that answers the question you have today. Each card below says what it is, when to use it, how a UX designer might apply it, what goes wrong, and where to read more.
Cards start folded. Expand one at a time. The open card fills the width and the rest move below.
Discovery
Double Diamond
Design Council model: Discover and Define, then Develop and Deliver, with diverge-converge cycles separating problem and solution space.
When to use it
Problem unclear
Risk of building the wrong thing is high
Stakeholders jump to UI too early
Example for a UX Designer
Timebox Discover and Define before high-fidelity UI. Name the decision each spike unlocks. Bring evidence into Sprint Review so stakeholders see learning, not only screens.
Things that go wrong
Skipping Discover under date pressure
Endless Discover with no decision owner
Treating the model as a waterfall gate set
Discovery
Jobs to be Done
Users hire products to make progress in a circumstance. Focuses on the job, forces and competing solutions.
When to use it
Feature requests conflict
Personas are not explaining behaviour
Need sharper outcome language with the Product Owner
Example for a UX Designer
Rewrite noisy feature asks as job stories. Use jobs and forces in critique to challenge solutioneering and keep acceptance tied to user progress.
Things that go wrong
JTBD jargon with no interview evidence
Ignoring competing solutions users already hire
Jobs so broad they cannot drive design decisions
Service design
Service design blueprinting
Maps user stages against frontstage interactions and backstage people, systems and policies that make the service work.
When to use it
Multi-channel or operational services
Contact centres or caseworking absorb failure
UI changes might shift burden unseen
Example for a UX Designer
Map as-is before to-be when operations hurt. Invite staff users into research. Design recovery paths and measure contact demand alongside completion.
Things that go wrong
Pretty journey maps with no backstage truth
Designing only the happy path
No operational owner for redesigned hand-offs
Philosophy
Lean UX
Outcome-focused design with small experiments, shared understanding and reduced hand-off waste between design, product and engineering.
When to use it
Heavyweight documentation blocks learning
Design and delivery need shared hypotheses
Need faster evidence loops inside Sprints
Example for a UX Designer
Pair each material design bet with a hypothesis and the thinnest prototype that could change the backlog. Prefer learning over polished unread specs.
Things that go wrong
MVPs that never get measured
Skipping accessibility in the name of lean
Lean as an excuse for no research with real users
Evaluation
Usability heuristics (Nielsen)
Ten general principles for interaction design used for expert evaluation and critique structure.
When to use it
Need fast expert review before user testing
Critique lacks a shared language
Catching obvious interaction failures early
Example for a UX Designer
Use heuristics to structure critique severity, then validate high-risk issues with users. Do not treat heuristic scores as a substitute for research with excluded users.
Things that go wrong
Heuristic theatre without user evidence
Treating all heuristics as equal severity
Ignoring domain and accessibility specifics
Accessibility
WCAG
Web Content Accessibility Guidelines. AA is the common public-sector floor for inclusive interfaces.
When to use it
Public-facing interfaces
Inclusive design and test evidence
Service assessment or equality duty risk
Example for a UX Designer
Put WCAG 2.2 AA into critique, Ready and Done. Prefer Design System components. Test critical journeys with keyboard and assistive technology every shipping Sprint.
Things that go wrong
Treating AA as optional polish
Relying only on automated scans
Bolting accessibility on in the final Sprint
Civil Service standard
GOV.UK Design System
Styles, components and patterns for building accessible, consistent UK government services.
When to use it
UK government public-facing services
Need researched defaults for forms and questions
Preparing for service assessment
Example for a UX Designer
Default to Design System patterns. Document exceptions with user evidence and revisit dates. Contribute durable new patterns rather than inventing silent one-offs.
Things that go wrong
Novelty for its own sake
Exceptions undocumented until assessment
Visual copying without accessible behaviour
Civil Service standard
GDS Service Standard
Fourteen points on meeting user needs, providing a good service, and using the right technology for UK public services.
When to use it
UK public service build or iteration
Service assessment preparation
Need a shared quality bar across design, product and delivery
Example for a UX Designer
Attach research, accessibility and iteration evidence to Service Standard points continuously. Practice assessment questions in reviews before the panel.
Things that go wrong
Paperwork-only assessment prep
Leaving accessibility and performance to the last Sprint
Design holding all evidence alone
Team practice
Design critique
Structured review of work-in-progress against goals, constraints and evidence, ending in decisions or experiments.
When to use it
Taste wars dominate refinement
HiPPO patterns appear
Need faster quality signal than waiting for UAT
Example for a UX Designer
Run timed critiques with context first, clarifying questions second, and HiPPO last. Separate must-fix inclusion issues from taste. Leave with owners and next experiments.
Things that go wrong
Show-and-tell with no decisions
Personal attacks or silent rooms
Feedback after shipping when change is expensive
Research synthesis
Proto-personas / personas
Memorable representations of user groups grounded in research, used to keep decisions tied to real needs and constraints.
When to use it
Team keeps designing for themselves
Need a shared shorthand for priority users
Communicating exclusions and edge cases
Example for a UX Designer
Build personas from evidence, include assistive tech and constrained contexts, and retire personas that are not used in decisions. Prefer jobs and needs when personas become costume.
Things that go wrong
Fiction personas from stakeholder stereotypes
Too many personas so nobody is priority
Personas never updated after new research
Content
Content design
Designing words and structure so people can find, understand and act, especially in forms, errors and guidance.
When to use it
Form drop-off or error confusion is high
Policy language is leaking into UI
Accessibility of meaning is at risk
Example for a UX Designer
Partner with content designers on questions, help text and errors. Treat content as a primary design material in critique, not a post-visual pass.
Things that go wrong
Lorem ipsum until the week before launch
Legal text dumped into interfaces
Ignoring reading age and plain language
Synthesis
Systems thinking / journey mapping
Visualise end-to-end experience over time to find pain, opportunity and moments that matter across channels.
When to use it
Local UI fixes are not moving outcomes
Handoffs between channels confuse users
Need a shared picture for multi-team services
Example for a UX Designer
Map the journey with evidence callouts. Prioritise moments that block completion or create contact demand. Link opportunities to backlog themes with the Product Owner.
Things that go wrong
Workshop theatre maps with no owners
Aspirational journeys disconnected from ops reality
Never revisiting the map after release learning
Inclusion
Inclusive design (Microsoft / GDS lens)
Design for exclusion and diversity of circumstance from the start, recognising permanent, temporary and situational impairments.
When to use it
Risk of excluding users is material
WCAG compliance alone feels insufficient
Services used in stressful or constrained contexts
Example for a UX Designer
Expand research sampling and critique prompts beyond average users. Design for situational limits (glare, one hand, interruption) common in real public-service use.
Things that go wrong
Inclusion as a poster, not a sampling practice
Assuming assistive tech users are a niche edge
Trading inclusion away for decorative novelty
Discovery
Design Thinking
Human-centred loop of empathise, define, ideate, prototype and test. Closely related to Double Diamond practice.
When to use it
Cross-functional workshops need a simple shared arc
Stakeholders need a non-jargon discovery story
Early problem framing with mixed disciplines
Example for a UX Designer
Use Design Thinking workshops to align on problem framing, then switch to tighter research decision cards and delivery dual-track so the arc does not stall in ideation theatre.