The very first step of designing a service/product is building empathy with all stakeholders standing at the ecosystem of the service to create a smooth experience.
One of the ways of having a common sense about customers and users is creating persona. Persona is a character which represent the customers/users or any stakeholder group included in the ecosystem of the service or product which is served. It should be highlighted that the process of understanding personas should be based on real ethnographic research rather than being invented out of some assumptions. Since first we should step into the persona’s life to understand their attitude, goals, expectations in order to bring them something really valuable and solve their real problems.
“People ignore design that ignores people.” — Frank Chimero
Why do we need Persona?
Personas enable us to forget about ourselves and see the world from their perspective, also step into their shoes. This situation helps us to understand expectations, motivations of this particular character. While designing the service/product, we benefit these information to understand their pains and problems that face through the current experience.
Having some insights about what users and customers need and expect shape our way to ideate realistic solutions which would really help them.
Before implementing the solutions we have designed, we could test it with the target to see if there is a gap in the new experience in order to fill the gaps.
User Persona vs Buyer Persona
The user and customer of a product/service would not be always the same person. In this case, it means that we should keep in mind all stakeholders while designing the service.
User persona is the end-user of the service but not necessarily the one who decide buying the service/product.
Buyer persona is the one who buy it but not necessarily use it. Customers would be influenced by other stakeholders and decision makers while making the decision. It is crucial to map all of these stakeholders and their effect with stakeholders map, ecosystem map, service blueprints etc.
Let’s think about an example which exemplifies a B2B accounting programme buying experience by a logistics company. In this example, the user will be the accountant who works for the company. Which means we can think of the accountant as the user persona for the product.
The general manager of the company will be the decision-maker who decide to buy the programme (or doesn’t buy) so that the general manager will be the buyer persona.
You would need to consider both your user persona and your buyer persona in developing the service/product.
For your user persona, accountant, would like to have a programme integrated with introduced legislation, and easy-to-use, user friendly interface while the buyer persona, general manager, would be persuaded by giving information about how the programme boost their operational improvement.
As you see, different types of personas would be at the core of the ecosystem. Furthermore, we need to understand their role in the context we are developing in order to meet their expectations.
Let’s see how to visualize stakeholder in a stakeholder map.
I would talk about showing the effects of stakeholders among each other on ecosystem map and placing different stakeholders’ actions for the same experience in a service blueprint in an another writing. If you are interested, you would share it on the comments.
To sum up, to always stay in the context and not to lose our way, we should always remember our personas’ motivations, background, expectations in order to deeply understand the problems and create new working ideas and experience to solve these problems.
