What to prepare for a London product design workshop
Give an agency workshop a decision to resolve, evidence to work from, the people who can decide, and clear acceptance criteria for its output.
Design Director
Published Updated 5 min read
A London product team should arrive at an agency workshop with one decision to resolve, the evidence behind it, and the people who can make or constrain that decision. It should also agree what the workshop must produce and how the team will judge whether that output is usable. Without those inputs, a busy session can end with sticky notes and no accountable next step.
A workshop can help a team frame a problem, compare directions, or turn research into a plan. It cannot make absent stakeholders available or settle a technical or product question that nobody has authority to answer.
What decision should the workshop make possible?
Write one sentence that names the decision and its owner. For example: “The product group will choose which account setup problem to test next, based on observed evidence and the engineering constraints.” This is an illustrative brief, not a delivered Humbleteam project.
Then list what is already known, what remains uncertain, and what the group is allowed to change. A screenshot collection without context makes it hard to distinguish an interface preference from a customer problem. Bring the journey, relevant research, support or analytics evidence, and known constraints in a form participants can review before the session.
If the central question is still unclear, schedule discovery or research before asking a workshop to generate solutions. The design sprint decision guide explains how to connect a working session to the evidence it can actually produce.
Who needs to be in the room?
Name a decision owner, a product representative, someone who can explain implementation constraints, and people who understand the customer evidence. Add the colleagues responsible for operational steps or dependencies the proposed change could affect. Invite people because they hold relevant knowledge or authority, not to fill seats.
For a London team working with an external agency, agree who must attend in person and who can contribute remotely. Decide in advance how remote participants will see the materials, speak, and register a concern. GOV.UK research guidance notes that screen sharing can let stakeholders observe sessions, while remote research needs deliberate access and preparation. Treat those points as useful logistics guidance when planning a hybrid workshop, then check the setup with the participants. See location guidance and remote session guidance.
Send the brief and pre-reading early enough for people to review them. Ask attendees to bring corrections to the evidence, unresolved questions, and any decision constraints. If an essential approver cannot attend, name the person who will review the recommendation and when.
What should the team decide before the session?
Use this worksheet to keep preparation concrete:
| Field | Write down |
|---|---|
| Decision | The choice this session should help someone make |
| Decision owner | The person who can accept, reject, or defer the choice |
| Evidence | What is observed, where it came from, and what is still a hypothesis |
| Participants | Roles needed for customer, product, technical, and operational context |
| Constraints | Dependencies, access limits, systems, and delivery conditions |
| Output | The artifact, its user, and what it must let them do next |
| Follow-through | Owners and dates for decisions or work that remain after the session |
Ask the agency to challenge assumptions in the evidence pack. That is more useful than asking every attendee to bring a preferred solution. If a claim has no source, label it as an open question so it does not acquire false certainty through repetition.
How should the brief describe the workshop output?
Specify the form and the acceptance test. If the output is a prioritized journey map, say which roles and states it must cover and how it will guide a decision. If it is a prototype, say which task and device it should represent, who will test it, and what question the test must answer.
“A strategy” or “a clear direction” is too vague to accept. A useful output might be a set of options with tradeoffs, evidence links, open dependencies, and a recommendation whose owner is named. Agree whether the agency should facilitate a decision or make a recommendation; those are different responsibilities.
Keep work outside scope visible. Legal review, engineering estimates, participant recruitment, service operations, and final prioritization may belong to other people. Record an owner for each dependency instead of assuming the workshop will resolve it.
What should happen after the workshop?
Reserve time for synthesis and a decision review. Capture what the group agreed, what it did not resolve, and which evidence would change the recommendation. Send the readout to the people responsible for implementation, even if they were not all present.
Close by checking that the accepted output supports a specific next action. That may be a research test, a product choice, a technical investigation, or a decision to stop. For a broader agency brief, see the London UX audit and agency shortlist and Humbleteam’s London product design page.
