When users stop being test subjects and start shaping the product alongside you.

Participatory design has its roots in 1970s Scandinavia — specifically in workplace democracy movements that argued workers should have genuine say in the tools they were required to use. Software was being built for factory floors and administrative offices with no input from the people actually doing the work. The result was systems that were technically functional but practically terrible.

The UTOPIA project in the early 1980s — a collaboration between researchers and newspaper workers in Sweden — became the landmark case study. Typographers and journalists co-designed the digital typesetting tools that would change their profession. The principle that came out of it: the people most affected by a system should have genuine influence over its design.

Participatory design doesn't have a fixed method — it's more of a stance that shows up in different ways depending on context:

• Co-design workshops: Users sketch interfaces, sort information, or prioritize features alongside designers. The output isn't a spec; it's shared understanding.
• Prototype co-creation: Users build rough physical or digital prototypes to articulate needs that are hard to express verbally.
• Speculative design sessions: Users are asked to imagine an ideal version of a workflow, unconstrained by current technology. Useful for surfacing latent needs the team hasn't considered.
• Embedded observation with feedback loops: Designers work in the user's environment in real time, making adjustments based on what they observe firsthand.

Participatory design earns its investment in a few specific situations:

• Internal tools with complex domain knowledge: Finance, healthcare, logistics, legal — contexts where the design team genuinely can't simulate the user's expertise. Building with them is faster than building for them and iterating.
• Products with underrepresented users: Where standard design assumptions are likely to be wrong and the cost of getting it wrong is high.
• Organizational change contexts: When the product is changing how people work, not just which tools they use. Buy-in matters as much as usability here.

It's less suited to high-volume consumer products where the user base is too large and varied to meaningfully represent in a workshop setting.

The terms are often used interchangeably, but there's a distinction worth keeping.

Participatory design refers to the broader philosophy — users as stakeholders with genuine agency in the design process. Co-design is a more specific practice — structured workshops or sessions where designers and users actively create together.

Think of co-design as one method within the participatory design approach. You can run a co-design workshop as a one-off engagement without committing to the full philosophy. But if you're doing participatory design properly, co-design sessions are typically part of how that plays out.

The biggest difficulty isn't getting users in the room — it's managing what happens once they're there.

Users can identify problems with real precision. They're less reliable at designing solutions — not because they're incapable, but because they don't have the full context of technical constraints, other users' needs, or business viability. Taking user-generated solutions too literally leads to products that serve one vocal user's preference rather than the broader audience.

Good facilitation keeps sessions focused on problems and needs, not solutions. The designer's job is synthesis — translating what users surface into decisions that serve the whole system.

There's also a power dynamic question worth asking: are users genuinely influencing the outcome, or are they being consulted in a process that was already decided? Token participation is worse than none — it creates expectations that go unmet.