I have watched plenty of design thinking days go wrong before anyone picked up a marker. The sponsor books a room and prints a challenge statement that already holds the answer. Nobody speaks to a customer. By four o'clock the wall is covered in sticky notes, and on Monday the team goes back to building the feature it planned last quarter.
If you are about to buy one of these days, the agenda tells you most of what you need to know. Look for the hours your team will spend with real people. Look for the moment the room gets to change the problem. If neither shows up on the page, you are paying for a brainstorm with better catering.
Start with the problem you bring
The best sessions I run start with a live problem the business already cares about. A claims form customers abandon halfway through. An onboarding process new staff complain about in their first week. A made-up case lets everyone relax, and relaxed people learn very little they can use on Tuesday.
Write the problem as a situation with a person in it. "Customers drop out of the claims form" gives the room something to investigate. "Build a claims app" hands them the answer and asks them to decorate it. I push back on the second kind of brief before we lock a date, because the day exists to test whether you are solving the right problem. My longer argument on that sits in solve the right problem before the build starts.
Bring the data you already have, too. Complaint logs, drop-off numbers, call centre notes and the last round of survey comments all help the team pick who to interview. Use them to decide where to point the interviews.
Time with real people
The Design Council describes the first half of its Double Diamond as the stage where people understand the problem instead of assuming it, by speaking to and spending time with the people affected. I use that as the test for any agenda. If the customers or staff who live with the problem never appear, you have skipped the first diamond and kept the sticky notes.
In our design thinking workshop we get the team into the user's world with interviews and observation, then build an empathy map from what they heard. On a one-day format that means recruiting a handful of customers or frontline staff before the day and booking them into short slots. On a two-day format the team can go out into the field and come back with notes.
Either way, someone on your side has to own the recruiting a week or two out. When nobody owns it, the interviews quietly turn into a panel of colleagues pretending to be customers. Colleagues know where the problems hide. They also built the current process, and when they play the customer they defend the design they already have.
Defining the problem again
Buyers underrate the step between the interviews and the ideas. The team has to turn messy notes into one sharp problem statement, and it is often a different problem from the one on the brief. That moment needs a sponsor in the room who is ready to hear it. If the most senior person has already decided the answer, the define step becomes a formality and everyone can feel it.
Ask the facilitator how they handle a room that discovers the brief was wrong. A good answer covers who signs off the new statement and what happens to the original plan. A vague answer about staying flexible tells you they have never had to do it.
I like to write the new problem statement on one line and read it back to the sponsor before lunch. If they wince, we talk about it while the interview notes are still on the wall. That conversation is cheaper on day one than in month six, when the build has started and nobody wants to admit the brief was off.
Ideas, then a rough prototype
Ideation is the part people picture when they hear design thinking, and it is the part least likely to fail. Any team can generate ideas all day. The harder skill is converging on a few and killing the weak ones while killing them is still cheap. We use structured brainstorming that keeps the loudest voice from setting the agenda, then make the group commit to the ideas it will test.
Every team should leave with at least one low fidelity prototype that a real person has already seen. Paper screens, a mocked-up letter, a fake landing page or a role-played service conversation will all do. If you want options, 12 types of prototypes to test your idea covers the range. The Design Council frames delivery as testing solutions at small scale and dropping the ones that will not work. A day that ends on a ranked list of concepts stops right before that stage.
Format, size and who should attend
We run the workshop in formats from a half day to two days, in person or remote, for groups of eight to thirty. A half day suits a team that needs the language and one short practice round. A full day leaves room for live interviews and a first prototype, and a second day lets the team test that prototype with users and come back with evidence.
Mix the room. Product owners, operations leads, frontline staff and someone from risk or legal will hear different problems in the same interview, and the friction between them is useful. Keep the sponsor for the define step and the final readout at a minimum. A sponsor who drops in for the opening and leaves before the evidence arrives will overrule the team later from a slide.
Remote works when the team is spread across cities, provided the session is built for screens. A full day of webcam sticky notes wears people out by lunch. Shorter blocks and a shared board the team keeps using afterwards make the remote version hold up. The customer interviews run well over video.
Signs you are buying theatre
Some warning signs show up in the proposal. The agenda lists six methods and no customers. The pack promises a mindset shift and never names an output. The facilitator offers a generic case study from another industry for the team to practise on. Any one of these means the day will feel energetic and change very little.
Another sign shows up in the room. People present ideas to each other and vote with dots, and nobody leaves the building or picks up the phone. Voting has its place. When it replaces contact with users, the team ends up ranking its own guesses.
What to ask before you book
- Will the day run on a live problem we bring, and will you help us rewrite the brief if it hides the answer?
- Who recruits the customers or staff we interview, and how many will the team actually meet?
- What will the team hold at the end, and will a real person have seen it?
- How will the team run the method again next month without you in the room?
The last question matters more than buyers expect. A workshop that only works with an outside facilitator leaves you waiting for the next booking. The team should leave with a method it can run on the next problem by itself.
After the workshop
Give the prototype an owner before anyone leaves the room. Put the next round of user tests in the calendar while everyone is still there. If the idea survives those tests and turns into a business bet, a lean startup and product sprint is the next step, because it tests whether anyone will pay for it.
If you want to book the day, send me the problem the way your customers would describe it, plus the names of a few people who live with it. We will shape the workshop around that problem and plan the interviews with you.
