Air Force CXO: We Don’t Have to Delight the User

The Air Force doesn’t necessarily have to delight its users, but the tech and platforms the service builds, buys and uses have to get better, according to Colt Whittall, the Air Force’s first chief experience officer, or CXO, who joined in July. The new role—which reports up to Deputy Chief Information Officer Bill Marion—was created to ensure airmen have digital tools that help their work, rather than hinder.

As he settles into the job, Whittall spoke with Nextgov about how he’s adapting commercial user experience practices and terminology for a military crowd and how the Air Force’s efforts differ from that of the private sector, as well as other areas of government.

The conversation has been edited for length and clarity.

Nextgov: Where do you come from and how did you end up in the customer experience role with the Air Force?

Colt Whittall: I came out of the digital agency world. I was with a digital consultancy that is focused on designing and developing web and mobile digital experiences in the commercial sector. I was part of the group that formed it by spinning it out of Deloitte Consulting and then we grew it and ultimately merged it with another company. It’s about 90% commercial-oriented in the U.S. and maybe 10, 15, 20% of their business supports the government.

That company is currently called Isobar.

I was working on a variety of clients in health care and technology and some government projects. Through that, I met a number of people at the Air Force and began to see that there was a huge need in user experience; there was a huge need in agile development, in DevSecOps; being able to deliver faster, cheaper. And, just frankly, wanted to step up to the challenge.

Did you see a job posting on USAJobs or were you headhunted? How did you find the job?

No. The Air Force was looking to—and still is—was looking to bring in some outside expertise, mainly from the commercial sector into fill a variety of roles and they created a [highly qualified expert] role specifically to put me in.

An HQE role is when the government brings somebody in with senior, outside expertise to do a specific role for usually a fairly specific and limited amount of time.

So, you’re expecting to be around for a limited amount of time?

I’m expecting to serve three years. If they want me to go longer, I could.

“Customer experience” has probably reached the buzzword stage of government adoption: Lots of people are talking about it right now; not everyone is talking about the same thing. What was the need the Air Force had identified?

Two big, broad categories. First, I think the identified need in the Air Force is more about user experience than customer experience. They are two different but related concepts.

In the Air Force, the big, hot button on user experience has to do with what they loosely call “the network.” What they really mean when they say “the network” is the end-to-end user experience from the time that I push return on a laptop or desktop to the time that I get back data or log in to my email or whatever the case may be. It’s that experience of using the network.

There is no question that is the biggest hot button for leadership. It was discussed by all of the senior officers at the [Air Force Information Technology and Cyberpower] Conference down in Montgomery back in August.

The other one: When you go out and talk to the airmen and say, “What’s working and what’s not when it comes to IT?” First of all, they have the same hot button about the network, broadly defined. But they will also tell you about difficulties they have with a wide variety of software applications. Things that are clunky, things that take unnecessary steps, things that require complicated manuals to go learn to do, etc., etc. You’ll hear that again and again, across a wide variety of systems, on any network—from the [unclassified] all the way into the combat support. You’ll hear that across the board: clunky software with a difficult user experience.

I view agile development and DevSecOps as a means to an end. It’s a means to, probably, three main things, maybe four depending on who you talk to. It’s a way to deliver software faster. It’s certainly a way to deliver it at lower cost. It’s also a way to deliver a better user experience. But in order to be able to do that, you’ve got to deliver DevSecOps and agile with the right mix of user experience skills and a process that does the right level of user research and empathy and prototyping and testing for user experience, yadda, yadda, yadda.

How do you get there, then? If doing user-centric design and usability testing are just baked-in parts of agile, what can be done to actually improve the experience? Are there fundamental processes that can be changed? Is it about buying more commercial software and customizing it? Is it about doing less customization? If there’s no silver bullet, what are the steps you can take to actually improve that user experience?

That is a fundamental question. First of all, it’s about the right skills. It’s about knowing what the standards are, knowing what the—for lack of a better word—best practices are. These evolve over time and differ slightly by platform. And then, being willing to adhere to those. Sometimes—in fact, most of the time, that involves not inventing something new in the design process but picking up and reusing something that is standard and generally accepted.

It involves lots of—face-to-face, often—interaction with your end-user and understanding what they’re trying to do. It involves lots of testing with those end-users, and not just functional testing. There’s a lot of programs that do the functional testing and they stop because that’s what the acquisition process requires. And then they never really deliver something that is as simple and straightforward as it could be.

It involves a lot of judgment on the part of the design team. In my experience, I’ve seen people follow the right process, use the right tools, seemingly proceed down the right path in every way with regard to user experience and they end up not delivering that great of a user experience simply because of bad judgment on the part of the design teams.

There’s a lot of judgment and a lot of [quality assurance] that goes into this to do it well. It requires good leadership. It requires the right levels of making sure you’re doing it the right way.

I don’t think it will be successful if all we do is train a few very junior user experience people and then put them in front of the problem and turn them loose. It’s not going to work. Even if they’re following a good process, if they’re using the right tools, they’re going to need to be managed, directed, guided by people who have done this and know how to do it and have good judgment when it comes to how to deliver user experience.

Before you get to the next component: How do you get those experienced people, especially when we’re talking about the military? You can’t just go out and hire people in the same way. Is it training them up—with quick training or career-long training? Is it hiring from outside and outsourcing?

I think it’s going to end up, inevitably, being a mix of all of the above. And for the reasons you just said. I’m already seeing some of that start to happen. We have some areas in the Air Force where they have engaged—or hired—people for the long-term who are very experienced user-experience people.

When it comes to junior people, I think you pull from a variety of places. I have seen really competent UX designers come from a variety of backgrounds. Sometimes, they come out of graphic design backgrounds or come out of designing things for paper and print. Then they merge into digital and instead of designing colors and fonts and pictures, they move more into the experience [realm]. I’ve seen that path work.

Frankly, two of the best designers I’ve ever had working for me in my former life, one had worked for RYOBI, the tools company, and was an industrial designer who moved into the digital space and was a fantastic user experience designer in the digital space. One was a furniture designer. So, industrial design people can come in and do this.

Even performance kind of people that train more in human factors are potential candidates. The good news is the Air Force actually has a decent number of those.

Junior user experience people—I only say “junior” for people moving into digital—they can come from several different backgrounds. And, of course, they can come from IT, too. The common link is it’s design skills, it’s empathy, it’s working with the tools and it’s understanding the fundamentals of frontend software development.

So, let’s go back to the concrete steps you can take.

Where I was going was into optimization. User experience is something that gets better through iteration. These skills play very nicely and are essential for things like lean startup sort of method.

You’ll see that in programs in the Air Force like Kessel Run, where they go into production then follow up with multiple other releases that not only add functionality but also improve the user experience of what they’ve already released.

The point is that we have to get away from this idea that you release an application, you throw it over the wall, it’s been tested for everything under the sun that’s in the requirements document and now it’s in production and we’re not going to touch it for 10 years. We have to get away from that mentality because that will never be successful in terms of UX.

What’s the alternative?

It’s a combination of agile, DevSecOps and UX where we construct the software development lifecycle around those concepts and we be prepared from an acquisition perspective—and I realize this is a big ask and a big change—but we deliver iteratively, continuously, continually improving the UX or optimizing it.

The good news is we are doing it. These software innovations like Kessel Run and others, that is what they are designed to do.

A lot of this is done in other parts of government with a combination of policy and evangelism from key officials. From your perspective, why is it important to have a lead, c-suite official in this role to push these things?

Honestly, before I took the job, I didn’t totally understand it myself. But now I do.

In the government environment, it’s really kind of required. You need somebody—and it is a bit of an evangelist role—but you need somebody who can hold up a goalpost and say, “Here’s the goal we’re shooting for and here’s why.” And start to align the various organizations, skillsets, career fields, acquisition people, etc., etc., etc. And then get them all working independently toward that goal.

In the Air Force, we have tremendous buy-in from senior leadership that we need to work on this. The question is: At the next level down, what are the various goalposts that we have to shoot for, that we’re going to have to hit and how are we going to get there? That’s the function that I can serve: get everyone aligned toward those ends, figure out what their barriers are, help them get past those barriers and help them all move in the same direction.

I want to shift slightly to the concrete steps you are taking. What tools, projects, programs are you pushing from your new position?

When we talk about the network or the infrastructure, in the last, it goes back about six weeks, we stood up an organization called ROLe IT, which stands for Ready Operational and Lethal IT. This is a multiorganization team that we brought together with key senior technology people that know the network and they know the infrastructure and they know all the pieces and parts so that we can lead multiple organizations to go improve the end-to-end experience on the infrastructure.

We stood that up. We do a scrum call three times a week. We’ve got six focused teams working underneath us. And we’re also interfacing with four or five separate, parallel efforts that are tied into what we’re doing that, depending what comes out of them, we’ll scale what they’re doing to the entire enterprise.

There’s a tremendous amount of activity going on under this umbrella already. I’m essentially a day-to-day, hands-in-the-middle-of-it adviser. Helping them with communication, prioritization, how do we organize. Helping them interpret data from our users and then figure out where do we focus and what things do we bubble to the top.

The way that we’re working is really a facilitator to go an investigate bottlenecks in the network, investigate issues on the desktop, investigate policies, perhaps, that value something over and above user experience that maybe we want to reconsider. Figure out what changes we want to make, testing all of those things and then getting them into production as quickly as we can.

Under the software—it’s really more than just the software, it’s the software and the network. It’s the user experience of IT broadly speaking. When you talk to the military, it helps to put it in the context of the OODA loop—observe, orient, decide, act.

When it comes to the overall CX of information technology, we don’t observe today very well at all. We get anecdotal feedback: If a network goes down at a base, we get a call from a general officer. But we don’t do a great job observing. We do on the internals of the network but not necessarily from a user experience perspective.

We don’t orient all that well from a UX perspective, specifically; meaning, interpret the results and figure out what we need to do to improve the experience. We don’t do that very well.

We definitely decide, in the sense that we make prioritizations about which systems and features to implement or turn off or what to invest in. We’re already deciding but we’re not doing it factoring in user experience very well.

Then, when it comes to acting, we build systems, for sure, but it takes too long to do and we don’t get the results we want. That’s because we weren’t observing and orienting with the user in mind.

This will be probably, over time, where I spend the bulk of my time is in the OODA loop of user experience and CX. We need to figure out a better way to observe, and there’s a bunch of things we can do there and I’m working on some of those. We need to figure out a better way to orient. And we need to figure out a way to decide on what we do and what changes we make that factors the user in mind. And then we need a way to act that includes the user in the way we act.

By doing all those things, we will get the user experience and the digital Air Force that the [Secretary of the Air Force] has asked for.

Three years from now, what do you hope to have accomplished? Where do you want the Air Force to be with regard to user experience by the time you’re done?

Having a great user experience within the context of what the Air Force needs. We don’t have to delight the user. I don’t think that’s the right bar. … We need to lower the level of effort to get their job done. And we need to help them lower the number of errors; we need to help them turn around work faster; we need to help them need less training—that’s where the bar is for us.

Where I want to be in three years is have that mentality everywhere within IT procurement and delivery in the Air Force. That should become the expectation. I want the acquisition community understand how to acquire that, how to require it, how to evaluate it, how to implement it. And I would like to have all the processes and tools that are necessary for that OODA loop to work effectively, have all those in place and working.

If we can do that, I think you will see a dramatically different level, much higher degree of user experience across the Air Force.