Rapid Prototyping to Improve Government Systems

We live and work in messy, complex environments. Civil servants are faced with roles that must balance time, budget and regulatory constraints with shipping services for millions of constituents.

There are endless varieties of frameworks to use for delivering products and services. Some examples of processes range from design thinking, policy analysis, behavioral science and agile development. Each process can be defined in a multitude of ways. Depending on the organization or types of people who are on your team to champion these principles, you may lean toward one camp over another.

Even when you know what they are, these practices may seem mythical, inaccessible and fairly complicated to employ in your work environment. As a civil servant working on these sometimes called “wicked problems,” you may wonder how you and your team might build something in a feasible time frame without packing features into one massive, decade-long release. The scope for actual user-facing improvement may feel overwhelming.

There is no easy fix or magic wand to these complex public-sector issues. Often, people look for one golden recipe for success for product design and development. No doctrine or framework that is so rigid it should never be modified to fit the needs and work environment unique to you. Some teams may need to translate their services into 24 languages while others need to accommodate 24 million users on a site on one day without going down.

One strategy is to start with a simple, bite-sized piece to test a hypothesis to improve a defined user pain point. Begin by creating low-fidelity paper or wireframe prototypes. Work with users and agency stakeholders to create better versions that produce success metrics that are representative of process improvement: “Number of structure fires in X city” instead of “Number of buildings inspected for fire code violations.”

When these frameworks say, “just build, design and test” or “be iterative,” what does that actually mean and what does it look like in practice? Often, this portion is glazed over in these frameworks. Each approach is unique to each team’s nuance and context. So let's go through a high-level example.

Let’s say you have an online process to sign up for housing benefits. You've found that the majority of users quit before they complete the process. Based on your research and your internal knowledge, this is a massive user pain point and brings in thousands of call center inquiries each day. What is the reason for this precipitous decline?

Instead of tossing out the code and starting from scratch, you start doing an often overlooked task to better understand the problem: You find and observe few of the applicants painstakingly navigate the current process online but realize a core theme. Six out of 7 of applicants couldn’t reach the final step to submit. You find there are several issues with the user interface, including confusing instructions and a hidden scrollbar that makes it difficult for users to see the call to action. As a result, applicants were unable to move forward and submit their form.

With just a few weeks of time available to improve these results, you then meet with more users. You create several low fidelity versions of designs that will improve this web-based service before you write a line of code. These low fidelity designs are created through resources that can be readily accessible to you: paper sketches and PowerPoint wireframes. Based on success metrics you may have selected (task completion, user comprehension and user satisfaction), you usability test the prototype, measure its performance until it meets requirements and finally move toward implementation.

As demonstrated in the example above, the national call for better technology to deliver government services is not about modern tech stacks and fancy user interfaces. It is not about making websites look pretty. It is about providing processes and services that work for the citizens who need them. Technology changes must be coupled with an empathy for the user experience and the desire to improve the processes that support them. We can use low fidelity prototypes to help us understand the user's needs and make informed, data-driven decisions about how best to serve them. The result can range from plain language content changes to visual updates to system rewrites.

Rapid prototyping has a variety of techniques civil servants can employ without immediately investing lots of money toward development. Engineers and designers are not the only roles that have access to this process—anyone in government who touches service technology can do this like caseworkers, project managers, analysts and policy experts.

A key to making excellent government product and service design choices is having those conversations in-person, if possible. In May, we led a seminar at the Code for America Summit on the importance of and techniques for rapid prototyping in government technology products, even if no developer resources are available immediately. Imagine the possible product improvements if anyone in government who touches service technology—whether directly or not—could contribute, from software developer to program manager to caseworker. 

Public servants should remember that they know their public better than most. They should feel empowered to think beyond the request for proposal and find creative solutions for the problems their users face. Rapid prototyping gives teams the tools they need to be able to push these solutions forward, whether or not they’ve ever written a line of code.

Stephanie Nguyen is a user experience designer and researcher and was most recently a Digital Service Expert at U.S. Digital Service at the White House. She’s currently a Masters in Public Policy candidate at Harvard Kennedy School and a Gleitsman Fellow for social change at the Center for Public Leadership. @nguyenist

Sabrina Williams is a software engineer currently at health care startup Devoted Health. Prior to joining Devoted, she was Acting Director of Engineering at U.S. Digital Service and worked at Google and HP. Sabrina graduated from Stanford with a BA in Philosophy and a BS in Computer Science. @barkimedes