Government services don’t have to be finished to learn from users. Designing a service for people means testing what you create, over and over again. This blog post is about how you can let users’ knowledge be your primary guide when creating government services—and why that is essential for developing better policies and better implementation.
Want an update in your mailbox every month about my research? Then subscribe to my newsletter.
“We can’t make this public yet”
“But it hasn’t been brought before the House yet.”
“People might start thinking it’s already been decided.”
“What kind of expectations are you creating then?”
I heard this often when I worked at various implementing organizations. Testing with users before something has been formally agreed upon, politically legitimized, or administratively finalized creates tension. Because, in the government’s logic, “the outside” is what counts. And that “outside” is twofold: on the one hand, you want to communicate democratically legitimized decisions; on the other hand, as a service provider, you want to align with what people need in their specific situations. I previously referred to this as the government’s dual “outside.”
Because of that pressure, user testing is often postponed or even canceled. It has to be “official” first. But what if that very delay is what causes us to know less, learn less, and ultimately be less able to make adjustments?
An important principle of human-centered design
The ISO standard for human-centered design makes it clear: A design must be driven and refined through user evaluation. That means: you create something, you show it to the people you’re making it for and who will use it, you learn from it, and you adapt it. Not just once, but continuously.
This principle builds on earlier principles from this blog series:
- Evaluation-driven approaches are only possible if you take the users’ entire experience into account.
- This will only work if you involve users from the very beginning.
- And it only makes sense if you work in iterations, during which you can make adjustments.
So testing isn’t just the icing on the cake. It’s the dough you use to bake. “Being driven by” also means that, when making decisions, you constantly ask yourself how users will experience your design. That’s what makes all the difference!
Why does testing feel so uncomfortable in the government?
In the world of politics and administration, you want control and clarity: Has this been coordinated? Do we have the mandate for this? What message are we sending if we show this to the public? What if people don’t like it, and the media picks up on it?
In design thinking, you actually want openness: What works, and what doesn’t? Where do people get stuck? What are we still missing? What do we need next to make it happen?
These two approaches clash, especially when it comes to “putting something out there.” Yet user testing does something quite different from communication: it’s not a press release, not a policy document, not marketing. It’s learning.
And more importantly, thorough testing actually helps bridge the gap to the political and administrative world outside. Because evidence speaks for itself. You know what works. You see what isn’t working. And you can make better-informed decisions, whether they’re small and operational or large and policy-related.
How is that even possible? What I see at CRI
In my research for the “Clustering Rijksincasso” program, I see how it *can* be done.
Take, for example, the creation of the “Vorderingenoverzicht,” a digital service for citizens who make payments to the government. During each development sprint, the service is tested with users, and their feedback informs the next sprint. Not only does this improve the design, but the entire design process is driven by these feedback sessions.
All of their user research is available online and can be reviewed. In handy slides, they consistently showcase what they’ve learned, such as in this example:
Another example is the Central Government Payment Scheme. In the blog post about iterative development, I already explained how this scheme is being expanded step by step to include new organizations. This allows us to learn along the way—both from citizens who use the scheme and from government organizations that join it.
These insights go beyond just text or buttons. They also touch on decisions regarding minimum repayment amounts, how to handle remaining debt, how funds are allocated among organizations, and what is technically and legally possible when it comes to sharing data.
The team operates on multiple levels simultaneously: the service is continuously monitored, in-depth research is conducted periodically with users, and the policy guideline is reviewed annually. In this way, input from the field is utilized both operationally and strategically.
In addition, the team is working on a Government Collection Act, ultimately in collaboration with ministries and government officials—that’s the other side of the story. Here, too, practical experience forms the foundation. In this way, implementation, policy, and legislation converge, based on what works for people.
In short, testing doesn’t eliminate uncertainty. But it makes it visible and manageable. And that’s exactly what you need if you want to create public value.
How do you get started with this principle?
If you want to do this, start small—but make sure you start. Apply the other principles of human-centered design: understand your users’ context, consider their entire experience, involve them throughout the process, and work iteratively.
The ISO also lists activities that can help you with this:
- Schedule evaluations at various points in your process, not just at the end—by then it will be too late.
- Choose appropriate evaluation methods (ranging from quick tests to observations and in-depth feedback sessions)
- Make sure that what you learn is actually reflected in the design. So, update the design regularly, and try out new ideas from time to time so you can test them.
And for leaders: dare to make room for this learning. Create space to change and adjust services, systems, processes, and policies. Yes, it feels vulnerable. Yes, it sometimes rubs against formal procedures. But only by testing can you know whether what you’re creating actually works for the people you’re creating it for.