Implementing Personas into your Workflow
How to make personas count in a multidisciplinary digital team
In order to stick to a human centered design approach, personas are created as a tool to relate to users. They are a representation of a user in an archetypical profile and reflect the relevant behaviors, goals, challenges and motivations of the user in relation to the product you’re designing. Unfortunately, in many teams personas are forgotten about too fast, because they simply don’t have a place in the day to day work rhythm.
Educate stakeholders and team members on their value
Before you get to the point that personas could potentially influence the way we do our jobs, you often have to advocate for them to have a voice. Making colleagues or stakeholders see the value in the use of personas can be challenging, especially if at the end of the day quantitative data is what drives decisions. Keep in mind that the benefits exceed the hassle of rooting for them.
Why root for them
- Creating personas is an opportunity to summarize your research findings in a way that is digestible for team members and stakeholders
Keep them short, relevant and make them guide requirement definitions - Empathizing with an actual ‘person’ is easier than with a number
Make a persona specific, generalized profiles don’t answer specific user needs - They help to keep the focus of design on the needs of real users
Happy users = good business
Make them easy and accessible
How personas will actually be used in a workflow depends a lot on how you implement them within the team structure. No one will refer back to that deck buried somewhere in the team Dropbox folder. You have to figure out the best way for the team to become accustomed to them. Obviously how to achieve that is highly dependent on the team culture and way of working.
An example from a multidisciplinary digital team
The past months I was part of a project that focused on exploring the digital future of how EF Education First communicates and sells their language courses abroad. Our team was a mix of UX and UI designers, developers, a product owner and a creative director acting as a stakeholder. Even though the research and interviews with customers and local sales coordinators had been conducted, there was no translation of this research that helped inform the team in an easy and accessible way in their day to day work.
I dug into the research and created a set of personas consisting of both customers that are children and parents, and of EF sales coordinators that interact with the customers. All personas have their own alias, color code and a summarized breakdown of their goals, challenges and key motivators to buy the product. I printed out small driver’s license sized cards of them and handed them out to each person on the team.
Attempting to force them into the workflow I brought in the cards in every conversation we had regarding the design of the website and started asking questions about how persona X would react in such situation, or how persona Y would respond to a specific tone of voice. This not only helped navigating the conversation more towards user needs, but also helped eliminate subjective opinions regarding design decisions.
Using persona needs as component prioritization
One layer deeper, as a team we conducted a card sorting exercise in which we validated the website structure by creating again it from scratch, with the persona hats/ mindsets on. The result of doing this was an information architecture made out of components that were all in a specific order because they were answering the persona needs.
Trying to move this forward, we struggled with prioritizing the components. A given was that we had to focus on the most important things on the website that make it functional. After that it was hard to give tangible value to different components or pages. We solved this by looking at different phases a customer goes through before buying the product. The three main phases are being inspired, being informed and being ensured of quality and safety. All of the personas were given a set of icons representing the different phases.
Each component on the website structure that we created in the exercise was given the relating persona/phase icon labels. This established a clear overview of which components or aspects of the website to prioritize. For instance, a mini city guide of a destination for a trip had less priority than an academics section of a school. Why? A city guide helps inspire a 16-year-old to travel somewhere, but if at the end of the day the parents is making the calls, it’s more important that we cover the quality phase for the parent persona. Seems pretty obvious right?
This mapping exercise brought focus to our roadmap, eliminated unnecessary discussions along the road and gave us something to fall back on when things were questioned.
Using personas in sales and marketing
Another example of how personas can be useful product-wide comes from Ngaire Wex, UX/UI designer at EF Academy. She’s been able to prove that personas are not only relevant in design teams, but that they can be used much more broadly, such as for sales teams onboarding new colleagues or in a global context building more empathy for diverse customer needs.
“Documenting our dispersed customer knowledge and distilling into personas has been very useful in a global context. It keeps our range of customer needs top of mind and easily accessible for our global team.” — Ngaire Wex
The right fit for the right team
Try experimenting with different ways to encourage your colleagues to adopt personas. Take their work and deadlines into consideration and make sure your solution is an easy and accessible one. Remind people and ask for feedback, is something you’re trying not working? Open the dialogue and discuss how you can improve. Remind people why you’re doing this and how their work benefits from it. And finally, keep the personas alive — your users and their needs are always evolving.
Credits to Ngaire Wex for her take on personas at EF Academy.
