Running a Design Workshop

In Sprint (2016), Jake Knapp, John Zeratsky and Braden Kowitz describe a week with Savioke, a startup building a robot that delivers items to hotel rooms. The open question was how the robot should behave around guests. By Friday the team had watched hotel guests meet the robot running prototype behaviors.

That week was a long design workshop: a small group working together on one question until it reached a decision it could not have reached over email. Most are shorter. The ones that fail tend to fail before anyone enters the room, because the question was vague or nobody decided in advance what the group should have in hand at the end.

What a design workshop is for

A workshop is worth the cost when three conditions hold. The problem needs several people's knowledge at once, say what engineering can ship this quarter and what support hears every day. The people who hold that knowledge disagree, or haven't compared notes. And the decision has to be made soon, because something is waiting on it.

If only one condition holds, use a cheaper format. A designer who needs engineering input can book thirty minutes with one engineer. A team that already agrees doesn't need a structured session to confirm it.

Workshops sit where a project widens or narrows: going from research to a problem statement, and from a problem statement to a short list of concepts worth prototyping. Those are the hand-offs between stages of the five-stage design thinking model. The design thinking hub covers the stages on either side.

Teams name workshops after what they produce: an alignment workshop ends with an agreed problem statement, a mapping workshop with a journey map everyone has corrected, an ideation workshop with sketched concepts. A design sprint strings several of these together over a week and ends with a tested prototype.

The brief

Write a one-page brief before sending a single invitation. It should answer five questions:

1. What decision will the group make? "Choose one onboarding concept to prototype next sprint" is a decision. "Explore onboarding" isn't one.
2. What will exist at the end? Name the artifact: three sketched concepts, a ranked list of ten problems, a corrected flow diagram.
3. Who decides if the group splits? A workshop isn't a vote unless you've said it is. In most teams a product lead or design lead holds the final call, and everyone should know who that is before they arrive.
4. What do participants need to know beforehand? For an onboarding workshop that might be the last two weeks of support tickets tagged onboarding. Keep the pre-reading short enough that people read it.
5. What is out of scope? If pricing is fixed, say so, or the second hour will be spent on pricing.

Show the brief to the decision-maker first. If they can't agree with question 1, the workshop isn't ready to schedule.

Who to invite

Sprint recommends seven people or fewer, and that is a sensible ceiling for any single group. Beyond that, people stop talking and start watching, and the facilitator needs to split the room into parallel groups.

Invite for knowledge, not seniority. The support lead who reads a hundred tickets a week often knows more about the onboarding problem than the VP who sponsors it. Include at least one person who will build what comes out of the session, because their questions about feasibility are cheaper to hear on the day than after a concept is approved.

Keep the facilitator separate from the decision-maker if you can. A facilitator who also owns the outcome will steer, even without meaning to, and participants notice. If the team is small and the designer has to do both, say so at the start and hand the facilitation to someone else for the convergence step.

Building the agenda

A workshop agenda alternates between two modes: diverging (producing many options) and converging (cutting them down). Most agendas fail by staying in one mode too long. A morning of open discussion produces lots of talk and nothing in writing. Diving straight into voting means choosing from whatever the first speaker suggested.

A half-day ideation workshop on an onboarding problem might look like this:

Time	Block	Mode	Output
0:00	Brief and constraints	Shared	Everyone working from the same facts
0:20	Problem framing: individual notes, then clustering	Diverge → converge	Three to five problem statements
1:00	Pick one problem to solve today	Converge	One "How might we" question
1:15	Break
1:30	Solo sketching	Diverge	Eight to twelve rough concepts
2:15	Gallery walk and silent dot voting	Converge	Heat map of interest
2:45	Decider picks, group critiques the pick	Converge	One or two concepts to prototype
3:15	Next steps: owners and dates	Shared	Written action list

Two habits make this work. Every block has a named output, so the facilitator can tell when it is done. And the agenda leaves time for a break and a buffer, because every block runs long.

Share the agenda with participants in advance. It sets expectations, and it gives people who think better alone a chance to arrive with something already written down.

Activities for each part of the day

The activity should follow from the output each block needs.

For framing the problem: affinity mapping. Each person writes observations from research on separate notes, one per note, then the group clusters them on a wall and names each cluster. It also puts research the team has only skimmed in front of everyone. Gamestorming (Gray, Brown and Macanufo, 2010) collects this and dozens of other exercises.

For generating options: solo sketching before any group discussion. Crazy 8s (eight sketches in eight minutes) and brainwriting both keep the first confident speaker from setting the direction for everyone else. The ideation techniques guide compares these formats in detail.

For mapping a process: a journey map built on the wall in real time. Pre-draw the stages from research, then ask the group to add what the customer is doing, thinking, and feeling at each step. People correct each other's assumptions faster on a shared map than in conversation. Customer journey mapping covers the format.

For choosing: silent voting, then a decider. In Sprint, sketches go up on the wall, participants mark what interests them with small dot stickers to build a heat map, and after a short critique the Decider casts a "supervote" that settles it. The dots show where interest sits; the Decider can still pick a concept with few dots if it fits the brief better. When the options are tasks rather than concepts, an impact/effort matrix does the same job: plot each one on two axes and discuss only the ones whose placement people dispute.

Running the room

The facilitator's job is to protect the agenda and to keep the quiet people in the conversation.

• Timebox visibly. Put a timer where everyone can see it. When it ends, move on, and record the unfinished item in a "parking lot" list rather than extending the block.
• Write before talking. Give people two or three minutes to write their own answer before anyone speaks.
• One conversation at a time. Side conversations mean the group has split without saying so. Bring it back, or split it on purpose into breakout groups with their own outputs.
• Capture in the room. Photograph the wall at the end of every block, not only at the end of the day. Sticky notes fall off.
• Separate critique from authorship. Present sketches without names during the gallery walk. People vote more honestly when they can't tell which concept belongs to the head of product.

When a participant keeps reopening a settled point, refer back to the brief. "Pricing is out of scope today; I'll add it to the parking lot" is easier to say when the brief says so in writing.

Remote workshops

A remote workshop needs the same structure with shorter blocks. Split a six-hour session into two three-hour calls on consecutive days.

Set up the digital whiteboard in advance, with a frame for every agenda block and the templates already placed. Run a five-minute warm-up that asks everyone to add a note and move it, so nobody spends the first real block learning the tool.

Some things get harder at a distance. Side conversations move into chat, where the facilitator can't see them. Reading the room gets harder, so ask for explicit signals: cameras on during discussion, a thumbs-up reaction when someone is done writing. Silent work translates well; open debate translates badly, so lean the agenda toward writing and voting and keep live discussion to small, short blocks.

What leaves the room

Within a day, send a short written summary to participants and to anyone who needs to act on the result:

• The decision made, and who made it.
• The artifacts: photos or a link to the whiteboard, plus a cleaned-up version of the key output.
• The parking lot, with an owner for each item or a note that it was dropped.
• Next steps, each with one owner and a date.

Three weeks later, the summary is the only evidence of what was agreed, and people will remember the day differently. If the workshop chose a concept, the next step is a prototype tested with users, and the wireframing guide covers how rough that first version can be.

FAQ

What is a workshop in UX design?

A UX workshop is a structured, facilitated session where a cross-functional group works together on a design problem, by mapping, sketching, or prioritizing, and ends with a specific decision or artifact rather than a discussion.

How long should a design workshop be?

Long enough to produce the output in the brief. A focused prioritization session can take 90 minutes; an ideation workshop usually needs a half day; a design sprint runs four to five days. If an agenda needs more than four hours in one sitting, split it across days.

How many people should attend a workshop?

Seven or fewer works for a single group. Larger workshops need breakout groups of that size, each with its own output, and more facilitation.

What is the difference between a workshop and a meeting?

A meeting mostly shares information and discusses it. A workshop produces something: participants spend most of the time writing, sketching, sorting, or voting, and the session ends with a tangible output and a decision.

What is the difference between a workshop and a design sprint?

A design sprint is a specific multi-day workshop format. Jake Knapp developed it at Google and refined it at Google Ventures; Sprint (2016) describes it. It moves from mapping a problem through sketching and deciding to building and testing a prototype with five users by the end of the week. A workshop can be any length and cover any single step.

Do you need a facilitator to run a design workshop?

For anything over an hour, yes. Without one, the agenda drifts and the most senior voice decides. The facilitator can be anyone on the team, as long as they aren't also the person making the final call.

Sources: Knapp, J., Zeratsky, J. & Kowitz, B. (2016), Sprint · Gray, D., Brown, S. & Macanufo, J. (2010), Gamestorming.