Whether you’re building a new system from the ground up or modernizing a legacy system, the mission is the same – create a holistic solution that delivers real value and impact to your client and their consumers. To an Agilest, the best way to do this is to staff a cross-functional team. Dedicated and skilled […]
Whether you’re building a new system from the ground up or modernizing a legacy system, the mission is the same – create a holistic solution that delivers real value and impact to your client and their consumers. To an Agilest, the best way to do this is to staff a cross-functional team. Dedicated and skilled product owners, developers, business analysts, User Experience (UX) and User Interface (UI) professionals, and ScrumMasters are crucial to ensure no stone is left unturned in the quest to deliver the best solution to the client. Unfortunately, a fully cross-functional team isn’t always feasible, specifically when it comes to UX.
Whether it’s budgetary, lack of understanding, or organizational roadblocks – many teams are forced to make due without UX resources. In these cases, the UX duties often fall to the business analysts. It’s an unfair position to put an analyst in, but as any analyst will tell you, to deliver an exceptional product, you must have a solid understanding of the problem you are trying to solve, and a thorough understanding of the end user. Therefore, it’s crucial that analysts staffed on a project without a UX team have a basic understanding of UX, and are equipped with tools to give a voice to the user.
Ensuring the team is solving the problem stakeholders have presented is paramount for business analysts. As part of the requirement gathering process, analysts must determine what will be best for the user. To know what is best for a user requires a deep understanding of the user themselves, and how they will use your product. You can build a beautiful desktop interface, but if only 5% of your users access your product on a desktop and 95% use a mobile application, your product will likely fail.
Empathy maps and personas are some of the best and simplest ways to bring the user to the forefront of the discussion when working on a development project. Both empathy maps and personas are used to bring a sense of realism to the problem the team is working to solve. As analysts know, the real challenge lies in finding the right solution for your audience. By researching the problem up front from the user’s perspective, you’ll have a much clearer picture of their frustrations and motivations, allowing you to have a better idea of what solution will work. It’s important to note that while empathy maps and personas take a very different approach to providing realism to the user and their needs, the commonality is that both are rooted in user research. In this post, we’re going to focus on empathy maps.
Empathy maps use questions centered around the five senses to form a representative user of your product. These are questions you pose to the empathy map creation team, which should include those who know your users best, and have answers based on the research you’ve done with real users. If you’re still in the research phase, you can often use a variation of these questions when conducting your research, but you’ll want to alter the language so it is more interview appropriate. Typically, empathy maps are divided into 4 quadrants: Think and Feel, See, Say and Do, and Hear. By asking thought provoking questions focused on these senses, you can start to piece together an average user. Good starter questions can include the following:
By asking questions about every aspect of your user’s experience, you can get a holistic representation of what they need and desire, and why. For instance, you may have an explanatory video tutorial on your site, but if your user works in a loud, busy environment, that may not be the ideal solution for them. You’ve technically solved the problem to provide a tutorial to the user, but the solution is not one that will work based on their environment.
Many empathy maps will also include two additional sections: Pain and Gain. These sections can be populated in a similar way as the senses-based questions above, but focused on pain points the user endures while using the product, and potential areas to gain delight using the product.
When it comes down to it, empathy maps center around asking questions – something that analysts are well versed in. By taking the next step and putting answers to those questions into a model that represents a user, it becomes easier to envision who you are building your product for, and glean insights about them that may otherwise go unnoticed. In our next segment, we’ll focus on personas, the value they bring to a project, and how they differ from empathy maps.
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...