DevOps and user experience at Concur

User experience is not just about pretty design and attractive software screens. It encompasses every link in the chain that influences interactions between a user and the system.

Historically, the enterprise software industry prioritized features and functions over usability. The industry's poor reputation is a predictable result of this legacy.

Although front-end design is most obvious, it is almost impossible to create a great customer experience without an engineering team that places users at the center of its work. Approaches such as DevOps can help engineering organizations become responsive to end-user needs.

To gain an inside look at how one large SaaS vendor thinks about linking engineering and user experience, I spoke with Kevin Evans, who is Vice President of Cloud Services at Concur.

Watch the entire conversation in the video embedded here and read an edited transcript below.

The discussion is part of the CXOTALK series of interviews and took place at New Relic's FutureStack16 conference, held in San Francisco last November.

What is Concur?

Concur is the world's leading travel and expense management provider for enterprise customers. We have about 40,000 customers, and about 35 million users that use the service on a regular basis to help them book and manage travel; as well as create, submit and manage expenses as the manager.

How does DevOps align engineering and customers?

The key message around DevOps is something that we call "end-to-end," because it's about giving responsibility to the teams, the product teams, the engineering groups - to have completed ownership of the services they're designing and building from start to finish. And that start to finish obviously starts with the capabilities and functionality of the software. But the finish is "How do we run the software? How well does it perform? How well does the service behave for the end-user?" And so, the end-to-end philosophy for us is about giving the controls, but also the responsibility and accountability to each of those teams. [It's] about making sure that the service is delivered to the end-user the way the end-user expects it.

It is. It's extremely important for us to consider the end-user and their experience using the service in everything that they're doing.

Is this different from traditional engineering?

So, I think if you were to look back at how we used to develop software at Concur, it was about focusing on the product and the functionality, and the requirements were heavily weighted towards "How is the functionality going to work for the end-user?" And I think what you will look at today and the major difference with how we build and deliver software is it's more just as much about the service as it is about the functionality. And so, how well is it going to perform? How resilient is it? How is the availability of the service going to come across for the end-user?

Why is data the glue between end-users and engineering?

We collect a tremendous amount of data. Sometimes, we refer to ourselves as a data collection company that just happens to do travel and expense management because the amounts of data that we're collecting about how the service is used, how the user interaction is happening, what the experience is like for the end-user ... Coming back and narrowing that too when there are challenges: What did the infrastructure look like? What's happening on the servers when those things are happening? What's happening with the code when the experience is bad? Or in many cases, what's happening when the user experience is good?

The only way that we have found that we can successfully make the right decisions from an engineering standpoint about how the servers are going to work is to be evaluating how the service is working in real-time. And so, that real-time aspect of the data, the fact that we're collecting so much information about user experience as they're using a service. And then we need to leverage that in our design process.

It's a real change from a traditional model where you're used to (and I think this is no longer [the case]) ─ I think it was the previous process that a lot of companies went through in developing software. You focus on the functionality. I think it's now about focusing on the service itself, and that goes to not just the development engineers who are building it, but from a product standpoint [of]: How are we delivering it? How do we upgrade it? How do we manage it? And that's user experience. It goes all the way back to the very first part of the very front part of the process.

There's a very complex set of systems that run the service and a very complex set of users that are from different variants, as far as where they're at in the world, what types of systems that they're using, whether they're using a tablet, whether they're using a browser. There's a lot of complex data that has to come together. And we need to coalesce all of that information and make it meaningful to a broad set of users that have different requirements, as well as different experiences about working with data. So, it's a challenge for us to make sure that we're presenting useful information that can be used to make decisions, as opposed to just presenting data.

Anyone can collect a lot of data. It's what you do with it, and how you turn it into information so you can make good, intelligent decisions from that data.

Thank you to New Relic for sponsoring this video.