In my Product Design course one of the things that I emphasize the most is how to turn design into value for the business. And we go through different tools to do that.
One of them is the “Insights Template”, that I created working with product and design teams to help them quickly identify and convert insights into value for the product.
I created this template because I observed three recurring problems in the way designers and product people related to user insights:
- Insights were mere observations, in the form of “the sky is blue”. That is, observations that had the potential to become value generators were abandoned mid sentence. What does it mean that the sky is blue? Does it mean that we can do outdoor activities? Does it mean that we don’t need to carry umbrellas? Do we need to bring sunscreen? In other words, what do I do with this information? What does it mean for my business?
- Observations were just design input (make X more visible, review flow X). But as I always say, every pixel on the screen needs to contribute to support user needs and product success. So we need to understand how our design decisions impact the product and the business.
- Sometimes anecdotal comments were turned into insights. So asking “how does that impact the product” helps separate true insights from just interesting comments.
An example
A while ago I was working with a team in the development of a time tracking app. One of the observations we got from the user interviews was related to the frequency of use. Some users would enter their hours daily at the end of the day, while others would do it at the end of the week. So the team’s initial interpretation was “how do we make users fill in their hours daily”.
But that was solving the wrong problem, because not all users needed to load their hours daily. Those with a daily frequency were the ones with multiple projects or tasks, while the ones assigned to a single project or with recurrent tasks like “develop back-end for project X” would fill it at the end of the week since they did the same all week.
The team was able to identify the right problem when I asked them “what is the problem with loading the hours once per week?”. The answer was that the hours loaded ended up being dirty data because users would fill the hours from memory and sometimes they forgot to record additional tasks.
And that was a business problem because the hours entered in the app were used to make sales estimates and if data was misleading there was the risk of under-estimating hours and that would impact future income.
So by asking that simple question we were able to identify that the real problem was “how do we make sure data is clean”.
How to use the template
What happened: here the idea is to describe the fact without analysis or evaluation. For instance “users need to know when they Will be receiving their order”, or “users uninstall the app because is slow”. It is also important to identify the source of the observation in case more context or information is needed.
What does it mean: just like in the above example, we need to identify what is the consequence for the product and the business. If we don’t find any then we know it is just anecdotal information.
What can we do: descripiton of the proposed idea/s to solve the problem.
Expected benefit: here we need to define what is the expected outcome both in terms of user/product goals and metrics so we can track whether we achieved our goals.
The idea behind this template is to help synthesize and systematize qualitative analysis in order to turn insights into value for the product and the business.
If you use the template, I’d love to hear your experience.
In my Product Design course one of the things that I emphasize the most is how to turn design into value for the business. And we go through different tools to do that.
One of them is the “Insights Template”, that I created working with product and design teams to help them quickly identify and convert insights into value for the product.
I created this template because I observed three recurring problems in the way designers and product people related to user insights:
- Insights were mere observations, in the form of “the sky is blue”. That is, observations that had the potential to become value generators were abandoned mid sentence. What does it mean that the sky is blue? Does it mean that we can do outdoor activities? Does it mean that we don’t need to carry umbrellas? Do we need to bring sunscreen? In other words, what do I do with this information? What does it mean for my business?
- Observations were just design input (make X more visible, review flow X). But as I always say, every pixel on the screen needs to contribute to support user needs and product success. So we need to understand how our design decisions impact the product and the business.
- Sometimes anecdotal comments were turned into insights. So asking “how does that impact the product” helps separate true insights from just interesting comments.
An example
A while ago I was working with a team in the development of a time tracking app. One of the observations we got from the user interviews was related to the frequency of use. Some users would enter their hours daily at the end of the day, while others would do it at the end of the week. So the team’s initial interpretation was “how do we make users fill in their hours daily”.
But that was solving the wrong problem, because not all users needed to load their hours daily. Those with a daily frequency were the ones with multiple projects or tasks, while the ones assigned to a single project or with recurrent tasks like “develop back-end for project X” would fill it at the end of the week since they did the same all week.
The team was able to identify the right problem when I asked them “what is the problem with loading the hours once per week?”. The answer was that the hours loaded ended up being dirty data because users would fill the hours from memory and sometimes they forgot to record additional tasks.
And that was a business problem because the hours entered in the app were used to make sales estimates and if data was misleading there was the risk of under-estimating hours and that would impact future income.
So by asking that simple question we were able to identify that the real problem was “how do we make sure data is clean”.
How to use the template
What happened: here the idea is to describe the fact without analysis or evaluation. For instance “users need to know when they Will be receiving their order”, or “users uninstall the app because is slow”. It is also important to identify the source of the observation in case more context or information is needed.
What does it mean: just like in the above example, we need to identify what is the consequence for the product and the business. If we don’t find any then we know it is just anecdotal information.
What can we do: descripiton of the proposed idea/s to solve the problem.
Expected benefit: here we need to define what is the expected outcome both in terms of user/product goals and metrics so we can track whether we achieved our goals.
The idea behind this template is to help synthesize and systematize qualitative analysis in order to turn insights into value for the product and the business.
If you use the template, I’d love to hear your experience.
