Design Thinking
For me, design thinking is not a workshop format. It is the order in which I work: understand first, then design, then make it tangible. The method suits projects where the outcome is not yet settled.
How a project runs
Research comes first. I gather data about the people a service is meant for, or work with what already exists. From that comes a first concept, and from the concept, as early as possible, a prototype that can be operated. I take it to those users, collect feedback and rebuild. That takes several rounds, not one.
The prototype is then rebuilt from the ground up and tested with more people. In parallel I check feasibility and viability: what can be built, and what can later be run, both count. Only then does a project move into implementation.
What comes out of it
Most recently in a municipal project, what we ended up with was considerably simpler than what we had started with. That is the most common result. Talking to users early means cutting features rather than building them. The gain lies less in the additional idea than in what turns out to be dispensable.
When I advise against it
When the outcome is already decided. The open process then becomes a detour, and everyone involved notices.
When the organisation does not support open processes. It is not enough for the project lead to agree. Where user feedback cannot be raised, or is not taken seriously, the procedure has no effect.
When deadline and scope are fixed in advance. The method can be timed, it delivers on the date. But it requires that something may be discarded along the way.
All three come down to the same condition: a willingness to work with uncertainty and to learn. That is not a side condition. It is the condition under which the method achieves anything at all.