Barriers to Government’s Adoption of User-centered Design — And How To Address Them

Last summer, my colleague Anna Heller Sebok and I embarked on a 10x project to explore (and potentially improve) user-centered design practices across the federal government. We fondly named our project ‘Users First’.

With our research, we wanted to understand the extent to which federal agencies were building in a user-centered way (where product design and development focused on user needs) and the benefits they had realized. For agencies that weren’t, we wanted to understand why, and to identify ways we might assist them in getting started.

In this article we’ll provide an overview of four of the most common barriers Anna and I heard, and how federal agencies might go about addressing them. (Note: We focused this research on non-regulatory barriers, and thus won’t be covering items such as privacy, The Paperwork Reduction Act of 1995 (PRA),etc.)

“We don’t have time, money, or expertise.”

Many agencies we interviewed were understaffed, tight on budget, or relatively new in their practice of user-centered design, making it difficult for them to continuously invite user feedback into their product development process. Most agencies we interviewed experienced continuous staff turnover. Some agencies had a single employee managing all of the agency’s digital properties!

Not surprisingly, these agencies expressed difficulty in planning and maintaining continuity around their user-centered initiatives. Resource limitation created low change tolerance and diminished motivation, causing agencies to focus on “maintaining the status quo,” which often resulted in extreme technical debt rather than taking a more user-centered approach.

How to address this:

• “Dip your toe in.” Start your journey into user-centered design with small initiatives. Usability testing is a great way to test your riskiest assumptions early in the process and avoid costs of redoing or rebuilding your products. Some free resources: Introduction to remote moderated usability testing, and the 18F Methods. Also, we heard some agencies including user research and usability testing as a part of their contracts with vendors.
• Apply analytics to your site. This is a quick and easy solution to measure the impact of any improvements you make.
• Nurture communities of practice at your agency, and/or join an existing one. Communities of Practice bring people with similar circumstances, challenges, and goals together to cross-pollinate ideas. They’re free to join, participate, and engage in, and can incubate new ideas and practices within your team. A great place to start is the government wide UX Community of Practice, a vibrant and active group of individuals working on driving user-centered design in the government.

“Isn’t research a one-time thing?”

We learnt from our interviews that gaining stakeholder buy-in for research can be difficult. One interviewee shared that they were constantly asked by their senior managers as to when user research would end. The interviewee was met with pushback when they mentioned that user-centered design is a continuous and iterative process, rather than a one time occurance. Some consider reaching out to their audience as a manifestation of their own incompetence: that asking users about their needs risks showing that agencies are unaware of those needs.

Others mentioned recent failures in public view (or those that required Congressional intervention) as motivation to adopt a more user-centered approach. Some mentioned that working in a user-centered approach helped them understand what the users DIDN’T need and what NOT to include in a product, saving a lot of time, effort and dollars. Others mentioned that adopting a user’s first mindset helped them gain buy-in from their users early on, reducing the risk of failure.

How to address this:

• Acknowledge that familiarity breeds assumptions — research is useful and insightful, for our purposes, if it’s recent. Product development is a continuous, iterative process. Relying on stale research for a continuously iterating product is not only wasteful, it’s potentially disastrous. Two suggestions:
  • Do an assumption-mapping exercise to help your team acknowledge everything they “know” about your users and their problems. Identify the riskiest ones and explore them.
  • Develop continuous feedback loops with your users. Begin by understanding their needs, hypothesize and develop solutions, conduct usability tests to showcase your solution, collect feedback, and repeat the process all over. Do this continuously and frequently for all your products.

Saving money isn’t always celebrated

This is a counterintuitive truism: government agencies aren’t always incentivized to work towards cost savings. Indeed, many agencies will see their future funding slashed if they spend significantly less money than they’ve been allocated.

As a result, risk-mitigation techniques like design research can get deprioritized. Design research presents a wealth of benefits—like helping us create simpler, more beautiful, more usable products and services. It can be difficult to measure these things, especially in dollars. What’s the dollar value of more usable government services (and is this even an argument we need to make)?

Cost/time savings, user retention, and decreased customer service complaints are fantastic ways to measure the success of user-centered design. However, funding authorities need to incentivize agencies to focus on these things. In the long run, good design reduces costs to both the agencies and the users they serve.

How to address this:

• Funding authorities should incentivize agencies that declare cost savings due to improved user research and user-centric processes. Oversight bodies such as Inspector Generals and Congress should start including user performance metrics around efficiency, effectiveness, and satisfaction as measures of success.

Programs that exhibit the benefits of a user-centered approach should be celebrated and commended. Two such programs include:

• SFTool: This site on sustainable buildings and procurement is produced by a phenomenal team at the Office of Federal High-Performance Buildings team (OFHPB). They maintain their site and deploy new modules in collaboration with their vendors for between $11K and $38K per module. They maintain a short sprint cycle and deploy, learn and iterate multiple times a month.
• Programs such as 10x.gsa.gov (which funded this research) have a great funding model and celebrate saving money while also championing user centered and agile product principles very efficiently. Programs such as 10x take on new ideas, determine the viability of the idea via user research, and proceed toward product development only if the research supports the need.

“We just need something to show”

Agencies often find themselves at a point where an output is indeed delivered, but the outcome, such as anticipated user adoption, isn’t. Sometimes it’s more politically expedient to focus on output over end-user outcomes: it’s difficult to measure the success of research and user experience as these are primarily qualitative. Quantifying the return on investment for any research or UX effort is difficult; satisfaction can seem extremely qualitative and vague. One interviewee mentioned that their product development is tied to external timelines (congressional or policy driven) needing them to turn around products quickly.

How to address this:

• Learn about your users and their needs: don’t expect them to solve it for you! Two common mistakes agencies make are: asking questions geared towards a solution they have in mind already; or asking users to propose solutions, which is really bad! Users don’t always know what best serves their need until they see the product. They see solutions that fits their particular needs rather than a solution that caters to a large audience base. Ask the right questions so your teams can prioritize solutions.
  • For example, DON’T ask your users if they want to see an app. DO ask questions to learn how they interact with your product, how they access it (mobile/desktop, etc) and hypothesize if the features they need are best optimized via an app.
• “Build more choosers” - Create features that compel your users to choose your product. Products/solutions built in the government are usually the only solution for your users without competing products to choose from. In such cases, focus on delivering the best user experience to get their needs met. Making user adoption and retention a priority will mean more users choosing your product vs using your product for lack of an alternative.

User research in the government comes with challenges, but isn’t impossible. Your teams should reflect on these three questions frequently:

• Who are we building the product for?
• Why do we feel our product will solve for their needs?
• When do we know we have added value for users?

Lastly, as our project name goes - USERS always come FIRST.