Design Thinking Workshop for Coaches: A Complete Guide

A design thinking workshop for coaches should produce learning that changes a decision. Participants investigate a human problem, examine different responses and make something specific enough for people to try. Completing a sequence of activities, collecting enthusiastic reactions or filling a board with ideas does not establish that the proposed service will work.

Coachful is our #1 recommendation for managing the coaching preparation and follow-through around that work. Individually assigned worksheets can distinguish observations from assumptions; group sessions can organize the meeting; client conversations can carry actual questions and returned feedback. A workshop prototype is still a prototype. Coachful does not automatically turn a paper service idea into a new interface, operational approval or tested customer outcome.

This guide explains the underlying modes, an original three-hour workshop and a complete fictional service-design case. The team changes its interpretation after a failed test, revises its instructions, runs a second test and follows one real use within the fictional case. Every name, date, figure and event in that case is invented.

Use the five modes as tools for inquiry

The Stanford d.school Design Thinking Bootleg identifies five modes: Empathize, Define, Ideate, Prototype and Test. Its overview invites starting where useful rather than following one compulsory sequence. The attribution matters, but the deck's individual activities are not reproduced here. The workshop and examples below are original.

A 2025 d.school discussion of design education also cautions against treating an introductory process as the whole discipline. It emphasizes abilities developed through practice. A short workshop can expose an assumption or develop a question; it cannot supply every research, design or implementation skill a project needs.

Empathize: learn without pretending to read minds

Begin with a recent situation. What was the person trying to achieve, what did they do and what happened next? Someone saying they felt unsure after submitting work is evidence of their account. It does not establish the reason, how often it occurs or what every client needs. A facilitator should make those distinctions visible.

For example, a coaching team may think clients fail to submit drafts because the upload route is difficult. A client might explain that they found the route but could not tell whether submission purchased a review, requested one or completed one. Those are different problems. Listening that merely confirms the team's proposed upload redesign has missed the opportunity to learn.

Research participation needs its own explanation and agreement. The GOV.UK informed-consent guidance covers purpose, data, observers, recording, use, retention and voluntary participation. Apply an appropriate reviewed process for the actual setting; a coaching agreement alone does not explain a new research activity. Avoid unnecessary personal material and clarify that declining research will not reduce the person's existing service.

Empathy does not require adopting every requested solution. A client can reasonably want same-day feedback while the practice cannot responsibly provide it. Learn what the timing matters for, then examine the service choices honestly. Agreeing to an unavailable promise may feel responsive in the interview and produce a worse experience later.

Equally, a coach should not turn research into a coaching intervention without agreement. If the question concerns finding feedback instructions, redirecting the participant toward their confidence or motivation can replace a design problem with an unrequested personal explanation. Record what they tried and ask about their interpretation before deciding where the difficulty belongs.

Define: make the problem specific and revisable

Framing converts scattered accounts into a question the team can investigate. It also excludes some work for now. “Clients need a better experience” is too broad to guide a useful test. “We need a new dashboard” already chooses a response. A narrower framing could ask how a client can understand what happens after requesting feedback on a draft.

Keep three categories separate: what a person said or did, what the team thinks that may mean and what remains unknown. If two participants describe different experiences, do not erase one to create a tidy theme. The difference may concern service terms, familiarity, device or a genuine exception.

State the decision boundary too. A coach may facilitate a discussion but lack authority to promise additional staff time. A prototype that implies unlimited review would be misleading even if people like it. Decide who can approve a service change, what constraints are fixed and which assumptions can be tested without changing a live service.

Ideate: create meaningful alternatives before selecting

Give each participant a way to contribute independently before group evaluation. Writing, sketching or spoken description can all work. Explain the question and constraints, and allow an accessible alternative rather than treating rapid drawing as proof of creativity.

For a feedback service, alternatives might include clearer instructions within the current relationship, a scheduled review appointment, a reduced promise with explicit acceptance, or an additional paid service. Those alternatives change timing, responsibility or scope. Four color schemes for the same submission page do not examine those underlying choices.

Compare ideas against the actual need and constraints. A majority preference is useful information about the workshop group, not proof of client usefulness. Ask what an option assumes, who must do extra work and what evidence would make the team reject it. Keep a viable alternative visible in case the first prototype fails.

Prototype: expose an uncertainty at proportionate cost

A prototype makes an idea concrete enough to examine. It could be a written instruction, a paper service sequence, a mock conversation or a more realistic interactive representation. The GOV.UK prototyping guidance describes using different levels of representation before committing to implementation. Choose the form around the question, rather than polishing whatever the group can build most quickly.

If you want to know whether a client understands who replies and what counts as acceptance, a one-page instruction and simulated response may be enough. If you want to know whether they can navigate a mobile interface using assistive technology, that paper cannot establish it. If you want to know whether the coach can deliver two-day reviews, a screen cannot establish staffing capacity.

Label invented content and keep a prototype away from accidental live use. Do not let a participant think a pretend request has entered their actual coaching service. State what is simulated, what is observed and what separate checks remain before using the idea with real work.

Test: observe an attempt without rescuing the design

The GOV.UK moderated-testing guidance recommends relevant participants and clear, believable tasks that do not give away the route. It distinguishes observing the service from judging the participant. Let the person attempt the task before explaining how the design was meant to work.

Define observations before the session. Record any assistance and its timing. A person who succeeds only after the facilitator points to the answer has shown something different from independent use. Ask about their interpretation after observing the attempt; agreement with your explanation is weaker evidence than understanding the original material.

Then make an actual decision: revise, reject, keep under limited conditions or investigate something else. Small purposive tests can reveal important problems without estimating their prevalence. A returning participant may have learned from an earlier attempt, so separate their result from a fresh participant's. A test can also change the problem framing, sending the team back to inquiry.

Complete the fictional workshop brief

Practice owner Omar asks facilitator Maya, coach Sol and operations lead Neri to examine the draft-feedback service. Three existing clients have agreed to twenty-minute research conversations beforehand. Their service continues unchanged if they decline or stop. The team explains who will hear the accounts, keeps notes rather than recordings and agrees a limited research record with its normal privacy process.

The three accounts differ. One client knew where to send work but waited because they did not know whether feedback was included. Another sent a draft and thought its arrival meant the coach had approved its contents. The third understood the arrangement after an earlier conversation and reported no difficulty. Maya preserves all three accounts. “Every client is confused” would misstate the evidence.

Omar authorizes a learning workshop on 7 February 2028, 09:00–12:00 UTC. It may propose revised instructions for the existing service, not add unlimited review or change native software. He allocates twenty-one staff hours across research, workshop, tests, configuration and a bounded pilot use. Participant payments have a separate £150 ceiling.

The initial learning question becomes: “Can a client distinguish requesting feedback, receiving a service answer and receiving the actual feedback?” Actual feedback scope still requires the coach's agreement. The team will examine understanding first, then check the workflow and real service response separately.

Maya checks the framing against the actual evidence before the group generates ideas:

The team does not settle which account is most typical. It chooses a small question that can expose a consequential misunderstanding while keeping the other questions open. Neri retains uncertainty about how clients first learn their entitlement; a status-message test cannot answer that separate onboarding question.

Run the original three-hour agenda

All four staff attend all three hours, so the workshop costs twelve staff hours, even though only three hours pass on the clock. All test participants separately agree the research information and observer arrangement before each appearance. Two research participants join only for their booked first-round test appointments. Their time is counted separately. Maya shares the agenda and task materials in a usable text format and checks access arrangements before the workshop.

Choose between actual alternatives

Sol proposes making every draft submission automatically include a complete review. Neri identifies the missing capacity: nobody has approved that additional work. Omar rules it out within the current service. The team keeps a separately scoped review appointment as a possible future offer, rather than pretending the workshop can add it at no cost.

Maya proposes a clearer request-and-answer sequence using the existing client conversation. It preserves the current service boundary, requires no new software and can be represented cheaply. Neri proposes simply adding a longer FAQ to the existing welcome document. That is viable, but it leaves the point-of-request interpretation uncertain. The team chooses the sequence for the first test and retains the FAQ as supporting information.

The test criteria are explicit. Using a synthetic draft, the participant must identify where the request goes, when to expect a service answer and whether the draft has already been reviewed or approved. If a participant thinks receipt establishes approval, the team will revise before any live use. This gate matters more than whether they describe the page as attractive.

Show the failed first test and the actual revision

The first paper prototype is labeled as a simulation, not a Coachful screen. It says “Send for approval,” gives the client's private conversation as the route and promises a team reply by 17:00 UTC on the second working day. Its simulated message after submission says, “Your draft is ready.” No request is actually sent during this test.

Dev reads it as ready for the coach to consider and correctly distinguishes a reply from completed review. Eva finds the route and reply time but thinks the final message means her draft is approved. Maya does not correct her during the initial attempt. After recording that interpretation, she explains the simulation and asks what created it. Eva points to both “approval” and “ready.”

The result is one independent successful interpretation and one failure in two attempts. Eva's positive comment about the page's brevity does not erase the failure. The team revises the problem from making the request short to making the state and promise unambiguous.

Revised instruction: To request feedback, send your draft and the specific question in your private client conversation. State the date you need an answer. The team replies by 17:00 UTC on the second working day, Monday to Friday. The reply confirms what feedback can be provided and when, or explains that the requested scope or date is unavailable. Sending a draft is not approval or completed feedback. Any agreed feedback returns in the same conversation.

The revised simulated status reads: “Request sent. No review has been completed. Wait for the team's scope and timing answer.” Omar approves further testing, not live release. On 9 February, Eva and a fresh participant, Finn, each attempt the revised task in a separate fifteen-minute session. Both identify the route, answer deadline and unreviewed status without assistance. Eva's repeat result is recorded separately because she has already seen the issue explained.

The team does not combine the two rounds into four independent successes. There are four attempts by three test participants: one initial success, one initial failure and two revised successes, one of which is a repeat participant. This supports trying the revised instruction under limited conditions; it does not estimate success for all clients or prove the actual response service works.

Make the limited implementation and use reviewable

On 10 February, Omar and Sol review the second-round notes and accept a small pilot. Neri places the approved instruction in an existing client resource and checks that the intended clients can open it. The team rehearses sending and replying through the supported conversation. It does not add a new approval button, automated status engine or software integration.

In Coachful, the actual conversation has its authorized staff audience. The word private distinguishes it from group discussion; it does not promise access by one coach alone. If the team uses Coach review to examine a submitted worksheet internally, that review is not client-facing feedback. The promised answer and actual comments still need to be sent through the conversation.

On Monday 14 February at 10:00 UTC, pilot client Carmen sends two pages and asks for feedback before Thursday at 17:00. Sol replies Tuesday at 16:00: “I can review one page and return two observations by Wednesday at 17:00 UTC. I cannot provide a two-page review by your requested date. Would the one-page scope work, or would you prefer to keep your current draft without this review?”

Carmen accepts at 16:15 and identifies the page. Sol returns the actual comments on Wednesday 16 February at 16:30: “The opening asks for approval but does not state the decision needed. Name the specific choice. The final paragraph proposes Friday delivery without an answer deadline. State when you need confirmation before treating Friday as agreed.” Carmen acknowledges at 17:00 and says she will add the decision question.

The service answer arrived before its Wednesday 17:00 deadline, the narrower review was actually accepted and the promised feedback arrived on time. Those are separate checked events. Carmen's planned edit is not claimed complete, and the draft's recipient has not accepted Friday delivery. The pilot demonstrates this one sequence, not a business-outcome improvement.

Reconcile the resources and make the final decision

By the 17 February review, staff work totals sixty minutes recruiting and agreeing participation, 120 on three interviews with two staff, sixty preparation, 720 in the workshop, forty-five refining material afterward, sixty in second-round tests with two staff, thirty in the two-person approval decision, forty-five configuring and checking access, and forty in the two-person final review. That is 1,180 staff minutes.

Sol's actual pilot response and feedback add twenty-five minutes. Including that service work gives 1,205 minutes, or twenty hours five minutes, against the twenty-one-hour allocation. Fifty-five minutes remain. The twenty-minute revision inside the workshop is already within its 720 person-minutes; the separate forty-five minutes is later refinement and preparation. Neither is counted twice.

Participants complete seven appearances: three research interviews, two first-round tests and two second-round tests. Each appearance is paid £20, including Eva's return, for £140 within the £150 limit. Participant time is sixty interview minutes plus sixty test minutes, two hours total, separate from staff effort. Payments are for participation, not favorable comments or service purchases.

Omar retains the revised instruction for a further limited period and rejects the original approval wording. Neri owns the instruction, Sol owns actual service replies and Maya records the evidence limits. They schedule another review after more ordinary use. They do not claim that the unresolved larger-scope review demand has disappeared. A useful instruction can make an unavailable service clearer without making it available.

Recognize when the next problem is a service decision

Consider a contrasting result: a participant understands the revised instruction perfectly but needs a full review today, while the practice has no review capacity until next week. More attractive wording would not resolve that conflict. The options might be a different deadline, a different scope, another appropriately qualified provider or no additional service. The client and authorized provider must make the actual choice.

This is why a test plan needs a next decision as well as a success criterion. If the misunderstanding disappears but the deadline conflict remains, the team should change its inquiry. It might investigate demand and delivery economics for a separately scoped service. That would require new evidence and approval, rather than being silently added to the current instruction.

In the fictional case, Omar explicitly keeps that larger service question open. The revised material will remain in the limited pilot through 24 February, with an evidence review scheduled for 25 February. Sol will record any requests whose scope or deadline cannot be accepted. That future record has not yet been collected. Retaining the instruction is a bounded decision under uncertainty, not a declaration that the whole feedback experience has been solved.

Prepare the next workshop in Coachful

1. Share the bounded brief. State the learning question, decision owner, constraints and what will remain simulated.
2. Assign an original preparation worksheet. Separate observations, assumptions, unknowns and the next decision. Keep consent records and identifying research material in the approved research process rather than a general shared worksheet.
3. Schedule the real meeting. Check time zone, intended participants and joining route. A resource assignment does not establish attendance or access.
4. Record decisions and controllable tasks. Assign actual owners for revision, testing and approval. Mark unknown capacity and absent authorization as open, not completed.
5. Review follow-through with evidence. Distinguish simulated understanding, live access, actual service answers and later outcomes. Keep the failed version and the reason it changed.

The workshop facilitation guide covers the broader event arrangement. The operational bottleneck audit helps when the remaining constraint concerns authority or capacity. Explore Coachful's features for supporting preparation and agreed follow-through.

Troubleshoot the learning process

The sponsor already wants a specific feature. Ask what uncertainty the feature addresses and what result would change the decision. If nothing could change it, describe the meeting as implementation planning rather than pretending it is open inquiry.

The team coaches every tester toward success. Preserve the assistance record and revise the test. Help can protect a participant's experience, but assisted completion cannot be relabeled independent use.

The prototype works but delivery does not. Return to the service constraint. Clear wording cannot supply unavailable staff time, technical capability or authorized approval. Change the promise or resource the service before expanding it.

Only enthusiastic clients participate. State the recruitment limitation and seek relevant other perspectives where appropriate. Do not present the resulting views as representative of the whole client base.

Frequently asked questions

Can a three-hour workshop complete design thinking?

It can examine a bounded question and choose a next learning step. This case also needs research beforehand, a second test and actual use afterward. The workshop's end is not the end of the work.

Must the five modes happen in order?

No. They help organize different kinds of work. Here a test changes the framing, and operational capacity remains a separate check throughout.

Does the coach need to be a designer?

The facilitator needs competence for the actual work. Listening and reflection help, but specialist research, accessibility, technical or legal needs may require appropriate colleagues. A coaching credential alone does not establish those skills.

Should we build a realistic app prototype immediately?

Choose fidelity around the question. Paper helped expose ambiguous status wording here, while the later conversation rehearsal and pilot checked the actual route and service. Paper alone could not establish those later outcomes.

What should we report as success?

Report what was actually observed: a failed interpretation, corrected wording, two qualified revised attempts and a completed bounded service exchange. Preserve the small sample, returning participant and unknown wider effects.