(intense upbeat music) - Hi, my name's Jane Davis and I'm Head of UX Research and Content Design at a company called Zapier.
And I'm giving this talk because you are all slowly killing me.
That's not because you're addicted to Gantt charts or designs friends, although you definitely are addicted to those things.
And that's fine, it's important to have hobbies. It's actually because I've been watching product teams over the past eight years, full of smart talented people with good ideas, spend weeks or even months, failing to make progress on solving the problem they're trying to solve.
I know we can do better than that.
So today I'm going to talk to you about how. Over the last several years of my career, I've spent a lot of time helping product and design get on the same page.
And while I think I'm pretty hot stuff.
After several years of doing this, I've come to the conclusion that none of it requires my particular magical touch. Anyone can do this.
And that made me ask, why am I a researcher playing this role in the first place, and how can I teach other people to do it, so that I can do the parts of my job that do require my particular magical touch. So that's what I'm going to do in this talk, walk you through how to identify and resolve those misalignments between product and design, and give you a process for avoiding them.
So first off, why is this talk being given by a researcher? It's a great question and it's one that I've frequently asked myself when working with product and design teams.
What is it about my background as a researcher specifically, that's enabled me to align these functions and situations where they've struggled.
So after reflecting on it for some time and rejecting some of my initial hypotheses as being needlessly obstructive, I took a step back and started treating it like I would treat any research project. Because after all that is one of the things I do better than other people.
Pattern recognition.
So what patterns was I seeing over and over again? First I noticed the teams weren't explicitly stating what decisions they were trying to make.
The agenda was usually something vague like, decide how to proceed on experiment Y.
Second I noticed teams having the same conversation over and over again, they would meet, reach what they thought was an agreement, and then start all over again the next time they were together.
And third, I noticed that people were frequently using a specific solution to stand in for the general idea they were trying to convey. Kind of like saying we need to clean out the fridge, when the problem is actually that the kitchen smells bad. That might seem like a pointless distinction, but it actually becomes extremely important when you're trying to talk about the same problem space. So if you think about it, we need to clean out the fridge is one possible solution to the problem of the kitchen smelling bad. It might be the most logical solution.
The other solutions might be things like, let's buy a new house or let's throw away the fridge, but they are technically also solutions, otherwise known as tools.
So, in all of these situations, the teams were talking about things that were actually tools for solving a problem, rather than the problem itself. And that final observation, was what really unlocked this for me.
When you actually start to dig, the first two patterns I'd been noticing, were higher order functions of the third.
At the end of the day, nearly every struggle between product and design that I was working on, boiled down to this. The people involved were talking about tools, not goals. This can be hard to understand in the abstract, so I'll give an example.
A few months ago, I was rummaging around in our home workshop to find a drill so that I could put up new house numbers.
Now it was pretty clear that the drill is a tool, where people tend to get tripped up, is that the house numbers are also a tool, putting up new house numbers isn't an end goal, house numbers are a tool.
The goal here was to enable people to find our house when they needed to, whether that's because they're delivering a package or dropping off some books they borrowed, or at least pre-pandemic coming over for dinner. But because of the way I initially stated it and framed this discussion, where I was looking for something that was very literally a tool, it was easy to assume that putting up the house numbers was my end goal. As described, this doesn't seem like it could possibly create the kind of strife and deadlock that product teams can find themselves in.
After all isn't it the important thing that I got the house numbers up.
So to see why that's not the case, let's look at how this could translate to a product teams work.
So I have a background in growth, so a lot of the things that I give as examples are around driving activation and conversion and things like that, today's gonna be no different.
So let's imagine that you and your team are trying to get more users to activate during their first 30 days, you look at the analytics and you see that people who watch your formatted intro video all the way through, activate at twice the rate of other users.
So what do you do? You create a flow that's designed to get more people watching the video and tries to get them to stick with it, and then you sit back and you wait for your dazzling numbers.
Sub to your numbers, don't improve.
In fact, your activation rates starts tanking. And the team starts arguing about what changes you need to make to the experience.
You spend a weeks going back and forth on how to get people to watch the video all the way through.
And none of the things you try are working. The problem is, the videos that what's driving the activation rate.
If you dug into it, you'd discover that users who watch the video, and then activate all have the same use case, which happens to be the example use case the video walks them through.
But watching the video has gotten so conflated with activation in your team's mind that they aren't able to have the right conversation about it.
They need to be talking about what causes users to activate in the first place, how to drive it.
And instead they're bickering about things like auto-play, which no, and whether it's okay to prevent users from closing the modal.
It's not, user should always be able to close the modal. And because they're not having the right conversation in the first place, it will be impossible to identify a winning way forward, because all of this is just people arguing about their opinions.
No one's talking about the right outcome, the activation itself.
So to go back to our house numbers analogy, your team is stuck arguing about what colour the drill should be, instead of how to enable the delivery person to drop off your damn pizza.
The key to doing great work, on big problems as a team, is to have those right conversations in the first place. To do that, you need to establish a goal that's actually a goal, not just a higher order tool. Now, if we were doing this in person, this is where I would make an ill-advised attempt to getting you the audience to participate in a token way. And I then proceed to say whatever it was, I was already planning to say, regardless of how the audience participation segment went. Since we can't do that, instead we'll just have 10 seconds of awkward silence, while you imagine we're doing it.
And, then we'll all appreciate that there are some distinct advantages to a remote conference.
Great, so let's get back to it.
Given that higher order tools like the house numbers in our video, or the video in our example, aren't always obvious as tools, how can we identify them, so that we can have the right conversations and avoid getting deadlocked? First, we have to anchor on the outcome we're trying to drive, the real outcome.
So the first thing I do in any situation where teams are struggling, is ask them what measurable outcome they're trying to effect.
If they can't tell me that, then we've got a very clear reason for the struggle, which is that, there's no actual goal.
Unless you are trying to drive a measurable outcome, you don't have a shared goal.
But if you do have that metric or that measurable thing that you're trying to achieve, then we've got a starting point for the rest of the discussion.
That outcome, or that metric, that's our shared goal, and everything needs to come from that.
So unless we start by anchoring on that common thing, that we can measure, that we're all trying to achieve, we're not going to make any progress.
So the first thing I always do with a product team that's struggling to get along between product and design, is ask them what metrics they're trying to change with a given project.
And if they don't have an answer, then we know where we need to start, defining a metric, otherwise known as a shared outcome, otherwise known as a goal.
But metrics aren't enough.
So you need to translate your outcome, or your goal into your user's goal.
So you've got to establish that shared metric, but I'd be really disturbed if a user ever came to me and said, "Yeah I'm trying to activate, while they were giving feedback on an onboarding experience." One, it would tell me that I've got a ringer in my research panel, but two, that's not a user goal, users don't care about activating, users care about achieving their own ends. So at the end of the day, on the product side, we're using activation as a proxy for user being able to do what they're trying to do with our product. Activation is a really handy way to talk about that, it's a useful shorthand, but it can result in us being disconnected from what users are trying to do, and from what their goals are.
So to start making progress in the discussion once you, about ways you might drive your metric, I recommend going back to it and restating it in your user's words.
Your users don't wanna activate, they want to successfully use your product to do something specific.
Activation is how we measure the organization's work. But reframing it from the user perspective, can get you out of a deadlock by reminding you of what you're trying to do. Enable your users to engage in a specific behaviour, or to accomplish something specific.
So you've gotta translate your outcomes and your metrics into what your users are actually trying to do. And third once you've rerouted yourselves in this shared metric, and what it looks like for your users, you've gotta start asking why a given idea might or might not help them achieve that goal.
This one is so important that I added an annoying keynote animation so that you will really, really remember it. So this step looks like asking why instead of what. In our activation example, the question isn't, what are users who are more likely to activate doing? Because we just get the answer watching this video. The question we should be asking is, why does that help a user successfully start using our product? So every piece of information we're digging for here is about how a tool like our video contributes to our ultimate goal of increasing activation, which is our proxy of course, for user success. So here's what this process might look like in our video example.
So one, we ask, why are users who watch this video more likely to activate? The answer to that could turn out to be, they got information from this, that they couldn't find anywhere else.
Okay, but that information is also just a tool. So why does that information make them more likely to activate? Well, we could ask them and it would turn out that tells them how to do something specific with our product.
Okay, but knowing how to do something specific with our product still isn't actually a goal. They want to do this specific thing.
So why does doing something specific with a project, make them more likely to activate.
Because that was their job to be done.
That's why they signed up for our product in the first place.
And so in our hypothetical here, at the end of this process, you've uncovered the real reason, the video is driving activation.
Because for a subset of your users, it's showing them how to do exactly what they came to your product to do.
And you've also got a reasonable hypothesis, for why driving more people to the video, isn't driving more activation.
Because those people don't have that specific use case. So the video isn't relevant to them.
So now you know what might actually drive activation, helping users find and get started with their specific use case.
You've established your goal, and now you and your team can start talking about the different tools you might use to achieve it. So that was a lot.
Let's go back and recap on our handy recap slide. So first, start from the ultimate outcome, as defined by your metrics.
You have to start your discussion by agreeing on the goal you're trying to get to as a team. Next, define what that outcome looks like from your user's perspective.
So how does your goal translate into user behaviour? And third, go beyond what users do, focus on why they do it, and how it helps them achieve their goal.
So there you have it.
The secret magical way, you can stop driving your friendly neighbourhood researcher around the bend. Now go fourth and set goals, not tools.
(upbeat music)
