Recording: UX Outcomes: The UX Leader’s Secret Advantage - Talk UX Strategy with Jared Spool
When people talk about UX work, they almost always talk about deliverables.
- They talk about creating personas.
- They talk about conducting stakeholder interviews.
- They talk about creating process flow diagrams.
- They talk about creating journey maps of how users interact with the product.
- They talk about creating service blueprints of how the service works behind the scenes.
- They talk about making recommendations from research studies.
- They talk about providing the developers wireframes and figma files.
- They talk about crafting design pattern libraries. UX people fetish their deliverables.
They see their design process as moving from one deliverable to another.
- Which deliverables come first?
- Which come last?
- What’s the order in between? Many teams evaluate new hires by the deliverables they produce.
- Portfolios are an exquisite example of how much we fetishize deliverables.
Deliverables are ==tactical outputs==.
- Outputs are what we deliver. (Developer shipping code, a PM's roadmap, etc)
- However, ==customers and users don’t care about outputs==.
- They don’t receive value from outputs.
- It’s no wonder that executives and key stakeholders have trouble seeing the value of UX.
- The senior executives can’t connect the outputs to the value of the product or service.
- It’s hard to see the value of personas.
- Or stakeholder interviews, journey maps, or wireframes.
- It’s even hard to see the value of design recommendations.
- They don’t speak specifically to why customers or users will get benefits.
@7:14~
==Value is what someone will pay (using money, time, attention, or something else they treasure).== - When senior executives seek value, they’re looking for what will make people pay more. - Or for more people to pay something for the first time. - UX outputs don’t show anyone how the UX team is increasing value.
Focusing on reducing frustration has a momentary effect.
- It can get us to “usable.”
- That adds value for the moment.
- However, that’s the steady state that users expect. (==as Debbie Millman noted in Reinventing Yourself, "these are table stakes" and says nothing about what "makes you unique", or your product…It works? I mean, I HOPE SO, I'm paying for it!!!==)
- Overtime, usable doesn’t add more value.
- The small amount it value it adds dissipates quickly.
==UX leaders need to push the boundaries of adding value.==
- Value comes to customers when they get meaningful benefits.
- People will pay more for meaningful benefits.
- ==Value comes when we increase the quality of the product or the service.==
When we improve the users’ experience, we increase the value of the product.
- The bigger the improvement, the more we increase value.
This is the role of UX Outcomes.
- ==UX outcomes are meaningful improvements to the lives of our customers’ and users’ lives.==
An outcome is an observable change in the world. @16:40 ~
- Outcomes can be positive or negative.
- For a UX outcome, we want to focus on positive change.
- We don’t want the change to be harmful to our users or customers.
- For a UX outcome, we want to focus on positive change.
UX outcomes are different from business outcomes. @18:20 ~
- Business outcomes are observable changes to the business.
- They can be increased revenue or customer retention.
==We want to prioritize UX outcomes over business outcomes.==
- Focusing primarily on business outcomes can result in harming our customers and users.
When we focus on UX outcomes, we’re focusing on improving people’s lives in a meaningful way.
- When we improve the lives of customers, users, and others affected by the use of our product, we increase the value of the product.
- By showing the improvement in people’s lives, we move away from outputs.
- ==We still need deliverables to do our work.==
- However, they’re not the objective of UX work.
The objective is to improve the lives of customers, users, and others who are affected by our products and services.
- This has clear connections to value.
- Customers whose lives are improved will pay more.
- This is our secret advantage.
My notes from video
Beyond the main talking points, he talks through the ideas more in depth and draws examples and diagrams.
@ 7:14 What will make people pay more? Or more people pay something for the first time? Focus on the Increase of Value. Everyone wins here.
- Regarding design recommendations, think of scale of user experience:
- Extreme delight 👼
- Neutral point in the middle 😴
- Extreme frustration 🤬
When conducting things like usability tests, we tend to focus on the items that fall into area of frustration. We look at this world of frustration and we can look to fix it in our design recomendations. When we get to the neutral point after eliminating the frustration, we are in the world of making things usable.
==But real value lives in the world of extreme delight. ==
==No one gets excited about finally hitting the neutral point.== Baseline is table stakes. Example of restaurant industry, where no one is thrilled about "the food is edible!!!". Another name for the baseline is "Satisfactory". Satisfaction surveys are only measuring from baseline and down. Doesn't help us in what to do that is useful.
When someone pays to get the upgrade to get something extra (convenience, going out for a fancy meal, etc) - this is value. They pay more to improve their life. This is where UX leaders can add a tremendous amount of value.
We cannot add a lot of value by just eliminating frustration. It is not enough because anyone can just copy and if all products are the same, baseline is just a comodity. If it is a comodity, you just buy the cheapest. Dish soap or toothpaste if you can't tell the difference, you'll ask "why should I pay more for that brand when I can get the same thing and pay less?".
Just eliminating frustration dissipates too quickly. Focusing on notion of meaningful benefits, the thing people will pay more, that's where value comes from. We don't get more value by delivering more personas…Focus on "moving the needle". How people's lives are affected.
==Outcomes are meaningful improvements to people's lives.== And observable c
UX Outcomes → focus on the word "Experience". We often focus too much on the user. To increase value, we need to improve the experience. We need the user to see the delight, see the benefit, it is remarkable from their perspective.
Q&A from session
Q1
-
34:14 How do we convince tough stakeholders to let us, UX teams, conduct critical research/services (outputs) when we can't guarantee the Outcome?
- Discovery allows you to become the expert
- leadership has to buy in and believe discovery must be done, or else it shows what they believe about UX
Q2
- 41:23 Often the features/product roadmaps are owned by PMs. How do we show the value of Design separate from the Product Management team’s?
Question: "At org, I've build design team, but because it is new, the question I get is 'what's the value that design is adding?' ~ ultimately the product roadmap is owned by PMs, design has a partner role, and the metrics we point to are co-owned by both teams"
The idea you need to show the value of design separately is a little bit of a red herron. It's like saying in a michelin star kitchen, "what's the value of the person working the grill". Sure, it is essential to the meal, but does it have a unique/separate value from the rest of the team? What's the individual breakdown of each role's individual contribution is not really all that valuable - at the end of the day, customers have a great meal or they don't.
==Where it becomes value is to determine where are you dropping the ball.== Noting the place(s) we ran into trouble is actually helpful - not sure spending time showing the value of design is that interesting.
The real place where it matters is had you not focused on improving customer's life, if you didn't produce ways of measuring the improvements, and all the insight that helped you get there, that's where you can see the difference.
UX team is important as it:
- Creates value in insights
- Helped to improve customer's lives
- Measured the improvements to validate and confirm
Where I tend to focus is by reframing what we're looking at - very explicit improvements, like observable change - what we can do there is to say right now on scale of frustration to delight, some delight in places of a product or service, etc
Journey Map to explain the point:
Now, by having spotted the frustration - what we have to do to not just hit the baseline, but to create delight in those spaces? Insight by studying current experience that none of the competitors have done yet.
The value in identifying the valleys and how to reach product market fit - the product markets itself if you solve those problems.
A place where we ran into trouble
"The quality of the salad is not based on the amount of lettuce you used, not an indicator of whether the food was any good" ~ speaking on some aspect of metrics/tracking?"
"Output based metrics - was the experience improved? for how many customers did you improve experience? That's a team effort."
- It doesn't matter how well the 3rd baseman plays if the team lost the game…
- ~ It can be boiled down to Number of runs your team got vs Number of runs the other team got. That's the key thing.
- If you keep trying to create derivative measures and try and figure out if 3rd baseman is worth all the money we pay, "is design worth the money we pay for it?" - At the end of the day, is our product winning because of the design we have? Is it so much better than competitors that people will come to our product no matter what? Why people go to [brand name], it isn't because of a particular person but the whole product.
end of answer @52:32
they key thing is that what you really need to do, you need to show the real objective of everything everyone on the team is trying to accomplish is embedded in that outcome. If y'all are not improving someone's life, why are you delivering anything? That's the key message that we just have to keep coming back to. ==Why are we working on this if we don't know how it improves someone's life.== Whether agency, startup, b2b enterprise business—it always is the same. This is part of that influence, what it means to be a key stakeholder.
Q3
-
53:53 Do you have examples of "reverse engineering" this approach? For example, an outcome (purchase, exchange of value, etc) happens and you're able to connect the dots in reverse to improvements attributed to a design activity?
- Is this claiming the success of something to be from your effort?
- like, this activity/work is the thing the design team did that caused that life improvement of our customers, like in a way, doing a "Case Study" after the fact and reflecting back on what came out of a project and determing its success.
- Spool: When looking at a product, and use UX outcome idea to figure out if it predicts why that project succeeded or not. "Yes!"
- Can you think of a time when you downloaded a new version of a product and suddenly the product was worse, you would be able to tell me about that
- Felt like the "Usability faeries" came in and moved everything around and confused you - something was made worse
- The way you'd do this internally, is you'd look for places where suddenly you got this sudden burst in your internal business metrics or you didn't. Put out new release and it fell flat (outcomes just didn't exist or you didn't hit them). Or look at places where it surprises you about people coming in and joining the product, sudden sales or increase in downloads you didn't expect (how did we improve people's lives and we didn't even know we'd done it?)
- Suggestion: Look at today's work in progress and ask if we do a fantastic job on this (ask PMs, Devs, stakeholders) and see what comes back - see if you're in alignment, see if you get benefit - or do they say "i have no idea".
- If you're behind and you're frustrating people because of that, then table stake is great. The thing to point out when they say "this is just table stakes" - you say "sure, that's okay, we do need to hit table stakes". You have to hit table stakes in order to go beyond it. I think that his earlier statements in this webinar were making sure we are not just aiming at baseline. Once we hit table stakes, what is an improvement that inches us beyond that, even if just slightly? If you only aim for table stakes, you are forcing a commodity decision. You're saying then we have to be the lowest price, which reduces profit.
Q4
-
1:03:25 In an environment where backlogs are stuffed with outputs or maybe user stories, what should I do to shift everybody towards UX outcomes?
- I would look at each item on the roadmap, and I would talk explicitly about what, if we did a great job on this item, how would it improve someone's life. And just go through and catalog all of that. What is the outcome that we get for each item on the roadmap? And if we focus on that, what you'll see, there will be some things that people won't clearly have confidence around, they may not even know, and that's where an investment in research is really going to pay off. Because if you can go and understand the current experience that people are having which that thing is supposed to fix, you can come back and say "I know exactly what the outcomes are here" because we can clearly see where it is a difference in what users have today and what they could have. And that's where truly the real benefit comes down. So that's where you want to start.
- where would you write? Rename every item on the roadmap with its outcomes - if the roadmap item says "Data export" I would rewrite it to be—what's the actual improvement that people would get?—"Better reports to show their progress" Maybe the reason people want export is they need to import to Excel to create charts to show their manager that they're making progress in their work. It turns out that when someone says "What I really need is export" what they're really asking for is they need to create charts, but maybe you can create a dashboard that actually shows the improvement to their stakeholders without them having to do all that work.
- i.e. asking the user "What do you need?" and they say, THIS. you follow up with "Why?" and they say, THIS. And you ask a follow up, why do you need that? and they say, THIS? And why do you need that? and they say, THIS THING (which is the root issue you should consider addressing).
- If you do the research, you find out what the improvement is—maybe some people need UX Outcome of "make a safe backup of data", but maybe the scenario of actually "create dashboard to show progress" — the "Data Export" feature misses the root cause of why it is needed. Renaming is important for meaning and impact.