3 Unexpected Lessons I Learned Conducting UX Research with the Government

In March 2021, I interviewed for a UX Strategist position at a small government contracting firm. The firm specialized in learning technology and training services.

"The researcher in this role will be supporting our Army contract," said my (now) boss to me during the interview.

A few weeks later, I came onto the contract feeling a lot of doubt and—quite frankly—carrying biases of what I thought working with the Army might look like. I was transitioning into UX from a background in linguistics and education. I had learned a lot about the government and how it worked in my previous position as an analyst at the National Science Foundation (NSF).

When I thought about the military, I thought about the $700 billion defense budget, compared to the $8 billion NSF received in 2020. I thought about the war machine and lives that had been affected by war, at home and abroad. And, without actually knowing anyone who had been in the military, I expected my relationships to be hierarchical, rigid, and resistant to change.

But part of our job as researchers is to recognize what we bring to the table, including our biases, and to show up and do good work anyway. The reality is, working with the Army has been one of the most rewarding experiences I've had.

Here are three lessons I've learned as a new researcher navigating UX work in the federal government.

1. Before you do anything, be aware of what you bring to the table.

We often talk about the importance of recognizing and minimizing the effects of bias in research to improve the quality of our data and insights. But there isn't nearly enough conversation around the bias we might bring to the table when we first meet a client, stakeholder, or user.

In her 2018 talk "Ethics & Power: Understanding the Role of Shame in UX Research", Vivianne Castillo describes six ways in which the UX researcher and counselor roles overlap. One of those is "Awareness of what you bring into the session."

For me, this meant taking a step back and examining my discomfort of working with the Army:

• What is the space I'm entering, and how would I describe it?
• How have I come to know things about this space or this particular agency?
• What identities do I have, and how does my experience influence how I view this space?

In doing so, I realized there were several factors at play:

1. The US federal government is funded by taxpayers who have an interest in its success. Unlike something like quantum physics, it's a topic that most of the population can access and discuss. This meant that I, too, had opinions about the government and what it should or should not be doing.
2. I am a white, immigrant, middle class woman who grew up in a blue state with access to education. My experience had shaped my view of the federal government, especially as it related to U.S. education and defense.
3. My experience working in the government also left an imprint. I carried this over into my new role.
4. I was unfamiliar with military culture, but had formed opinions about the kind of people that were in the Army based on media, hearsay, and the circles I was part of.

Becoming aware of what we bring to the table often means accepting uncomfortable truths. And once we do, the research can begin.

2. Question requirements to carve out freedom within the boundaries of the system.

Gathering requirements through the initial discovery phase is an important part of any UX research project.

This research phase looks different in the federal space because of how federal contracting generally works. Before a federal contract can be awarded to a business, a federal agency puts out a Request for Proposals (RFP).

The RFP:

• Announces a project
• Describes the needed solution
• Outlines the anticipated contract’s terms and conditions

Typically at this point, the client already has a set of requirements. Some RFPs can even be as detailed as to include specific technical features for a product.

When I first began as a researcher in this space, I thought, "What's the point? The client is already making assumptions about what the solution looks like. A business is obligated to do what's in the contract."

But that doesn't mean that we can't learn to carve out freedom for ourselves within the boundaries of this system.

For our Army project, this meant creating a Shared Success Framework. This helped our clients take a step back and collaboratively explore the problem space again:

• Vision: What problem are we trying to solve?
• Values: What's important to us?
• Methods: How might we get there?
• Obstacles: What's currently preventing us from being successful?
• Measures: How will we know when we've accomplished our vision? What does success look like?

I learned to pump the brakes on requirements by asking, "Why do we think we need these particular features?" I also asked to delay some of the requirements until we've gathered data that will validate or invalidate our hypothesized solution.

This approach has helped us in a few ways:

1. Aligning stakeholder vision and getting everyone's buy-in
2. Helping our clients learn to question the requirements they initially outlined in the RFP
3. Helping our clients to decide whether they truly met the needs of the population they were trying to serve

While I expected to get pushback on re-examining or delaying requirements, I found that our clients were more than happy to take a step back. They also wanted to make sure that we were doing things in a way that would set the project up for success.

3. Try to understand the constraints of the bureaucracy instead of seeing it as a hurdle.

There are certain things about working as a researcher with the government that you can't sidestep.

For instance, it will always be a reality that the democratic government is a bureaucracy. By design, it has multiple layers of systems and processes put in place to make decision-making slow. This helps mitigate chaos in such a large organization. It also means there are constraints that we have to accept if we want to work in this space.

Constraints can look like:

☒ Strict security requirements that will affect your systems and your users

Products built for the government must meet specific criteria for security. To eliminate the need for time-consuming layers of approval, some agencies choose to eliminate certain features that are obvious for most products.

For example, to avoid exceeding a certain security level in our Army project, we couldn't store Personally Identifiable Information (PII) in the system (no email, no names, etc.). This has a big impact on the user experience.

☒ Reporting requirements that will take time

Government contracts are notorious for frequent reporting. This means that researchers have to be ready to provide data and report progress on a weekly basis. It also means understanding that failure to perform the project in compliance with the contract—like not providing required deliverables on time and on budget—could result in criminal or civil penalties and potential financial consequences for the business. No pressure!

☒ Inability to recruit participants directly

The government has strict rules on who can reach out to the population they serve. In two different projects I was involved in, I was not allowed to reach out to recruit participants directly.

For our Army project, this means going through project stakeholders and organizational leadership to request the participants we need for our studies. As a result, participant recruitment can take much longer and needs more lead time.

Often, constraints mean that the research process is slower and clunkier than in private industry.

But it doesn't mean you can't learn to embrace them and still thrive. The key to carving out freedom is to truly understand the bureaucracy instead of seeing it as a hurdle.

Coming into the Army project, I was expecting to focus a majority of my time on our users and only some of my time on stakeholder management. But I quickly understood that in this environment, it's not enough to focus a majority of my attention on understanding the users.

Working in the federal space is all about learning to navigate and understand the culture and the ecosystem of the users. The tension between balancing user needs and client needs is at the forefront of this work, and translates into a lot more relationship building and stakeholder management.

In summary

In a 2015 interview with comedian Marc Maron, President Obama described how big democratic societies work: “They are like ocean liners: you turn the wheel slowly, and the big ship pivots. Sometimes your job is just to make stuff work.

“Sometimes the task of government is to make incremental improvements, or to try to steer the ocean liner two degrees north or south so that, ten years from now, suddenly we’re in a very different place than we were.”

As more federal, state, and local governments are turning towards improving the customer and user experience, many are wondering what it truly takes to find solutions for systems that are not dissimilar from ocean liners.

Consider this: When trying to find solutions, the biggest problems are not caused by what we don’t know. They are caused by what we think we know.

To set yourself up for success, you can:

1. Become aware of what you bring to the table before you do anything
2. Step back and question requirements to carve out freedom within the boundaries of the system
3. Try to understand the constraints of the bureaucracy, instead of seeing it as a hurdle.