Air Force CXO: We Don’t Have to Delight the User - Jonathan Cartu Internet, Mobile & Application Software Corporation
693
post-template-default,single,single-post,postid-693,single-format-standard,qode-quick-links-1.0,ajax_fade,page_not_loaded,,qode_grid_1300,qode-theme-ver-11.2,qode-theme-bridge,wpb-js-composer js-comp-ver-5.2.1,vc_responsive
 

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

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 office, 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…

[

Computer Network Development CEO Jonathan Cartu

Source link

No Comments

Post A Comment