In January 2026 I ran a two-day Design Thinking lab at Domstolsverket with a cross-functional group drawn from across the organisation. The brief was straightforward on paper: use Design Thinking to explore how the courts could better leverage digitalisation. In practice, it meant coaching a room full of people who were used to jumping straight to solutions — through a structured process that deliberately kept solutions off the table for most of day one.
The coaching challenge
The hardest part of facilitating Design Thinking in a traditional public sector organisation isn’t the methodology — it’s the culture.
People arrive with solutions already formed. They’ve been thinking about “the problem” for months, and the workshop feels like the moment to finally pitch the fix. When you ask them to spend the first half of day one writing down problems without proposing any solutions, the resistance is immediate and often disguised as helpfulness.
My approach was to make the constraint explicit and recurring:
“We’re not solving anything today. If a solution surfaces, write it on a separate piece of paper. We’ll come back to it.”
Repeated often enough, this phrase becomes a shared language. By mid-afternoon, group members were using it on each other.
The structure
The lab followed three phases across two days.
Phase 1 — Discover (day one)
Individual problem collection using a structured template: situation, friction, consequence, and current workaround. The workaround field was the most revealing — it forced participants to be honest about how they were actually coping, not how the process was supposed to work.
After individual collection, problems were shared one by one. The rule: only clarifying questions. No evaluation, no “but actually,” no “we already have a project for that.” This was the hardest rule to enforce, and the most valuable one.
Problems were then clustered on a shared wall, grouped by theme and frequency. The group named the clusters themselves.
Phase 2 — Synthesise (end of day one, morning of day two)
From fifteen-plus identified problems, the group converged on three areas. One was parked early — it was likely to be addressed through existing initiatives. A second was noted but deprioritised. A third became the focus: scheduling and staffing coordination within the courts.
A sharpening exercise crystallised this into a precise problem statement using the format: When [situation], [friction] occurs, which leads to [consequence], and today this is handled through [workaround]. Precision here mattered — the group building a solution in phase three needed to know exactly what they were building against.
Phase 3 — Build (day two)
Individual ideation (quantity over quality), group sharing and clustering, then prioritisation using the How / Now / Wow / Ciao framework. The group selected one concept and built a prototype: a unified staffing and scheduling support tool that would give coordinators a shared, real-time view of who is needed, where, and when.
The session closed with a short pitch in a design gallery format — problem, proposal, expected effect, proposed next steps — structured to create a decision-ready output rather than a sales pitch.
What worked
Starting with workarounds, not problems. Asking “what do you do when this breaks?” surfaced more honest and concrete material than “what problems do you have?” People know their workarounds intimately. They’ve been running them for years.
The coach phrases. Having a set of short, repeatable phrases — “we’re collecting problems, not solutions,” “build on that,” “what would make that even more extreme?” — reduced the cognitive load of facilitation and gave me tools to redirect without confrontation.
The How / Now / Wow / Ciao matrix. Giving the group an explicit framework for evaluating ideas prevented the usual collapse to “safest and most obvious.” The Wow quadrant gave permission to be ambitious.
Closing with a pitch structure. Framing the output as “something a steering group could make a decision about” raised the quality of synthesis significantly. Participants stopped describing the workshop and started making arguments.
What I’d adjust
The problem-sharpening step at the start of day two took longer than planned. The group had done significant work the day before, and reworking the problem formulation felt repetitive. Next time I’d do more sharpening at the close of day one while the material is fresh.
The gallery pitch format also compressed the prototype work. Sixty minutes to go from brainstorm to documented prototype is tight. I’d consider splitting the lab into three half-days to give the build phase more room.
Outcome
The workshop delivered a prototype concept with a clear problem statement, a defined primary user group, and proposed next steps for testing. The output was submitted to a strategic reference group for evaluation.
More durably: several participants noted that the two days had given them contact with parts of the organisation they’d never worked with directly. That cross-organisational connective tissue was part of the brief from the start — and the outcome I was least able to plan for and most pleased to see.