By Nick Babich
Key Takeaways
- What it is: a facilitated session, usually half a day to two days, where your decision makers, subject-matter experts and the design team agree on the problem, users, goals, scope and risks before any design starts.
- What it takes: in my estimate, a one-day workshop needs about 56 hours from a three-person design team (16 to prepare, 24 in the room, 16 to synthesize), plus roughly 50 hours from your side.
- What you should get: a written summary, a decisions log, a problem statement, success metrics with baselines, a journey map, a prioritized scope for release one, a risk list with owners, a research plan and an updated estimate.
- When it pays off: new products, legacy overhauls and flows your own teams disagree about. A small, well-defined change only needs a kickoff call and a brief.
- Who attends: five to eight people, including one named decision maker from your side.
- The red flag to watch: a workshop that ends with photos of sticky notes and no written decisions within a week.
A discovery workshop is a facilitated working session, usually half a day to two days long, that puts your decision makers, subject-matter experts and the design team in one room (or one video call) to agree on the problem, the users, the goals, the scope of the first release and the main risks before anyone designs a screen. When it works, you leave with written decisions, not a wall of ideas. Experienced design partners open most new engagements this way, especially the UX teams that run discovery for complex B2B products in our reviews.
The short list of what you should receive afterwards: a workshop summary, a decisions log, a problem statement, two or three success metrics with baselines, a map of the main user journey, a prioritized scope, a risk and assumption list with owners, a research plan and an updated estimate. In the time model I use for this guide, a one-day workshop takes about 56 hours of work from a three-person design team, and less than half of it happens in the room.
This guide is for founders, product managers and heads of product who have a workshop in a proposal and want to know what they are paying for. If you are still comparing UX design partners that run structured discovery before design, use it to ask each one how they run theirs. Below: when a workshop is worth it, who should attend, how to prepare, a timed agenda, a worked example, a checklist for accepting each output, and the time it takes.
When a Workshop Is Worth It (and When a Kickoff Call Is Enough)
Not every project needs a workshop. If the work is a landing page refresh, a small feature inside an existing design system or a fix to one known screen, a one-hour kickoff call plus a written brief covers it.
A workshop earns its cost when at least one of these is true:
- You are building a new product or a new major flow, and the scope is still open.
- You are replacing a legacy system with workflows that only a few people fully understand.
- Product, sales and support describe the user's main problem in different ways.
- Several teams or departments have to sign off on the result.
- The design budget is large enough that building the wrong thing would cost more than the workshop.
A workshop is one step inside a discovery phase, not the whole phase. The phase often runs two to four weeks and adds user interviews, analytics review and technical checks. The workshop is the one moment when the people who decide, the people who know the users and the people who will design and build sit together.
Who Should Be in the Room
Keep it to five to eight people. More than that and the session turns into a presentation.
From your side:
- One named decision maker (often the founder or head of product) who breaks ties.
- Someone who talks to users every week, such as a customer success or support lead.
- A technical lead who can say what is feasible and what is expensive.
- Optional: a sales or operations lead if the flow touches revenue or internal processes.
From the design team:
- A facilitator or product strategist who runs the agenda.
- The lead UX designer who will carry the work forward.
- A UX researcher who will turn open assumptions into a research plan.
If your decision maker can only join for an hour, schedule that hour for the scope block in the afternoon, not the introductions.
How to Prepare: What to Send Before the Session
The best workshops start a week earlier. The design team should ask for inputs and read them before the day, so the session is spent deciding rather than discovering basic facts. Send:
- A short brief with the business goal, budget range, deadline and constraints. If you do not have one yet, here is a written brief you can send before the session.
- Analytics for the flow in question: funnel drop-off, time to complete, error rates.
- A sample of recent support tickets and sales call notes about the problem.
- Any past research, survey results or usability findings, even if they are old.
- Technical constraints: integrations, security rules, platforms you must support.
- Access to the current product or prototype.
Ask the design team what they plan to do with each input. A good facilitator will turn them into pre-filled boards so the day starts with evidence on the wall.
What Happens in the Room: A One-Day Agenda
A well-run workshop follows a strict order, and every block leaves a written output behind. Each block uses the output of the one before it, so the order matters more than the exact times. This is the one-day agenda I would expect a design team to propose:
| Time | Block | Output it must leave behind |
|---|---|---|
| 9:00 to 9:20 | Introductions, rules and the decision maker named aloud | Who decides, who advises, how ties are broken |
| 9:20 to 10:30 | Problem and context | A two-sentence problem statement with the evidence behind it |
| 10:30 to 11:30 | Goals and success metrics | Two or three goals, each with a metric, a baseline and a target |
| 11:30 to 12:30 | User types and main journeys | The primary user types and one main journey each, with pain points marked |
| 12:30 to 1:15 | Lunch | None |
| 1:15 to 2:15 | Assumption mapping | Assumptions sorted by how risky and how unproven they are |
| 2:15 to 3:30 | Scope and priorities (MoSCoW) | A Must, Should, Could and Won't list for the first release |
| 3:30 to 4:30 | Risks, constraints and open questions | Each item with an owner and a date |
| 4:30 to 5:00 | Wrap-up | Next steps, who writes what, and by when |
The exercises behind these blocks are not exotic. The problem block often uses a "how might we" reframing or a short problem statement template. Goals use a metric, a baseline and a target. Journeys are drawn as a simple sequence of steps per user type. Assumption mapping sorts beliefs by risk and evidence. Scope uses MoSCoW (must, should, could, won't). The risk block can include a short pre-mortem: everyone writes down what could go wrong, the group votes on the biggest threats, and each one gets an action with an owner and a due date, as laid out in Atlassian's pre-mortem play.
How the format changes:
- Half day (about 4 hours): keep problem, goals, scope and risks; shrink journeys to one user type; skip assumption mapping and fold it into risks. Works for a single flow with a clear owner.
- Two days: day one covers problem, goals, users and journeys; day two covers assumptions, sketching key screens together, scope and a delivery plan. Fits new products and multi-team systems.
- Remote: split the one-day agenda into three sessions of about two and a half hours on consecutive days, on a shared whiteboard. Nobody keeps workshop-level focus on a video call for eight hours.
A Worked Example: B2B SaaS Onboarding Redesign
Here is how the agenda turns into decisions, using an example I put together for this guide. It is not a client story, and the numbers are illustrative. A B2B SaaS team wants to redesign onboarding because new accounts take too long to reach their first useful result. Six people attend: the head of product (decision maker), the customer success lead, the engineering lead, a facilitator, a lead designer and a researcher. They run the one-day agenda above. The decisions that come out of it:
- Problem statement: "New accounts take a median of 14 days to send their first report because setup requires manual API keys and a support call. About 40 percent of trial accounts never get there, and those accounts almost never convert."
- Goal with metric: reduce median time to first report from 14 days (baseline, from product analytics) to under 2 days within one quarter after launch.
- Scope line for release one: guided setup with one-click connections for the three most used integrations is a Must. Manual API key setup stays as it is and moves to release two. A setup checklist inside the app is a Should.
- Risk 1: security teams at larger customers may block one-click connections. Owner: engineering lead, confirm with three enterprise accounts within a week.
- Risk 2: the 14-day baseline mixes self-serve and sales-led accounts. Owner: researcher, split the data by account type before design starts.
- Open question: do admins or end users complete setup? Owner: customer success lead, answer from the last 50 onboarding calls.
Notice what is not on the list: no screens, no color choices, no feature wish list. The workshop decided what to build first and what to prove, which is exactly what the design phase needs.
What You Should Get: The Output Acceptance Checklist
The whiteboard is raw material, not the deliverable. Within a week of the session, the design team should send a written package. Use this checklist to accept or push back on each item:
| Deliverable | What a good version contains | Quick acceptance test | Typical deadline |
|---|---|---|---|
| Workshop summary | One to three pages: what was agreed, what was not, next steps | Could you forward it to your CEO without explaining it? | 2 to 3 working days |
| Decisions log | Each decision, the options considered and why one won | Does it say why a feature was cut, not only that it was? | 2 to 3 working days |
| Problem statement | Two sentences that link user friction to a business result, with evidence | Would each attendee describe the problem the same way after reading it? | Same day (agreed in the room) |
| Success metrics | Two or three metrics, each with a baseline, a target and a data source | Can you already measure the baseline today? | 2 to 3 working days |
| Journey or workflow map | The current main journey per user type with pain points marked | Do your support and sales leads recognize it as accurate? | 3 to 5 working days |
| Prioritized scope for release one | Must, Should, Could and Won't, with the scope line drawn | Do the Must items fit the budget and the deadline you have? | 3 to 5 working days |
| Risk and assumption list | Each risk or assumption with an owner, a date and a way to test it | Does every high-risk item have a named owner? | 2 to 3 working days |
| Research plan | Which assumptions get tested, with whom, how and when | Does it test the riskiest assumptions first? | 3 to 5 working days |
| Updated estimate or proposal | Timeline and cost revised to the agreed scope | Does the math reflect the cuts made in the room? | 5 to 7 working days |
If two or more items fail their test, ask for a revision before design starts. Fixing a vague problem statement now costs an afternoon; fixing it after wireframes costs weeks.
How Much Time a Workshop Takes
Many buyers compare the workshop fee with eight hours of meetings and feel overcharged. Most of the work happens outside the room. Here is my estimate for a one-day workshop run by a three-person design team, built from the agenda above:
| Role | Preparation | Session | Synthesis | Total |
|---|---|---|---|---|
| Facilitator or product strategist | 6 hours | 8 hours | 6 hours | 20 hours |
| Lead UX designer | 6 hours | 8 hours | 6 hours | 20 hours |
| UX researcher | 4 hours | 8 hours | 4 hours | 16 hours |
| Design team total | 16 hours | 24 hours | 16 hours | 56 hours |
| Your team (5 people) | 5 to 10 hours gathering inputs | 40 hours | 3 to 5 hours reviewing outputs | 48 to 55 hours |
At a blended rate of $150 an hour, 56 design-team hours come to about $8,400. Your own rate and the team's will differ, so multiply the hours by the rates in your proposal. Teams usually price the workshop as a fixed fee or bundle it into a paid discovery phase; either way, ask which outputs the fee includes. For how this fits the rest of the project budget, see what UX work costs once discovery is done.
Do not forget your side: about 50 hours of your team's time in this example. That is the real reason to keep the room small and the agenda strict.
Red Flags to Watch For
- Sticky-note photos as the deliverable: if all you get is whiteboard screenshots, you paid for a meeting, not for analysis.
- No named decision maker: without a tie-breaker in the room, the day ends in circular debate.
- Solutions before the problem: if people sketch screens before the problem statement is agreed, the facilitator has lost the room.
- A generic agenda: if the agenda was not adjusted after reading your inputs, the inputs were probably not read.
- Silence afterwards: no summary and decisions log within a few working days means the momentum is gone.
- Scope grows in the room: a workshop should end with a shorter Must list than it started with, not a longer one.
What Happens After the Workshop
The outputs feed straight into the next stages. The problem statement and metrics shape the strategy work that discovery feeds into. The research plan turns the riskiest assumptions into interviews or tests. The prioritized scope becomes the list of flows for information architecture and wireframes. For the full sequence, see the UX stages that follow discovery.
Book a 30-minute review of the written package with your decision maker before design starts. Read the decisions log line by line and confirm nothing has changed since the session.
Frequently Asked Questions
How long does a discovery workshop take?
Most run one full day of about seven working hours. A single, well-understood flow can fit into half a day; a new product or a system shared by several teams usually needs two days. Preparation and synthesis add about a week around the session.
Who should attend a discovery workshop?
Five to eight people: one decision maker, someone close to users (support or customer success), a technical lead, and from the design team a facilitator, the lead designer and a researcher.
Can a discovery workshop be done remotely?
Yes. Split the agenda into shorter sessions of about two and a half hours over consecutive days, use a shared whiteboard, and send inputs earlier so people arrive prepared.
What is the difference between a discovery workshop and a discovery phase?
The workshop is one session focused on alignment and decisions. The discovery phase is a broader stage, often two to four weeks, that includes the workshop plus user interviews, analytics review and technical checks.
Is a discovery workshop worth paying for?
It is when the scope is open, several teams have a stake, or the build is expensive. Agreeing on the problem, metrics and scope before design costs far less than redesigning after development has started. For a small, well-defined change, a kickoff call and a brief are enough.
Conclusion
A discovery workshop is worth exactly what it leaves behind in writing. Before you sign, ask for the agenda, the list of outputs and the delivery dates, and make sure one person on your side can make the final call in the room. Afterwards, hold every deliverable to the acceptance checklist above. A good workshop gives you a shorter scope, clear metrics and named owners for every open risk, and that is what lets the design work start on the right problem.
