A hospital commissions new scheduling software. Managers specify reporting needs, designers sketch screens, and nurses are invited to a workshop after the core workflow has been selected. The nurses identify a problem: the proposed schedule treats handovers as empty time, although those minutes carry vital coordination work. The team records the observation but says the procurement contract cannot change. Was that participatory design? People took part, yet the consequential decision may already have been made.
Participatory design is an approach in which people affected by a design take an active role in shaping its questions, alternatives and decisions. It grew from work on technology and workplace democracy, especially Scandinavian projects that treated workers’ knowledge and organizational power as central to systems design. Its mechanism is not a magic workshop technique. Participation can bring situated knowledge into view, create shared representations of possible futures, and redistribute some influence over what gets built. Whether it does so depends on who participates, when, with what resources, and with which authority.
From workplace democracy to contemporary design
Early Scandinavian participatory design was tied to the workplace politics of computerization. Ehn’s work-oriented design account situated computer artifacts within the skills and social relations of work, rather than treating technology as an isolated technical object. Workers and their representatives were not merely sources of requirements. They had a stake in how new systems would alter jobs, autonomy and cooperation. That history matters because participation was a claim about democratic influence in technological change, not only a way to discover usability problems.
The tradition did not imply that every project could dissolve differences between workers, management and designers. It drew attention to those differences. If a new tool changes who can see performance data or who controls a work pace, a pleasant interface cannot answer the political question. The design process must identify where authority resides and what alternatives are open. People may need time, technical explanation or collective organization to challenge a proposal effectively. A project that invites attendance without these conditions can reproduce the power imbalance it says it addresses.
Bødker’s discussion of conditions for participation makes this problem concrete. Participation has to be created within real organizational conflicts and resource constraints. The opportunity to attend a meeting is not equivalent to the capacity to shape a system. Paid time, access to decision makers, understandable prototypes and a process for handling disagreement can matter more than the number of sticky notes produced. These conditions are not administrative extras; they are part of the mechanism by which participation could affect design.
Contemporary participatory design spans public services, health care, education, civic technology, community settings and AI systems. The expansion creates new opportunities and ambiguity. A project may call a survey, usability test or consultation “participation,” while another gives participants authority to define the problem and veto a harmful option. Halskov and Hansen’s review of participatory design research documents this diversity. The label alone cannot tell a reader how much influence participants had.
How participation can change a design
The first route is situated knowledge. People who use a system encounter workarounds, informal coordination, exceptions and harms that a remote design team may not see. Nurses in the opening example know what happens during handover because they perform it under pressure. Their knowledge may not fit the categories in a specification. Observation, storytelling and collaborative mapping can help translate that knowledge into requirements, but the translation is never neutral. A designer chooses which account enters the final plan.
The second route is mutual learning. Designers bring technical possibilities and constraints; participants bring experience of activities and institutions. Together they can develop a more realistic picture of what a system might do. Ehn and colleagues’ cooperative design tradition used tangible artifacts and shared exploration partly because an abstract technical description can prevent non-specialists from contesting a proposal. A mock-up lets participants show a missed step or demonstrate why a sequence fails in practice. Designers, in turn, can explain tradeoffs and invite alternatives.
The third route is generative. Participation can create options that would not arise from interviewing users about a predefined product. Participants can sketch future arrangements, role-play a service, rearrange a workflow or compare prototypes. They may challenge whether the proposed technology is needed at all. This last possibility is a test of the process’s openness. If the only acceptable outcome is adoption of the commissioned system, participants have limited room to shape the problem.
The fourth route is governance. Bratteteig and Wagner distinguish kinds and streams of design decisions and show why influence is more complex than speaking in a meeting. The choice of problem, funding, interface, deployment site and evaluation criterion may be made at different times by different actors. Participants can win a visible interface change while having no effect on data ownership or staffing. A credible process traces decisions and explains which ones participants could alter.
None of these routes guarantees a good outcome. Situated knowledge can be ignored. Mutual learning can become a one-way exercise in teaching participants to accept a fixed plan. A workshop can generate creative options that never survive procurement. Governance can remain opaque. Participatory design is therefore a set of conditions and practices for influence, not an automatic effect of gathering people in a room.
Who counts as a participant?
“Users” are not a single group. A scheduling system affects nurses, patients, coordinators, administrators, temporary staff and people whose information is processed. Some groups use the interface directly; others bear consequences without seeing it. A project must decide whose experience matters, who is absent, and how participation can account for indirect stakeholders. The answer may change as the design develops.
Representation is difficult. One volunteer cannot stand for every colleague. People with the least time or institutional security may be least able to attend. A community leader may have authority in one setting but not represent every member’s interests. If designers treat attendance as consent by an entire group, they overclaim. Recruitment should be explained, dissent recorded, and uncertainty about representativeness kept visible. Sometimes separate sessions are needed so junior staff can speak without managers present.
Participation can impose costs. People may disclose sensitive experiences, repeat painful stories, or spend unpaid time improving a service that will later exclude them. A process should make compensation, accessibility, privacy, translation and aftercare proportionate to the task. It should also tell participants what can change and what cannot. An honest constraint may narrow the scope but respects their time better than a promise of influence that the project cannot deliver.
Expertise is distributed rather than interchangeable. Clinicians may know clinical safety, patients may know lived burdens, engineers may know system limits, and operations staff may know maintenance realities. Participation does not mean every opinion becomes a technical requirement or that professional responsibility disappears. It means that decisions are made with the relevant knowledge and affected interests visible, and that disagreements are addressed rather than concealed behind the word “co-design.”
Power enters before the workshop
The commissioning brief defines the initial field of possibility. If a funding body has already chosen an AI system and asks people only what color its dashboard should be, participation begins downstream of the decision that matters most. A stronger process can revisit the framing: What problem is being solved? Who described it? What nontechnical alternatives exist? Which harms might the new system create? Participants should not have to accept the sponsor’s definition to be counted as cooperative.
Time is another source of power. A manager can attend a meeting as part of a paid job, while a patient must arrange transport and childcare. A designer can read all documentation; a participant may receive a brief summary. Technical vocabulary can make certain objections seem uninformed even when they express a real concern. Equal speaking time does not erase these asymmetries. Materials, facilitation and compensation can reduce some barriers, though they cannot remove institutional hierarchy by themselves.
Decision rules should be explicit. Does the group advise, co-decide or approve? Can participants reject a prototype, demand a new study or require a written response? Who resolves conflicts when affected groups disagree? Bratteteig and Wagner’s work is useful here because it redirects attention from participation as presence to participation as influence over decisions. A project may legitimately retain legal accountability with an institution, but it should not describe advisory input as shared control.
Feedback loops are essential. Participants need to see what happened to their contributions, including why a suggestion was rejected. Otherwise the process can extract insights without accountability. A decision log need not be bureaucratic. It can record an issue, the alternatives discussed, who decided, what changed and what remains open. The record also helps later teams avoid telling a simplified story in which every workshop automatically led to a successful design.
Methods serve the relationship
Common techniques include contextual observation, workshops, cooperative prototyping, design games, scenario building, role play and iterative testing. None is inherently participatory. A prototype can invite real reconfiguration or merely ask participants to endorse a finished concept. An interview can open a question or seek quotes to justify a prior plan. The method’s meaning depends on timing, control of the agenda and the route from participant input to decision.
Low-fidelity artifacts can be useful because they signal that change is possible. Paper screens or simple physical models may make it easier to annotate, move and reject elements. Yet a rough prototype can also hide hard constraints, and a polished one can sometimes help participants understand consequences. The best representation matches the decision at hand. If the issue is who sees sensitive data, a diagram of data flows may be more useful than a screen layout.
Iteration lets learning accumulate. Participants may not foresee a problem until they try an alternative. Designers can return with a revision, explain tradeoffs and invite another round. This is more meaningful than a single event called “the co-design workshop.” It is also costly. The organization must reserve time and budget to respond. If there is no capacity to revise, the process should say so before recruiting participants.
Some participation occurs after deployment. People appropriate systems, create workarounds and organize to demand changes. Participatory design can treat this as ongoing infrastructuring rather than assume a project ends when software launches. Yet post-launch feedback should not substitute for participation in major earlier choices, especially where harms may be difficult to reverse. Both stages have a role.
Relation to value-sensitive design
Value-sensitive design, or VSD, offers methods for identifying values implicated in technology and examining direct and indirect stakeholders. A critical review of value-sensitive AI design argues for attention to sociotechnical process and the way values are operationalized. Those concerns overlap with participatory design, but the approaches are not synonyms. A team can conduct conceptual value analysis without giving affected people decision influence. It can also hold participatory workshops without explicitly analyzing conflicts among privacy, fairness, autonomy and other values.
Participatory design’s distinctive question is who has a say in shaping the technology and its institutional setting. VSD’s distinctive emphasis is systematic examination of human values in design, often through conceptual, empirical and technical investigations. Projects can combine them. A participatory process may reveal which values matter to a community, while a VSD analysis may help clarify conflicts and indirect effects. Neither framework alone proves that power was redistributed or that the final system is just.
Research on value-sensitive AI is useful as adjacent evidence about sociotechnical design, not as a primary history of Scandinavian participation. Treating it as the whole basis for participatory design would erase the political and workplace roots of the practice. Classic participatory sources are needed alongside the value-sensitive comparison.
Scope and boundary conditions
Participation is especially valuable when designers lack access to situated knowledge, when technology will change work or civic relations, and when affected people have legitimate claims over the design problem. But participation cannot by itself settle scientific evidence, legal duties or conflicts between groups. If an unsafe design is popular in a workshop, the team still has responsibilities. If one group benefits and another bears the cost, participation must reveal that distribution rather than treat consensus among attendees as universal consent.
Scale creates challenges. A local workshop can support detailed exchange, while a national digital service affects millions. Sampling, deliberative methods, representatives and public accountability can widen input, but each sacrifices something. Online surveys reach more people yet often give little control over framing. Small groups allow deeper negotiation yet may exclude others. The choice should follow the decision and population, with limitations stated plainly.
AI systems add further difficulties. Their behavior can change after deployment, outputs vary by context, and organizations may rely on vendors whose models and data practices participants cannot inspect. A participatory session on an interface cannot resolve hidden training-data or governance decisions. It can still surface concerns and shape use rules, escalation pathways, documentation and procurement criteria. To be meaningful, the process needs access to the decisions it claims to influence.
Success is not identical to agreement. A process may uncover an irreconcilable conflict or lead to a decision not to build. That can be an important result if participants’ reasons are documented and considered. Conversely, a smooth workshop may indicate that dissent was suppressed or that major decisions were unavailable for discussion. The quality of participation should be judged in relation to decision rights, learning and accountability, not atmosphere alone.
What the evidence does not show
The cited work does not show that any workshop labeled participatory produces a democratic or effective outcome. It does not establish that attendance equals consent, that a participant sample represents everyone affected, or that every conflict can be resolved by co-creation. Case studies and conceptual accounts illuminate mechanisms and power relations but cannot supply a universal effect size for participation across organizations.
Participatory design does not replace accessibility testing, safety evaluation, clinical evidence, technical validation or legal accountability. It can reveal what those evaluations should ask and whose experience they should include. It cannot guarantee that a chosen system is safe or equitable merely because stakeholders were consulted. When organizational authority remains unchanged, the honest claim is narrower: people contributed information or advice under specified conditions.
Nor does the Scandinavian tradition prescribe one unchanging toolkit for every contemporary setting. Its durable challenge is to make technological change contestable by those living with it. The form this takes may differ in a unionized workplace, a patient community or a public AI service. Researchers and practitioners must show how the principle was enacted rather than invoke the history as a credential.
Return to the scheduling system
The nurses’ observation about handovers is valuable situated knowledge. If the contract truly fixes the workflow, the team can document the problem and seek a procurement change, pilot an alternative, or explain why the constraint cannot be moved. If it merely thanks the nurses and continues, the workshop has generated input but little participation in the consequential decision. The distinction turns on influence, not courtesy.
Participatory design works when the people affected by a system can help define the problem, explore alternatives and see how their contributions shape decisions. It requires methods, resources and institutional willingness. Its promise is a more accountable way to make technology in shared life; its boundary is that invitation alone does not confer power.
Research references
- Ehn, P. (1988). Work-oriented design of computer artifacts. Arbetslivscentrum. View source
- Bødker, S. (1996). Creating conditions for participation: Conflicts and resources in systems design. Human-Computer Interaction, 11, 215–236. View source
- Bratteteig, T., & Wagner, I. (2014). Disentangling participation: Power and decision-making in participatory design. Springer. View source
- Halskov, K., & Hansen, N. B. (2015). The diversity of participatory design research practice at PDC 2002–2012. International Journal of Human-Computer Studies, 74, 81–92. View source
- Robertson, T., & Simonsen, J. (2013). Participatory design: An introduction. In J. Simonsen & T. Robertson (Eds.), Routledge international handbook of participatory design. Routledge. View source
- Sadek, M., Calvo, R. A., & Mougenot, C. (2024). Designing value-sensitive AI: A critical review and recommendations for socio-technical design processes. AI and Ethics, 4, 949–967. View source