Becoming truly customer-centric is a big challenge for most organizations. It’s even harder for big companies that have to deal with existing hierarchies and rethink processes that have been used for years. UX consultant, author, and educator Jared Spool is an expert in driving this type of change for big organizations like NASA. We sat down with him to talk about the ways teams can increase their UX maturity and avoid common mistakes when trying to understand their users.
Jared Spool is a Maker of Awesomeness at Center Centre – UIE. Center Centre is the school he started with Leslie Jensen-Inman to create industry-ready User Experience Designers. In the 39 years he’s been in the tech field, he’s worked with hundreds of organizations, written two books, published hundreds of articles and podcasts, and tours the world speaking to audiences everywhere.
UX maturity
My first question is about assessing big organizations — when do they need to build a UX strategy? How do they evaluate what they already have?
Everybody starts at a different place. Usually, they start because they’re a little panicked, and they feel like they’re not using their UX capabilities to the fullest. So a UX strategy is a way to use all of your UX resources — your teams, knowledge, and expertise — to help the business achieve a major objective.
There are five critical stages that an organization goes through to become more UX mature. In the first stage (we call it the ‘Dark Ages’), they are focused on the basics: getting business and technology to work. So users are not part of the plan.
At some point, they master the business and the technology, but customers are still not flocking to them, or they’re struggling. Senior management starts to think, “Okay, so what kind of strategy can we build to help?” At that point, a UX strategy starts with just a couple of people in the organization. We call that stage ‘Spot UX Design.’ During this phase, different parts of the company start thinking about the user experience and trying things out. But this approach doesn’t produce much, it just gets them started.
The real forward movement happens when someone with resources decides that the company needs to invest in user experience so they can grow their capabilities. At that point, we get to what we call UX design as a service. They’re hiring a manager, building a team, and have a bunch of people who function as an internal agency. A lot of teams stay at that stage for a really long time.
For the longest time, designers thought that was what we were all supposed to be doing. That was the goal of the project. But then we realized that’s not actually the goal. If you do your job really well, the teams that you’re working for as a service start to get a little anxious, and they’re not happy with you because you can’t give them enough resources.
You then shift to the next stage, which we call embedded UX design. That means there’s a designer embedded in each product or service team who is thinking about the design of that product or service 100% of the time. They’re thinking about multiple releases, and they’re digging into deeper problems. For the longest time, we thought that was the ultimate goal — if we could get designers embedded into every team, then we have succeeded. But it turns out that’s not it either.
There’s a final stage. We call it infused UX design. Infused UX design starts to happen when people who don’t think of themselves as designers begin to make smart design decisions. They have been part of the process all along, and now they have the knowledge to make smart decisions on their own. If the organization has developers who come up with pretty good designs by themselves, or product managers making decisions based on what users actually need instead of what will ship faster or what will be easier to develop, it show the company’s UX maturity.
When you are starting to go to the Infused UX Design stage, how do you involve all the major stakeholders?
Usually, the stakeholder doesn’t say, “I give people permission to learn how to do this.” You get support from stakeholders, and it comes from making sure that the incentive system is rewarding people for producing better quality products or services. If you’re rewarding people for shipping fast, but it doesn’t matter whether what they ship is any good or not, then that’s not going to work. It’s really about mustering the support by having the stakeholders understand how this is strategically important. If you can make it map into the strategic priorities, you can make that happen.
How do you align your UX goals with your business goals?
Business goals always boil down to about several things. You’re either increasing revenue, decreasing costs, increasing the money you bring in from new customers, increasing the amount of existing money that you’re getting from existing channels, or increasing your overall long-term shareholder value. I believe that any design should be translated into at least one of those five things. If you can’t do that, then you’re working on the wrong thing.
The Five Stages of UX Design Maturity
stage 1. Dark Ages
The team is entirely focused on meeting the business and technology challenges, without considering the user’s experience at all.
stage 2. Spot UX Design
An emerging design leader within the team struggles to deliver products and services with improved user experiences.
stage 3. UX Design As A Service
Executive support to form and grow a centralized UX design team comes to the organization.
stage 4. Embedded UX Design
Teams bring on their own UX design capability, separate from the centralized UX design team, to deliver enhanced user experiences.
stage 5. Infused UX Design
Non-design members of the team have developed sufficient UX design expertise to, alongside the team’s UX designers, deliver market-leading user experiences.
One of the places where organizations get tripped up is they’ll use a lot of proxies for information
UX & Agile
How does building a UX strategy connect with agile transformation?
Agile transformation is about producing something for customers faster. The trick is using feedback from the actual customers. One of the places where organizations get tripped up is they’ll use a lot of proxies for information. A business owner or a product manager will say, “This is what I think the customer wants, ” and they’ll build for that. Then they deliver it, and it turns out they were wrong. It’s important to work with user experience professionals so they start with research, so you really get to understand what problem this product is solving.
Problems are basically stepping stones to what the outcomes are for users. If we did a fantastic job shipping this product, what would be different in the lives of our customers? If we’re creating a product that helps salespeople sell more, what does this product do to help salespeople sell more? How are their lives better because we’ve delivered this? We use our understanding of that outcome to say, “What are the problems we have to solve in order to get the customer to have that great experience?” Once we can identify what the problem is, the solutions are usually easy to come by.
The issue with agile is that it’s very solution-focused. You put things on a backlog, you figure out what you’re working on in your sprint, and then you just put your head down and you work on it. What we really want to be using agile for is what it was made for — to answer the question, “Are we solving the right problem? Do we understand what the problem is that we’re trying to solve?” If we can use agile to do that, we’re going to be much more successful delivering well-designed products and services.
You wrote an article about Jobs To Be Done and how a lot of people overuse it. Are there any other approaches that you think are very solution-focused, and not as universal as the many UX professionals think?
I think Jobs To Be Done is particularly difficult because it really is focused on just getting to the notion of a solution as fast as possible. If you think of jobs the user trying to hire for, it implies that I understand users experience, and it’s a very transactional approach. That’s problematic because people don’t think transactionally. Nobody thinks that they are hiring a pen to put notes on a piece of paper. The problem is that we are solving the wrong problem that is imagined by designers, and there’s very little in the standard discussion of Jobs To Be Done about how you actually do the research to understand what the users really need.
That part is really missing in all the writing, and most of the discussion of Jobs To Be Done. You can use any UX research approach to figure out what users need, but most people who are applying Jobs To Be Done don’t know that. There’s no discussion of that, and the fact is that it’s really hard work and it takes a bit of skill. So people who buy into Jobs To Be Done unfortunately are buying into this promise of, “I just need to figure out what the job is.”
The more users you spend time with, the better off you’ll be
What approaches or techniques really help to understand the problems users are facing?
You just have to spend time with your users and do what we call “deep hanging out.” You spend time just getting to know what users need. From there, focus on the needs of each person that will factor into your decision-making process. The more users you spend time with, the better off you’ll be. So it’s really about just observing users as they try to do things that your product is supposed to help them with. From there, you can see the problems they’re having, and how your product helps them overcome those problems and do better work.
By “deep hanging out” I mean lots of watching and listening, not just doing interviews. For example, when we were working on sales enablement software, we spent a lot of time watching salespeople, going on sales calls with them, seeing how they’re interacting, looking at where some sort of enterprise sales tool could make their sales process more effective. We found out they were having to prepare materials for customers they just met with that talked about the products or their customers’ challenges. They gathered up different PDFs: case studies, white papers, and product descriptions, and sent them off…
It was a very messy process. They would miss things or they wouldn’t get to it. If they had multiple sales calls in a day, it might be several days before they sent anything. We realized that, based on the nature of the sales call, it would be useful to establish what materials would be needed, and package them up in a way that would be easy for the customer to go through — at the same time, easy for the salesperson to gather up and put a little note on it and sell it. But the only way we would know that is by spending time actually watching salespeople struggle to collect collateral and get it to customers, to support the sales process.
UX research at scale
What techniques help distribute research insights across the whole company?
Make sure that all the stakeholders are part of the team that does the research. If they’re going out and meeting the customers with everybody else, you don’t have to spend time collecting the results, documenting what you saw, and training people on what you learned. That disconnect creates a risk for information to get lost or distorted. If they are with the customers when you’re visiting them, then they saw what you saw.
How do you do that with a bigger company?
You build the research capability. Organizations that realize the value of user research don’t let the fact that it takes a bit of work stop them from doing it. It takes resources, but it is doable. When you build it at scale, it’s not actually that difficult. Many teams already have opportunities to meet with customers. Product managers are meeting with customers all the time, they just don’t know what questions to ask or how to spend the time with them. So they ask them questions like, “What features would you like to see in a product?” That’s not the right way to do the research.
Organizations that realize the value of user research don’t let the fact that it takes a bit of work to stop them from doing it
But if you say, “Tell me about something that’s really frustrating today, ” then suddenly you’re in a conversation. Then say, “Can you show me what that is?”, and you can have a conversation where they’re showing you what’s wrong. Now you’re observing. UX research is not rocket science. We know this because NASA is one of our clients. They have a very strict definition as to what’s rocket science, and they have been very clear: this is not rocket science.
