Stakeholder Workshops

“We need a workshop” is not yet a useful brief.

We need to understand what is unresolved. Perhaps departments are working from different assumptions. Perhaps a proposed experience depends on decisions nobody has connected. Perhaps the team knows a process is difficult but has never had an opportunity to examine the whole thing together.

A workshop can help when the task benefits from people responding to one another's knowledge and developing something jointly. If the need is an update, an individual interview, or a decision one person can make with the information already available, another format may be more appropriate.

The question is not how to fill the session. It is what the session should help us learn, make visible, or move forward.

That purpose determines the preparation, participation, methods, and output. It also gives us a way to recognize when the work is useful—or when a different kind of investigation is needed.

Stakeholders are not only the people approving a budget.

Depending on the challenge, we may need leadership, customer-facing staff, operations, marketing, content owners, designers, developers, service partners, or others whose work shapes the experience. Someone responsible for a small handoff can hold information that changes a much larger design decision.

We choose participants for what the work needs, not to make the invitation list look comprehensive. Some people may contribute beforehand through Stakeholder Interviews, documents, examples, or written responses. Others may only need to join the part where their knowledge or authority matters.

People should know why they are being asked to participate and what influence the session can have. Are they contributing experience, developing alternatives, assessing feasibility, or making a decision? Those roles can overlap, but they should not be left to guesswork.

We also want to know whose perspective is missing. A room full of employees can help us understand how a business serves its customers. It cannot, by itself, stand in for those customers' experiences.

Preparation gives a workshop substance.

We may bring existing research, examples of customer questions, a current journey, a service process, content, interface screens, a proposed direction, or a clearly described business challenge. The material should be understandable to the people using it and appropriate to share with them.

We separate what is known from what is assumed. We identify constraints without treating every inherited habit as a constraint. We clarify which decisions can be made in the session and which require further evidence or approval.

The preparation should also make participation practical. That can mean sharing context in advance, explaining unfamiliar terms, choosing accessible tools, allowing time to think, or arranging another way for someone to contribute.

We are asking people to bring their experience into the work. They should not have to spend the first half of the session figuring out what the assignment is.

A workshop does not need to march through every stage of Design Thinking in miniature.

Some sessions need careful listening and a shared map. Others need individual ideation, a comparison of alternatives, or a way to turn a broad concern into questions we can investigate. Methods can be combined, adapted, or left out according to the objective, people, time, and budget.

For example:

• Customer Journey Mapping can help a group examine what someone encounters over time—and mark where its understanding is incomplete.
• Service Blueprinting can connect visible interactions with the people, processes, and systems supporting them.
• How Might We can reframe an understood challenge into an opportunity for exploration without deciding the solution in advance.
• A concept review can compare possible responses against human needs, intended character, operational realities, and technical constraints.

Design Facilitation is the capability that helps guide this work. The workshop is one setting in which it happens.

The method should earn its place. An activity that produces a lot of material but does not help the underlying question may be keeping people busy rather than helping them design.

When a professional-services business is considering a client portal, we can use a workshop to examine the handoff from signed agreement to a useful first meeting.

We ask the team to bring the information requests, welcome material and working arrangements that shape the beginning of the relationship. Which parts help clients prepare, and where do people have to ask for clarification?

Sales, onboarding and delivery colleagues can each contribute examples of the material they use and their account of what happens. Their knowledge helps frame the investigation; it does not replace hearing from clients.

The shared task is to map the transition from agreement to a prepared first meeting.

Sales may explain what clients have been told to expect. Operations may identify information it requests before creating the account. The delivery team may explain which details it genuinely needs for the first conversation and which can come later.

Working through that sequence could reveal a distinction the original request did not capture: some information is required to begin; some is useful later; and some is being requested twice because two teams cannot see one another's records.

That changes the design question. Instead of starting with a list of portal features, we can ask how to help a client understand the next step, provide the right information at the right moment, and arrive feeling prepared rather than processed.

Possible responses could include better onboarding content, a change in the service process, a modest integration, a portal, or a combination of them. The workshop does not prove which response will work best. It helps us define the choices, expose dependencies, and identify what to investigate next.

The value is a shared starting point: a clearer question, visible dependencies and a practical next step that the people responsible understand.

People may leave a workshop understanding one another better without agreeing on everything.

We should not hide that behind a tidy summary. A concern about feasibility, a disagreement about the intended customer, or uncertainty about a business promise can be important information.

Where possible, we make the underlying issue specific. Are we disagreeing about an observation, interpreting it differently, or choosing between competing priorities? Would a rough prototype help? Do we need a decision from someone who is not present? Is there something customers could help us understand?

The purpose is not to prove whose idea wins. It is to make a responsible next move.

Some decisions belong to the client. Some require specialist judgment. Some need more evidence. A workshop should help those responsibilities become clearer, not disguise them as a group vote.

A photograph of a busy workshop may show that people participated. It does not explain what changed.

Depending on the purpose, the useful output might be a shared problem statement, a journey or service map, a set of requirements, alternative concepts, a proposed direction, or a record of decisions and remaining questions.

We want the record to distinguish:

• Contributions and observations from interpretations and assumptions.
• Ideas considered from decisions actually made.
• Agreed constraints from conditions still open to change.
• Next actions from questions requiring further investigation.
• Responsibility for follow-through from people simply consulted.

Workshop findings can contribute to the wider discovery findings deliverable, incorporating useful knowledge from the client as well as Abstraction's investigation. They can also become part of the Product Intelligence we build together over time.

The record matters for people who could not attend. Participation matters in a different way: those present can experience the reasoning, hear the competing considerations, and help shape the response. Both are valuable; a document does not fully reproduce the learning of doing the work together.

Choose one moment in your customer's experience that depends on more than one part of the business.

Ask the people involved three things: What has the customer been led to expect? What do you need in order to deliver your part? What do you believe happens next?

Place the answers beside one another. Mark what is supported by an example and what still needs checking.

The first useful result may not be a solution. It may be noticing that people have been working toward different versions of the same experience.

Workshops sit within our broader Design Thinking practice:

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover.

They are particularly useful when we need to investigate, frame, or explore before committing to a response. They can return when a project changes, an implementation exposes a dependency, or new learning gives the team something important to work through.

We do not need every stakeholder in every session, and we do not require a workshop at every stage. We need the right contribution at a useful moment.

Abstraction can organize a workshop around a defined challenge or include it within a wider design engagement. The starting point is what your team needs to understand or accomplish—not a predetermined collection of exercises.

Bring us what feels disconnected. We can work through it together.

Contact Us