A run down of the Fearsome tool for taking your customer conversations and using them to drive product strategy.
Stakeholder interviews and empathic exploration are examples of useful, front-end research tools, used to help better our understanding of a client's market. The outcome of these activities should be some useful soundbites, capturing the motivations, frustrations and behaviours of the people. Having elicited this vital information, how does that become a thing?
One of the most useful tools we have developed for this is something we call Benefit Mapping.
Formed through our research in the initial phases of a project, and continually refined as the project progresses, the benefit map is a central point of reference for development work. In a sense it acts as a conscience for the project: faithfully reminding us of the valuable input we have received from stakeholders and ensuring that these soundbites are not lost in the everyday mishmash of trying to create a functional product.
But where the benefit map really comes into its own is in taking these emotive - sometimes fairly qualitative - bits of information and translating them into practical design goals. These are objective goals that will eventually form the basis for design requirements that can be verified through prototype testing.
In this way, the benefit map helps form a bridge between our front-end research and the outcomes of our design work: between the emotive needs of people and the specific functionality that will enable those needs to be met.
Marketable benefits - those things that make a product sell - can be determined earlier on in a project. Rather than designing a product, then asking our client's marketing department to create a story around it, we collaboratively understand what the story needs to be, and develop a product to enable this.
How does benefit mapping work?
The Big idea The big idea is essentially a vision for the project. For example: "the smoothest car ride in the world" or "the best surgical lighting available". The statement is usually aspirational and can take the form of a marketing headline. In this way, the design is tied into the marketing story from an early point in the project. We can form an initial big idea at the beginning of our development work, but it tends to evolve as the project comes together and our understanding grows.
Stakeholders A stakeholder is anyone who stands to gain from the realisation of the big idea. The primary stakeholders are usually end users, but we also have to think about everyone else involved in the product life cycle: Distributors, buyers, and our clients themselves are often in the stakeholder mix.
Benefits At this level we're talking about higher level objectives that will eventually form part of the marketing story. If we can achieve these benefits, then we have achieved the big idea. They describe the change that our stakeholders want to see and they are formed through our front-end research. They might be stated as single words, or simple phrases such as "better sleep" or "reduced waiting times".
Design Goals The design goals are practical objectives we need to meet in order to enable the benefits. Figuring out what they are usually requires some further thinking and potentially further exploration. Some of the design goals may start out life as fairly general statements. But, as the project progresses, they should become more clearly defined and eventually worked into a set of formal design requirements. Some of these will have defined, measurable targets. For example "turns 360° in both directions" or "can take 10kg of load". Our design goals can also be enhanced through competitor analysis, giving us benchmarks from competing products that our new product will need to improved upon. Our map shows how the primary design goals trickle down from the main benefits for different stakeholders. As we've shown in this example, it's helpful to highlight the goals that are at the end of this 'cause and effect' chain, as these are the ones that the project will need to target. It's common in benefit maps to have multiple layers of benefits and 'design goals. Often the line between these two layers is blurred and we often ask ourselves the question: "Is this a benefit or a design goal?". And we often find that the answer is "both".
Comments