Framework ⚡ High

Participatory Design

The people who will live with the design should have a hand in making it.

Co-Design Community Design Public Services Healthcare UX Workplace Tools Social Innovation

01 — TL;DR

Two sentences.

Participatory Design positions people who will use or be affected by a design as active co-designers, not research subjects. The distinction from conventional user research is fundamental: in PD, users are not observed from behind a one-way mirror — they are in the room, shaping artefacts, exercising genuine agency over the outcomes that will affect their lives.

The framework originated in the Scandinavian workplace democracy movements of the 1960s and 1970s, most notably through the UTOPIA project, which brought typographers into the design of the computer systems that would replace their tools. Its political foundation matters: Participatory Design rests on the principle that people have a democratic right to influence the technologies and systems that shape their work and daily experience. What makes it distinctive is not just the method but the redistribution of design authority.

02 — When to Use

Apply this when…

→ You are designing for a community whose daily context differs significantly from yours — and assumptions about their needs are likely to be wrong

→ You are building workplace tools where frontline workers hold domain knowledge that designers and product managers cannot access through observation alone

→ The project involves public services or healthcare where design decisions directly affect people's access to essential resources

→ You are serving a community that has historically been designed for without their input — and the resulting products reflect it

→ The core problem is embedded in lived experience that cannot be fully understood through interviews, analytics, or desk research

→ A product has failed adoption despite technically correct implementation — a signal that the design process missed something only participants could surface

When NOT to apply it

Skip it when the decisions are primarily technical with no meaningful impact on user experience or workflow. Skip it when the timeline is too constrained for genuine participation — rushing PD produces worse outcomes than not attempting it, because it creates the appearance of involvement without the substance. And skip it when the organisation cannot or will not act on what participants produce — running participatory workshops and then ignoring the output is worse than never asking.

03 — How It Works

The mechanism

Participatory Design works by closing the knowledge gap between the people who understand the problem domain and the people who have the skills to build solutions. Traditional design processes treat this gap as something to bridge through research — PD treats it as something to eliminate by putting both parties in the same room with shared authorship.

The UTOPIA project and democratic design

In the 1980s, Scandinavian researchers worked with newspaper typographers to co-design the computer systems that would transform their work. The UTOPIA project established a core principle: workers have a democratic right to influence the tools they will use. This was not a usability exercise — it was a political commitment. The typographers did not review wireframes; they shaped the system architecture, decided which tasks the software should automate and which it should leave to human judgment. The resulting system was adopted because the people who would use it had authored it.

Design games, mock-ups, and future workshops

PD uses specific methods designed to equalise the power dynamic between designers and participants. Design games give participants structured ways to express preferences without needing design vocabulary. Mock-ups — physical or paper prototypes made by participants — externalise tacit knowledge that interviews cannot surface. Future workshops ask participants to critique the present, envision a preferred future, and then collaboratively plan the transition. These methods exist because traditional design tools — wireframes, user stories, journey maps — privilege the designer's literacy over the participant's knowledge.

Participants are experts in the problem, not the solution

The most common misunderstanding of PD is that participants replace designers. They do not. Participants bring irreplaceable domain knowledge — the nurse who knows that shift handovers are where information is lost, the social worker who knows which questions make clients shut down. Designers bring the ability to synthesise, structure, and translate that knowledge into buildable artefacts. PD works when both forms of expertise are present and neither is subordinate to the other. The designer's job shifts from authoring solutions to facilitating a process where solutions emerge from shared understanding.

Measuring participation: adoption, satisfaction, design-fit

You measure PD's effectiveness through three lenses. Adoption rates: products designed with genuine participation consistently show higher uptake because the people who will use them have already validated the core assumptions during the design process. Participant satisfaction: did participants feel their contributions shaped the outcome, or did they feel consulted and then ignored? Design-fit scores: how well does the final product match the actual workflows, language, and mental models of the people it serves? If the product requires training to use in a domain where participants were involved, something went wrong in the participation.

PD vs co-design: the distinction matters

Co-design has become a fashionable label applied to any process that includes users. But running a focus group is not co-design, and co-design is not necessarily Participatory Design. PD requires that participants have genuine decision-making authority — not just input. When organisations label consultation as co-design, they engage in what critics call "co-design washing": borrowing the legitimacy of participation without redistributing any actual power. The test is simple: can participants point to a specific design decision that exists because they made it, not because a designer agreed with their suggestion?

04 — Real Example

The Homeless Youth Portal — navigation by crisis, not by service

A UK charity building a digital portal for homeless young people hired 8 young people with lived experience of homelessness as paid co-designers throughout the project. They were not consulted at the end — they participated from the first brief through to the final build review, attending the same workshops as the design team and holding equal decision-making authority over the interface.

The key design decision that emerged: navigation should be organised by crisis questions — "Where can I sleep tonight?", "How do I get food now?", "I need to talk to someone" — not by service categories like "Housing Services", "Food Banks", "Mental Health". The professional designers had assumed service-category navigation was intuitive. The co-designers knew from experience that someone in crisis does not think in institutional categories — they think in urgent needs. No amount of user interviews could have surfaced this with the same clarity, because the insight required authorship, not observation.

UK charity · Homeless youth portal · Participatory Design

Lived experience produces navigation no observation could

Doing it right — lived experience produces navigation no observation could

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Know a product designed with genuine community input — or one that clearly was not? Submit what the team got right, or what they missed by excluding the people who would use it. Every approved example gets attributed to you.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen Participatory Design applied well or ignored? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗ Consulting instead of co-designing. The most common failure is inviting participants to review decisions that have already been made. Showing wireframes to a focus group and asking "does this work?" is user testing, not Participatory Design. PD requires participants to be present when design options are generated, not just when they are evaluated. If participants only see finished artefacts, they have been given the illusion of involvement without the substance.

✗ Selecting the easiest-to-recruit participants. Teams default to participants who are articulate, available, and comfortable in workshop settings — which systematically excludes the people whose needs are hardest to meet. Genuine PD requires intentional recruitment that includes marginalised, hard-to-reach, or less confident participants. The people least likely to volunteer are often the ones whose lived experience would most transform the design.

✗ Treating participant contributions as raw material. Some teams collect ideas from participants and then redesign them in the studio without attribution or traceability. The result looks polished but has been stripped of the contextual knowledge that made the original contributions valuable. If the designer's refinement removes the participant's intent, the participation was performative. Contributions should be traceable from workshop to final product.

✗ Not feeding back what contributions produced. Participants invest time and emotional labour. If they never learn what happened to their input — which ideas were implemented, which were set aside and why — the relationship is extractive. Closing the loop is not optional politeness; it is a structural requirement of the framework. Participants who feel their contributions disappeared into a void will not participate again, and word will spread in the community.

07 — Variations & Related Principles

Connected ideas

Participatory Design shares territory with several frameworks that also centre users — but differs in how much authority it grants them. The principles below either complement PD, sharpen specific aspects of it, or offer a contrasting approach to the same challenge.

The most important pairing in this list is Participatory Design with Contextual Inquiry. CI provides the observational foundation — understanding what people actually do in context — that makes participatory sessions productive rather than speculative. Without CI, PD workshops risk generating ideas disconnected from actual workflows. Together they ensure that participation is grounded in observed reality and that observation leads to shared authorship rather than designer interpretation.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Team · No prep

The Authorship Audit

Pick the last significant design decision your team made — a navigation structure, a workflow change, a feature scope cut.

1. List every person who was in the room (or on the call) when that decision was made. Write their names and roles.

2. Next to each name, classify the type of knowledge they brought: D (Design/technical — knows how to build it), P (Process — knows how the organisation works), or E (Experience — lives with the problem daily). Count the letters. Most teams will find the room was heavy on D and P, light on E.

3. Identify the stakeholders who were absent — the people who will use this feature daily, or whose workflow it will change. Write their roles or descriptions. These are the missing co-designers.

4. For the decision you audited, ask: would the outcome have been different if one of those absent stakeholders had been in the room with equal authority? If the answer is "probably yes" or "I do not know," that is your signal that participation was missing where it mattered.

10 minutes