In Part 1 of UX Tools for the Business Analyst, we discussed the importance of understanding the end user, and examined how empathy maps are one approach to doing so. By asking sensory focused questions, you can gain valuable insight into your users, and their needs and frustrations. Personas are another way to bring the […]
In Part 1 of UX Tools for the Business Analyst, we discussed the importance of understanding the end user, and examined how empathy maps are one approach to doing so. By asking sensory focused questions, you can gain valuable insight into your users, and their needs and frustrations. Personas are another way to bring the voice of the user to the forefront of a project, but they take a different approach than empathy maps.
Personas are fictional profiles created based on characteristics of your target user. While empathy maps use the five senses to create a representative user, personas don’t limit the scope to just the senses. As such, persona creation focuses on demographics, environment information (physical, social, and technological), and motivations.
Building a persona involves creating a fictional person that is a representation of your user, so you’ll want to name your persona, give them an age, hometown, and any other details that will help provide realism. An appropriate backstory (again, rooted in research) is necessary to understand your user’s motivations and frustrations which can include why they use your product, how long they’ve been using it, and what they like and dislike about the product. Similar to an empathy map, here you are gathering information about the traits and habits of your user. When appropriate, you can also add more details such as quotes that embody what’s important to them, familiar brands they trust, and other factors that are influential and relevant to how they will interact and perceive your product. For instance, if their technological proficiency is low and you are building a mobile application, will they understand how to use a hamburger menu? Perhaps not. Relevant details like that will vary from project to project, but it’s those little insights that make a persona come alive and provide real value when it comes to understanding your user.
One of the best things about personas is that even a quick and dirty persona can bring enormous value to a project. They can be extremely intricate with graphs, logos and a few paragraphs, or at its simplest, a quadrant with bulleted list items. The value lies in the information imparted, not how it looks; even a small amount of information can be useful when designing a solution. As you discover more about your users through interviews and testing, you should update and add to your persona so it is always an accurate representation of your user.
Although these two methods have very distinct approaches, the end result is the same – a strong picture of who your users are. If you don’t have any research available, create a persona based on knowledge from those who should know your user best – your stakeholders. If you’re forced to go this route, the key is to validate these assumptions. This path isn’t a substitution for user research, it’s just a stopgap until you have the time and resources to do research. Regardless of which method you choose, your persona or empathy map should be reevaluated during the design process as you discover more about your users through research and testing, and updated as necessary.
A solid empathy map or persona is the first step in giving the user a voice during the design and development of a product. These tools are rooted in research that every member of the team can reference and understand throughout the design, development, and testing process. As any analyst knows, at each point in the project life cycle, it is important to check and make sure the work you are doing makes sense. You can’t effectively answer the question “why are we doing this?” without having a comprehensive understanding of who you are doing it for. In the next installment, we’ll discuss Journey Maps and how to use them to shed light on where your user is experiencing frustration, and how to spot opportunities to add delight and ease to their experience.
Getting Agile requirements right can be a challenge but it’s essential as they can make...
Scaling, like Agile itself, can become a target objective rather than the means to an...