# What to prepare for a London product design workshop

> Prepare a product design workshop with a decision brief, evidence, accountable stakeholders, constraints, and acceptance criteria for the work it produces.

- Canonical page: https://humbleteam.com/blog/london-product-design-workshop-brief
- Last updated: 2026-11-09

Skip to main content

[All articles](https://humbleteam.com/blog)

- Other

Updated November 9, 2026 5 min read

Give an agency workshop a decision to resolve, evidence to work from, the people who can decide, and clear acceptance criteria for its output.

[Sergey Krasotin](https://www.linkedin.com/in/krasotin/)
Design Director

Share [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fhumbleteam.com%2Fblog%2Flondon-product-design-workshop-brief) [X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fhumbleteam.com%2Fblog%2Flondon-product-design-workshop-brief&text=What%20to%20prepare%20for%20a%20London%20product%20design%20workshop) [Email](mailto:?subject=What%20to%20prepare%20for%20a%20London%20product%20design%20workshop&body=https%3A%2F%2Fhumbleteam.com%2Fblog%2Flondon-product-design-workshop-brief) Copy link

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](https://humbleteam.com/blog/startup-design-sprint-decision-evidence) 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](https://www.gov.uk/service-manual/user-research/choose-a-location-for-user-research) and [remote session guidance](https://www.gov.uk/service-manual/user-research/remote-user-research-phone-video-call).

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:

Workshop preparation worksheet

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](https://humbleteam.com/blog/london-ux-audit-activation-agency-shortlist) and Humbleteam’s [London product design page](https://humbleteam.com/london).

## Read next

- [Other October 26, 2026 How should a B2B SaaS product design data tables, filters and saved views?](https://humbleteam.com/blog/b2b-saas-data-table-filters-saved-views)
- [Other September 5, 2026 How to audit an AI copilot that users don’t adopt](https://humbleteam.com/blog/ai-copilot-ux-audit-low-adoption)
- [Other November 8, 2026 How should an enterprise software startup prepare a VPAT before a buyer asks for one?](https://humbleteam.com/blog/enterprise-software-startup-vpat-accessibility-report)
- [Other Fintech Healthtech May 7, 2026 Why startup branding is not a logo — it’s a product decision](https://humbleteam.com/blog/why-startup-branding-is-not-a-logo----its-a-product-decision)