Stakeholder Maps, Interviews & Personas
So, how do we develop this deep understanding of the human aspects of our project, including the context in which our product, service, or solution will be used? Ideally you would integrate stakeholders directly into your development team, a perfectly viable approach that is often dismissed as too unwieldy. Three other practical tools to keep stakeholder needs top-‐of-‐mind, and that are tremendously powerful, are stakeholder analysis maps, stakeholder interviews, and personas.
Doing a stakeholder analysis is fairly common in projects, and you can get a detailed template for this from ProjectConnections here. I work mainly with teams of people from many different countries, and our only common language is “Globish” combined with a whole lot of body language, so I prefer to use a more visual approach -‐ a stakeholder map. Here’s a picture of a gigantic one that a team of a dozen people from four different countries created at a project kickoff that I facilitated recently. Working with a huge piece of paper and sticky notes like this enables “non-‐ verbal negotiation” as team members co-‐create the map and draw the relationships among various stakeholders. Even when everyone shares the same language, this gargantuan technique assures that quieter people can comfortably participate and contribute.
Interviewing real stakeholders, and doing so in the environment in which your product or service will be used, is essential to developing a deep understanding of their real situation, wants, and needs. The tool shown here is an empathy map, and is a useful guide to conducting and interpreting these interviews. Notice that you need to go beyond asking leading questions and observing explicit actions to exploring what people are thinking and feeling. This is what makes design thinking “empathetic” rather than merely “customer-‐centric”.
Your pile of interview notes will be quickly forgotten, so capture the essence of each key stakeholder in a persona that can be remembered and referred to throughout the project. A persona is a fictional character that posesses the attributes of the stakeholder it represents. Those of you using Agile will recognize this as a tool used in that methodology as well, but actually personas are purported to have been first introduced to the design world by Alan Cooper, author of the amusingly titled book “The Inmates Are Running the Asylum”. Below is an example of a basic one.
Base personas on real stakeholders! Although people sometimes create them based purely on their imaginations, these are often highly exaggerated fictional characters, and not very useful in guiding teams to delighting real stakeholders. In order to be useful in the development process your personas must reflect the relevant characteristics of the groups of people for whom they are a proxy. The most useful ones are developed based on interviews and observations of real people representative of your stakeholder group. Granted, sometimes you won’t be able to get hold of a representative from a particular group (if they’re infants, for example, or people who will be alive in the future), but usually you can dig up someone relevant to interview.
Walk in the Customer’s Shoes
A user experience map, also called a customer journey map, can help you visualize the current situation and the entire lifecycle of how a stakeholder would encounter and experience your product or service. Creating this kind of map together greatly increases team members’ shared understanding of your project goals. These maps can run the gamut from simple to mind-bogglingly complex. Here’s an example of a perfectly useful map following the incredibly complex process of discovering and managing a complicated health condition.
This map, in contrast, makes me wonder how I ever managed to purchase a cell phone!
The purpose of these maps in Scrappy Design Thinking® is to identify areas of opportunity for your product or service, and provide a customer-‐centered context within which to innovate. Be scrappy! You don’t have to go into excruciating detail. Follow the scrappy credo of “Just enough detail. Not a drop more and not a drop less than necessary to optimize results.”