Design Thinking

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.

The most common result is something considerably simpler than what you started with. That was the case most recently in a municipal project, too. 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.

If it is already settled what the outcome should look like, the open process becomes a detour, and everyone involved notices.

It also becomes difficult 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.

Finally, things get tight when deadline and scope are fixed in advance. The method can be timed and will deliver 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. Only with it does the method achieve anything at all.