While at this year’s Code for America Summit, I met up with friends and former coworkers from 18F, the U.S. Digital Service, Code for America, and similar organizations and realized that we’re all focused on improving “government digital services,” but don’t have a shared definition for what that term means.
This post offers one perspective on the conversation, by outlining how we think about digital services at Ad Hoc and how these ideas relate to our product practice and approach.
Creating new ways for government to interact with and serve people
At Ad Hoc, we define a digital service as technology that enables effective interactions between government and the people it serves. These interactions can be supported in a variety of ways, such as a digital experience that helps people search for and compare healthcare plans, or an API that allows for the secure exchange of data between patients and physicians.
Our team likes to think of digital services as “social infrastructure,” similar to physical bridges and roads, that supports the public good. Just like a bridge, technology needs to be designed for the environment it supports. When it comes to designing new digital services for government, this means finding ways to best meet user needs within the context of policy, organizational, and technology constraints. Similarly, if we deliver a great user experience but do so in isolation of other factors, like people and process, we’re only solving for part of the problem.
Digital services bring together people, process, and technology to enable an end-to-end experience.
Key characteristics of an effective government digital service
Effective digital services provide an end-to-end experience that benefits both the consumers and providers of a service. In other words, it’s about making sure that the products we deliver work for end-users as well as the people, process, and technology they support. This starts with mapping the service, understanding it’s various touch points, and identifying where technology can make the greatest impact. It also involves bringing stakeholders together to understand how the service works as a whole and making government an integral part of the design process to ensure that the solutions we deliver are effective at scale.
We’ll talk more in future posts about how Ad Hoc’s product practice measures the impact of what we deliver. In the meanwhile, let’s talk about what success looks like. While not an exhaustive list, we believe that all effective digital services share the following characteristics:
- They promote the public’s trust in government by providing information that is timely and accurate and enabling transactions that are secure and reliable.
- They expand access to services by making technology easier to use, creating a shared experience across digital and non-digital service channels, and enabling self-service whenever possible.
- They’re designed in a way that facilitates change and allows government to deliver on them at scale.
What this means for product teams serving government
As we explained in an earlier post, Ad Hoc defines product management as a discipline for maximizing the value of what we deliver given our customer’s goals, user needs, and constraints. Finding the right balance among these factors means viewing government as a service and the products we deliver as enablers of those services. These perspectives are important because they help us focus on the right problems to solve and work towards the outcomes that really matter, like whether or not people can get the help they need, rather than just meeting requirements.
For example, if we’re working with an agency to improve how veterans apply for healthcare online, we’ll want to design a digital application that is easy to use, but which also works with relevant systems and processes so the agency can process those new applications efficiently. Solving for both end-user and organization needs is important because the goal of the service is to connect veterans with healthcare, not just to let them apply. If we only focus on the usability of the form for veterans, but not on how staff expect to process them, or how application data will flow between systems, we may leave the agency with a huge influx of applications that it can’t possibly keep up with. Even worse, this new backlog may result in longer wait times for veterans because we haven’t delivered a solution that facilitates the organization’s transition from a paper-based world.
More product efforts should start with service design
As government continues to invest in digital services and as the public’s expectations of them grows, product managers should expect more of their work to include elements of service design. This is because the mission of government is to serve people and our job as product managers is to deliver products that support that purpose. Doing so will require product managers to think more holistically about the problems they’re trying to solve and how products can bring together people and organizations to enable an end-to-end experience. It will also require product managers to work even more closely with other disciplines, like research and design, as government focuses more on delivering effective services, rather than just software that meets requirements.
If we’re going to build new social infrastructure for a digital age, we need to think differently about the role of technology — less as something we build in reaction to policy change or executive mandate and more as a catalyst for improving how government interacts with and serves people.
