Co-design

Practice

A way of working where users or stakeholders sit in the design session itself and draw the screens and flows alongside the designer.

Why it exists

Ways of hearing from users have been around for a long time. Teams ran interviews, sent surveys, sat beside people while they worked. What all of those have in common is the shape: listen, go back to your desk, and let the designer interpret.

Things fall out during that interpretation. Noa hit this on Pagedeck's permission settings screen. Two customer interviews later, back at her desk, she drew the screen — and every time she showed it she heard the same sentence: that isn't how it works at our company. She revised it three times over two weeks and got the same response all three times.

The trouble is that those administrators carry an entire org chart and approval chain in their heads, and an interview never gets all of it out of them. People answer the questions they're asked, and whatever feels obvious to them never surfaces as something worth saying at all. Co-design removes the interpretation step. Put that person in the room with a pen and a sheet of paper and the structure they couldn't put into words comes out of their hand first.

How it runs

A session runs in five steps: narrow the topic, prepare, walk the current flow, draw alone then combine, and close.

  1. Narrow what you'll draw together to a single sentence. "The permission settings screen" is about the right size. Leave it open as "the product in general" and two hours go by collecting complaints with no decision about where any of it belongs.
  2. Choose the people and gather materials. Materials means printed empty screen frames, pens, and sticky pieces that can be moved around. There's a reason nobody opens a design tool: the moment one is on screen, only the person who knows how to drive it touches anything and everyone else watches.
  3. Walk through the current flow for about fifteen minutes. Put the existing screens up and trace what happens where. When participants come from different companies, this is the step that gets everyone to the same starting point.
  4. Have everyone draw alone for five minutes, then present in turn. The solo stretch comes first so that the rest of the room doesn't get pulled toward whoever speaks first. After the presentations, the overlapping parts get merged onto one sheet.
  5. Close by writing down what everyone agreed on and what split, kept separate. Nothing that split gets decided in the room. Participants know their own situation, but they aren't the people who decide what this product does.

The paper left at the end is not a design. Moving it into a prototype — something built temporarily to see how people react — and refining it from there is the designer's work afterwards.

Who joins and when

The people to invite are the ones whose day actually changes when the screen changes. For Pagedeck's permission settings, that's the administrator at a customer who hands out access, the internal support person who fields those tickets every day, and Sofia, who lives through the first weeks of every rollout. Four to six participants works, plus a separate facilitator and a separate note-taker.

Some people are better left off the list — the ones with decision authority who don't do the work themselves. One opinion from that person and the rest of the room goes quiet, and a two-hour session turns into confirming what one person already thought. If they have to attend, seat them so they hear everyone else's drawings before they speak.

The timing is the stretch where the problem is still being narrowed. On the double diamond, which widens and narrows twice, that's the first diamond. The value is highest while it's still unsettled what the problem even is. Run it after a single direction has been chosen and it becomes a session for collecting approval, and there is already a separate procedure for that in the design review.

It also isn't something you can hold often. You're asking three or four outsiders for two hours, and with preparation and write-up the hosting side spends two days. Once a quarter, on the one topic the team hasn't been able to settle for weeks, is a realistic rate.

How it sounds at work

"Let's not decide this among ourselves — let's co-design it. Every customer has a different approval chain and we can't draw that."

Internal knowledge isn't enough to produce the screen, so outsiders should be seated in the design session.

"For next week's co-design, invite three people who actually hand out the permissions."

Pick participants by the work they do rather than by their title.

"Three of the sheets from the co-design came out nearly identical. We're starting from there."

Participants who don't know each other drew the same structure, so that part can be treated as verified and built on.

The permission settings screen did get resolved this way in the end. Noa brought in three customer administrators, handed out empty screen frames, and asked each of them to draw how access gets granted at their own company. Thirty minutes later there were three sheets, and none of the three had an approval step. Someone joins, the administrator gets a notification, and it can be reversed if something looks wrong.

What Noa had been refining for two weeks was a three-stage approval flow. She'd heard "it has to be approved" in the interviews and translated that into a sign-off chain, but the approval they meant was closer to seeing a notification and stepping in if it looked off. The same word in speech turned out to be an entirely different screen on paper.

What people get wrong

The most common mistake is treating whatever users drew as something to build as-is. It's drawn by the people who use the product, so it looks like the most accurate answer available. But what a participant put on paper is the structure of their own work, not a solution. Build five companies' sheets literally and you get five screens, none of which the other four will use. Pulling out what repeats across those sheets and standing one screen on it is still the designer's job.

Confusing it with a session for gathering feedback is common too, since both involve bringing people into a room. The difference is what's on the table. In a feedback session participants respond to something already made; in co-design they put their own hands on paper that is still blank. Miss that and you end up putting a finished mockup on screen and calling the meeting a co-design, and what comes out of a room like that is commentary on the work. Examining finished work against its reasoning already has its own name: design critique.

Where to go next

  • Design process

    see which stage co-design belongs to and what sits beside it

  • Design critique

    the same collaboration branch, but opened around work already made. Reading both settles which session to call and when

Last updated 2026-09-16