Transforming research insights into impactful design decisions is a
must-have skill for any designer or product manager. By employing a
systematic approach called synthesis, you can effectively translate
evidence gathered from various sources, such as heat maps, analytics,
and customer interviews, into concrete actions that drive product
improvement. In this lesson, we'll explore the synthesis process and how
it works hand-in-hand with prioritization to ensure your design
decisions are data-driven and aligned with business objectives.
Once you've performed research, how do you turn that into design decisions? Through a process called synthesis. So synthesis is essentially how you take all of the things that you're doing to gather evidence, heat maps, analytics, customer interviews, and turn them into things that you can actually do for the product. I try to create a systematic approach to synthesis so that we can apply that consistently, no matter what the research happens to be. And that allows research to challenge us meaningfully.
Research should challenge us, right? But also the way in which that we turn research into design is kind of magical. Like there's this cartoon that I like that basically has two scientists looking at a chalkboard and in the middle of all these equations It says, and then a miracle occurs. And that kind of is what it is. It's sort of a blend of common sense and evidence gathering that allows us to actually move forward with clarity and expertise.
Synthesis is a multi-step process that's pretty easy. First, you identify a problem. So you're looking at the research, and you say, hey, that's not actually working well for us. Now, that can be you have a primary metric, and it's causing people to not convert. It can be you want people to behave in a certain way, and they're not behaving in that way.
Well, that might be surprising or challenging to you. Either way, it might be a problem. The next is you want to know why that problem is actually happening. So you might need to research more as to the cause. Sometimes you need to confirm with analytics.
Sometimes you need to confirm by actually talking to people. But if you're not really certain on what the overall solution is, then you need to go back and confirm it with some more research. Dive into that problem. Follow that hunch. Follow that small voice.
This is intuition, and then this is where your intellect kicks in. Once you've got a really good guess as to what the overall solution is, then you move into refinement, creating a prototype, creating specificity around what the actual design decision is. So let's say people are not responding to what our brand is, and they're bouncing at a high rate from the home page. So that's an analytics thing. Now, you might want to confirm that by talking with customers and understanding how they actually understood what the value of your product was And if it's not coming through say your home page or your immediate pitch, then you have a problem on your hands, right?
So the solution could be in that case updating your headline so it actually reflects what the customer is reflecting back to you. Seems reasonable. Now, what do you actually change that thing to? Well, you figure out what the copy is. You might steal a quote from a customer interview or something like that.
So again, intuition. This isn't working really well. This isn't working well in this particular way guessing the solution is if we do this the problem might go away and then we need to do it in a specific way right so for example this is a heat map that was furnished to me by one of my clients. There's one thing that I notice here that's really, really interesting. Nobody's really interacting with the navigation.
Like, the search field is lit up really heavily, and they sell commercial playground equipment. So probably people are going in, and they have a clear sense of what they actually want to be buying. So, alright, that seems a little bit weird. Is there a higher conversion rate from navigation versus from search? And we turned out that once people went to navigation, they actually converted at a higher rate.
Or when they go to collection pages from these primary calls to action, they were getting pretty good results. So what we ended up doing was rework the navigation and came up with a given solution around all of it. We were confirming heatmaps with analytics, and then we were using that to change the overall layout of the navigation to reflect what people were putting together in their search queries. As a result, bounce rate decreased, conversion rate increased, quote rate increased. Big, big wins for the business.
Now, you do this over and over and over again, no matter what kind of problems you see. And that could be all over the place on a given site. You never really know what is going to work and where and in what capacity. And so how do you take all of the different design decisions? Because you're not just doing this once, right?
You're not just running synthesis once and actually trying to figure things out. You run synthesis over and over and over again for many, many different problems. And you keep following many, many different hunches. Because the more you do this, the more research you gather, and the more you synthesize all of that into design decisions, the more bets you're placing that probably those will meaningfully move the needle for the business. So how do you make sense of all of that?
It's through a process called prioritization. So you're taking all these different design decisions, and you're not using your own ego or your own agenda to follow them, but what you believe the actual impact might actually provide for the business. So there are many different prioritization methods that exist throughout the industry. One of them is called PI, so you rate things based on their potential, their importance, and their ease. Another one is called ICE, Impact, confidence, ease.
I kind of view potential and impact to be kind of similar. These are similar frameworks. There's PXL, which is what Conversion XL uses. And it's like 20 different metrics and really, really complicated. But if you're in more of an enterprise place, you could do that.
There's our methodology, which we'll be talking about today, because that's the one that I know the best. And we go by three different metrics. The first is feasibility. So that could be, I guess, confidence. But really, it's in a more rigorous development technical side of things.
So if you're overhauling the entire site, then you're probably going to put the feasibility at a 1 out of 10. So we grade all three of these metrics out of 10. We're going to go through three metrics and figure it out. Feasibility, How hard is it to put together if it is you know? I change a headline on the front page.
That's a 10 out of 10 That's super super easy if it's we rework the whole thing it might be 1 out of 10 I like co-creating these feasibility metrics alongside developers most of the time But ultimately the more experience that you have doing this, the easier it's going to be for you to be doing. Then impact. What is the potential impact of the design decision? If it's happening, and I have a whole set of metrics around all of this on draft site, but if the thing is happening above the fold on a load-bearing element that has direct connection to conversion funnels, yeah, it's going to be a pretty high impact. If I'm changing something tiny in the footer, it's probably going to be an impact of one.
And then the last is alignment with business strategy. So that means that your business needs a strategy, and you need to end up making sure that the decisions that you're making are actually in alignment with how the business operates and how we might want to make customers happy. And so if something is like a very hell yes for the business, we definitely want to make customers happy in this particular way, rated a 10. If it's massively challenging for the business and doesn't really feel like the kind of thing that is like the way that you want to be doing things, then it might be a 1. For one-off fixes, we do something a little bit different than alignment with business strategy, which is we want to make sure those fixes fit with the existing context on the interface.
So we write this instead. So this is for experiments, and then this is for one-off fixes. And if something fits exactly with the context, like you're fixing a bug or something like that, it's probably a 10. If it would result in a significant redesign or rethink of the way that things operate, then it would probably be a bit lower score. You add all of these up, and then you post them to a project management board like Trello or Asana or whatever you use to try and figure things out.
So with clear sources of truth, you want to create places where all of these scores are actually posted so other people will have access to these boards and then they'll understand what design decisions need to be pursued and what ways. You sort scores from 30 to 3 in descending order, and you just start building. This keeps people from duplicating work. It keeps QA processes relatively consistent and reasonable. And it keeps people from following arbitrary agendas or going through power struggles that might actually harm the quality of work or executional velocity for the team.
It allows you to ask hard questions in a really deep way around why we're doing things in the way that we're doing things and helps you bust norms around a lot of things that might be kind of deviant practices. So it is, I will note, kind of a way of leveraging your own power in the organization, too. Because the person who does the prioritization is ultimately going to have power over these sorts of design decisions. And so knowing that that's happening is really, really useful for understanding how things are operating. So I'll provide a separate list of questions that you need to ask to how to calculate these scores in a separate worksheet, but that's overall what people need to be doing to actually prioritize these design decisions after synthesizing them.
Once you've performed research, how do you turn that into design decisions? Through a process called synthesis. So synthesis is essentially how you take all of the things that you're doing to gather evidence, heat maps, analytics, customer interviews, and turn them into things that you can actually do for the product. I try to create a systematic approach to synthesis so that we can apply that consistently, no matter what the research happens to be. And that allows research to challenge us meaningfully.
Research should challenge us, right? But also the way in which that we turn research into design is kind of magical. Like there's this cartoon that I like that basically has two scientists looking at a chalkboard and in the middle of all these equations It says, and then a miracle occurs. And that kind of is what it is. It's sort of a blend of common sense and evidence gathering that allows us to actually move forward with clarity and expertise.
Synthesis is a multi-step process that's pretty easy. First, you identify a problem. So you're looking at the research, and you say, hey, that's not actually working well for us. Now, that can be you have a primary metric, and it's causing people to not convert. It can be you want people to behave in a certain way, and they're not behaving in that way.
Well, that might be surprising or challenging to you. Either way, it might be a problem. The next is you want to know why that problem is actually happening. So you might need to research more as to the cause. Sometimes you need to confirm with analytics.
Sometimes you need to confirm by actually talking to people. But if you're not really certain on what the overall solution is, then you need to go back and confirm it with some more research. Dive into that problem. Follow that hunch. Follow that small voice.
This is intuition, and then this is where your intellect kicks in. Once you've got a really good guess as to what the overall solution is, then you move into refinement, creating a prototype, creating specificity around what the actual design decision is. So let's say people are not responding to what our brand is, and they're bouncing at a high rate from the home page. So that's an analytics thing. Now, you might want to confirm that by talking with customers and understanding how they actually understood what the value of your product was And if it's not coming through say your home page or your immediate pitch, then you have a problem on your hands, right?
So the solution could be in that case updating your headline so it actually reflects what the customer is reflecting back to you. Seems reasonable. Now, what do you actually change that thing to? Well, you figure out what the copy is. You might steal a quote from a customer interview or something like that.
So again, intuition. This isn't working really well. This isn't working well in this particular way guessing the solution is if we do this the problem might go away and then we need to do it in a specific way right so for example this is a heat map that was furnished to me by one of my clients. There's one thing that I notice here that's really, really interesting. Nobody's really interacting with the navigation.
Like, the search field is lit up really heavily, and they sell commercial playground equipment. So probably people are going in, and they have a clear sense of what they actually want to be buying. So, alright, that seems a little bit weird. Is there a higher conversion rate from navigation versus from search? And we turned out that once people went to navigation, they actually converted at a higher rate.
Or when they go to collection pages from these primary calls to action, they were getting pretty good results. So what we ended up doing was rework the navigation and came up with a given solution around all of it. We were confirming heatmaps with analytics, and then we were using that to change the overall layout of the navigation to reflect what people were putting together in their search queries. As a result, bounce rate decreased, conversion rate increased, quote rate increased. Big, big wins for the business.
Now, you do this over and over and over again, no matter what kind of problems you see. And that could be all over the place on a given site. You never really know what is going to work and where and in what capacity. And so how do you take all of the different design decisions? Because you're not just doing this once, right?
You're not just running synthesis once and actually trying to figure things out. You run synthesis over and over and over again for many, many different problems. And you keep following many, many different hunches. Because the more you do this, the more research you gather, and the more you synthesize all of that into design decisions, the more bets you're placing that probably those will meaningfully move the needle for the business. So how do you make sense of all of that?
It's through a process called prioritization. So you're taking all these different design decisions, and you're not using your own ego or your own agenda to follow them, but what you believe the actual impact might actually provide for the business. So there are many different prioritization methods that exist throughout the industry. One of them is called PI, so you rate things based on their potential, their importance, and their ease. Another one is called ICE, Impact, confidence, ease.
I kind of view potential and impact to be kind of similar. These are similar frameworks. There's PXL, which is what Conversion XL uses. And it's like 20 different metrics and really, really complicated. But if you're in more of an enterprise place, you could do that.
There's our methodology, which we'll be talking about today, because that's the one that I know the best. And we go by three different metrics. The first is feasibility. So that could be, I guess, confidence. But really, it's in a more rigorous development technical side of things.
So if you're overhauling the entire site, then you're probably going to put the feasibility at a 1 out of 10. So we grade all three of these metrics out of 10. We're going to go through three metrics and figure it out. Feasibility, How hard is it to put together if it is you know? I change a headline on the front page.
That's a 10 out of 10 That's super super easy if it's we rework the whole thing it might be 1 out of 10 I like co-creating these feasibility metrics alongside developers most of the time But ultimately the more experience that you have doing this, the easier it's going to be for you to be doing. Then impact. What is the potential impact of the design decision? If it's happening, and I have a whole set of metrics around all of this on draft site, but if the thing is happening above the fold on a load-bearing element that has direct connection to conversion funnels, yeah, it's going to be a pretty high impact. If I'm changing something tiny in the footer, it's probably going to be an impact of one.
And then the last is alignment with business strategy. So that means that your business needs a strategy, and you need to end up making sure that the decisions that you're making are actually in alignment with how the business operates and how we might want to make customers happy. And so if something is like a very hell yes for the business, we definitely want to make customers happy in this particular way, rated a 10. If it's massively challenging for the business and doesn't really feel like the kind of thing that is like the way that you want to be doing things, then it might be a 1. For one-off fixes, we do something a little bit different than alignment with business strategy, which is we want to make sure those fixes fit with the existing context on the interface.
So we write this instead. So this is for experiments, and then this is for one-off fixes. And if something fits exactly with the context, like you're fixing a bug or something like that, it's probably a 10. If it would result in a significant redesign or rethink of the way that things operate, then it would probably be a bit lower score. You add all of these up, and then you post them to a project management board like Trello or Asana or whatever you use to try and figure things out.
So with clear sources of truth, you want to create places where all of these scores are actually posted so other people will have access to these boards and then they'll understand what design decisions need to be pursued and what ways. You sort scores from 30 to 3 in descending order, and you just start building. This keeps people from duplicating work. It keeps QA processes relatively consistent and reasonable. And it keeps people from following arbitrary agendas or going through power struggles that might actually harm the quality of work or executional velocity for the team.
It allows you to ask hard questions in a really deep way around why we're doing things in the way that we're doing things and helps you bust norms around a lot of things that might be kind of deviant practices. So it is, I will note, kind of a way of leveraging your own power in the organization, too. Because the person who does the prioritization is ultimately going to have power over these sorts of design decisions. And so knowing that that's happening is really, really useful for understanding how things are operating. So I'll provide a separate list of questions that you need to ask to how to calculate these scores in a separate worksheet, but that's overall what people need to be doing to actually prioritize these design decisions after synthesizing them.
Nick Disabato