57: On Being a Chief Experience Officer (ft. Amy Lokey)

Transcript

Jesse: I’m Jesse James Garrett,

Peter: and I’m Peter Merholz.

Jesse: And we’re finding our way,

Peter: Navigating the opportunities

Jesse: and challenges

Peter: of design and design leadership,

Jesse: Welcome to the next phase. Joining us today to talk about what’s next for design is Amy Lokey, Chief Experience Officer for the enterprise software platform, ServiceNow. We’ll be talking about building a team that unifies product experience with customer experience, defining experience metrics that actually matter, investing in her own growth as a leader, and the real implications of AI for digital product design.

Peter: Amy, thank you so much for joining us.

Amy: You’re so welcome. I’m happy to be here.

What does a Chief Experience Officer do?

Peter: So, in the introduction that Jesse will have recorded before people hear us talk, he will mention that you are a CXO, Chief Experience Officer at ServiceNow. What is a Chief Experience Officer?

Amy: Well, Chief Experience Officer, I’ll say first is importantly not a CEO, because you can only have one of those. So that’s why I’m A CXO. But I run product experience and also customer experience at ServiceNow. My wheelhouse, my background, is primarily in product user experience design. My team includes all of the functions that you would expect in user experience design team.

So we have a large research organization. We have a large design organization. We have design operations and various operational functions that keep us kind of working together smoothly and things running. And then additionally, I have a large content team as well, too, that produces content for our technical documentation, best practices content, and is really the engine behind a lot of the content that helps our customers be successful with our products. And as part of that, we’re also responsible for a lot of the digital experiences that our customers use to be successful.

So everything from… We have a learning experience where our customers and developers can get credentialed on ServiceNow. We have our customer support site. We have a product called Impact where our customers get kind of white glove customer support and work with squads of people that help them get up and running. So there’s a number of digital experiences. Those are just a few that my team also is responsible for. And so that’s the customer experience side of it.

And then our product suite includes customer support software. So, there’s an intersection of our own product, is what we use for those experiences, so a lot of what we build to support our customers is the same thing that we’re building as a product that we sell to customers too. So there’s kind of an interplay in how all of that product experience design works and how we’re using it.

Peter: And just to kind of establish some boundaries here, when you’re talking about customer experience, what is your relationship to marketing and kind of that front end of the funnel? And do you do any design or research work on that side? And then on the other side, more kind of typical customer service and even maybe even customer success. It sounds like those are outside your purview…

Amy: Those are outside of my… yeah, yeah. From an organizational standpoint, so, we have a great CMO Colin, he leads our marketing organization. They do have a couple creative teams within that organization that work on various parts and pieces. And so our corporate website, for example, his team drives that.

The digital experience, that we work really closely to bring those together in one unified navigation. So we want, from a brand and from a user experience design standpoint, we want it to be really seamless. So whether you’re looking on what might the corporate site, meaning, like, you’re looking at our products, you’re looking at our marketing communications, you’re evaluating the company, or you move into, Hey, I need to deploy this new thing that I got and I need some detailed information on that.

You move more into the customer experience side of it. That’s my team. But we want those, you know, boundaries to be invisible to our customers. So we do have kind of an architecture that we work on from an information architecture standpoint, even like a universal login standpoint. So that’s, hopefully, not visible to customers, even though we have two different teams working on those parts.

Peter: Sometimes customer experience means customer service. Do you have a relationship there?

Amy: Absolutely, I don’t run customer service. So there’s another leader that runs customer service in terms of our support organization. But my team does work on the digital experience. So we design that entry point, right? And that’s, again, using our own product and then building it out to fit the needs of our particular customer service experience.

So the digital experience we are responsible for, we support that. But the team of people that are behind that support system, like they’re managed by a different person. Yeah.

Jesse: Within your team, you have an unusually broad mandate. In terms of bringing together both product experience and customer experience capabilities, and content as well. And I find myself curious about the organizational impetus to unify these functions. What’s the value of having a unified team with such a broad mandate that in most organizations is kept separate?

Amy: Yeah. it’s not all organizations that are separate. I will say, like reflecting back at my time at Google, when I led user experience for G Suite, I was also responsible for the technical documentation. So, I think there are cases where you might have one org leader over both. The reason why I think it makes sense here is, the documentation of, like, how the product works is in many ways just this foundational piece that all of our other marketing and other content pieces are built from. We’re kind of the source of truth, and the people who write that content really sit side by side with the designers and the engineers building the products.

So they are very much integrated into the product development process. And I think that’s an important part of why this all works. So, you know, my peer groups in my organization are, you know, product management and engineering, just to like very general terms, right? And then I have kind of the everything else bucket of user experience plus product, content and research and so on.

But all the functions within my team are very, very close and tight with the product development process. So they’re working with product management, engineering. We are part of that release cycle. We’re part of, like, QE processes. So I think that’s why it all makes sense. It’s just fundamentally, I’m part of an R and D org and all of the experts within my team are part of that process that deploys software and then builds the things on top of it that help our customers be successful with that software.

But we have to have that subject matter expertise of really understanding what it was designed to do and what it was built to do, and how it really, really works to be that source of truth. So we’re, you know, the customers that come to our documentation, they see it as very objective. It’s intentionally not positioned in a marketing type of framing.

It is just factual because then it’s very, very trustworthy and seen as like this is the absolute source of truth of how something works.

Peter: On your LinkedIn profile, when you define yourself as a CXO, you mentioned design and research, product content, design operations, but then there’s this phrase, information strategy. What is that?

Amy: It’s how we deliver the right information to our customers. And so we are doing a lot of work to think about the best way to deliver vast amounts of information and what that strategy is. So it’s very much information architecture. We have a team internally, we call it Lexicon, which is just how we actually name our products, how they’re actually affiliated into our customer support experience, right?

So if you file a ticket about our software, you’re gonna say what product you’re using, what functionality you’re using, that all has a data architecture in the backend that helps us tag it to particular products. So then we can kind of document the throughput of information back to the product team.

So that information strategy and information architecture, it’s not only how we externally organize the content, it’s also how we internally tag it and map the data basically. So we have that throughput of information.

The Holy Grail of Information Architecture

Peter: This is like a holy grail. Well, so Jesse and I came up as information architects, and I think one of the challenges that I’ve seen UX teams face is, when they want to get to data models and content models, who owns those relationships with engineering, a lack of broad horizontal view of a company’s information standards and platforms and, and practices, and so it gets in the way when you’re trying to create, say, a unified navigation across a multi-product suite when every team has kind of done things their own way. And I guess usually this is solved by enterprise architecture or something, but it feels like your team has a bigger voice in this conversation, I guess recognizing there’s a user expe