Agile sprint processes have generally been put into practice for many businesses to help manage and ensure productivity for development teams. The philosophy is generally to release an output quickly and then iterate based on product usage. With the fast-paced sprint nature of Agile, stakeholders are compelled to value assumption, intuition, and output over research-led activities.
Preface
Some organizations have even moved away from centralized and allocated research teams and resources. Product teams have been hesitant to engage with research teams in organizations that still have them, because they've experienced time delays and labor-intensive processes. Because of this, product teams now expect designers to be equipped with the skills to carry out research activities for their projects. Individual designers are now tasked to acquire the necessary analysis for their project on their own.
Mission
To deliver research value, counter the negative connotations and stereotypes. Implementing these research strategies into your agile process will help you gain your team's trust for research.
Here are 5 negative connotations on why research has been relinquished:
1. It takes too long or is expensive.
Stakeholders may had experiences in previous companies or previous projects with elongated research activities that required a lot of time. resources, and was labor-intensive. There have been cases when research took too long, leading to no momentum and taking its final resting place into oblivion. When the data comes too late and doesn't align with product release dates, it gets ignored, resented, shelved, and never resurfaced. The thinking and focus gets lost, and stakeholders feel it was was waste of effort.
What to do
Provide quick-hit research data on your own, that can be achieved within days of your sprint, helping to inform your design. Ensure an insight is attainable, that you do it on your own with no dependencies, and that it directly influences your design decisions. Prove it can be done quickly, swiftly, with ease, and ensure there is correlation from your findings to your design outputs.
2. Moderated testing is unnatural and skewed.
What users do is different from what they say they do. Research data may be skewed since users answer questions where you give them time to think, causing unnatural and engineered answers that may be false or aspirational instead of real or actual. In any situation where a question is posed during tests or interviews, people tend to construct experiences that are generalized instead of true. Most users, when given time to think about an answer, humanly and naturally will feel compelled to answer a question "right" or artificially "intelligently". They will want to sound and feel like they're giving a correct answer instead of a real answer.
What to do
Conduct unmoderated testings where you purely just observe user behavior. This can be done with and without the knowledge of the users. This can also be achieved through web analytics and heat maps. User interviews can be done by observing the user's workflow, thought process, and behaviors. Showing you what they do instead of saying it to you will showcase the actuality of the research.
3. The data doesn't get used for design outputs.
Research is not impactful until you have design output to back it up. It is not effective until you have designs to prove its value. The research data may be perceived as just information and learnings, but how you execute on the data is what will really brings the value out. All too often, the data might be too abstract, might be too overloaded and dense, or might be focused on the wrong problems or things, leading to no design direction or clear solutions.
What to do
Ensure your data analysis correlates a learned insight is applied to a UI design solution. Ensure there are design actions stated to keep the momentum going through the process and also to ensure the testing led to tangible solutions. Ensure that a UI solution is always the final output and objective from the beginning to end. Most importantly, design the solution. Show how the solution was influenced by the research. Deliver the design to your team with research backing to support it.
4. The data is incorrectly interpreted and hypothesized.
Stakeholder may sometimes believe research data might be incorrectly translated based on the researcher or data analyst's interpretation. They believe the quality of the data is only as good as the competency of the analyst or researcher obtaining it. This is mostly due to low confidence or trust in the process, ability of the researcher, and type of data received. In most cases, stakeholders may even make their own interpretations and have their own opinions which is not aligned with the analyst or researcher. Then this created turmoil, misalignment, and confusion.
What to do
Display the actual data and comments from your users. Show the real or raw facts. Walk your team through what was actually done or said. Then provide insight and foresight after. Be flexible and open to interpretation from your team. Have something for them to react to. You can also include them in work sessions to organize the data.
5. The research data is led on and influenced.
The researcher might have directed the answers through leading questions and manipulate the data to their benefit or advantage. Stakeholders may believe the analyst or researcher is biased or has experiences with similar topics in the past, swaying their expectations of the user or workflow. Bias can also come from competitive landscape research, initial projects, or communications with other counterparts.
What to do
Include your team in your research activities like user interviews and usability tests. Ensure they are either invited to, participating or observing you administer or moderate the interviews and tests. They will get to witness what takes place and can see how things are not being skewed or altered.
6. Stakeholders claim they already know what to build.
Stakeholders may provide anecdotal suggestions and literal design solutions that are based on biased opinion, personal interpretation, or just pure business metrics/goals. The stakeholder may have obtained these ideas from their own interactions, saw competitors do them, or is plainly using their intuition to fabricate them. Stakeholders may have also done their own research initially without the UX designer, potentially missing out key UX methodologies focused on user empathy, creativity, connecting dots, and metaphor association.
What to do
Challenge the idea by posing your research questions directly to the stakeholder a la the socratic method. Continue to do quick and light research to validate the idea. Get a sense of the stakeholder's meanings and values, and reconcile that with real UX values like user goals, workflows, emotions, etc.
7. The research isn't tied to actual product outcomes.
Stakeholders may think that the research didn't lead to positive product outcomes on a business, technology, and user satisfaction level. They may think that the research informed the UI design and then the buck stops there. They may think the research was purely about defining design and not about real problem solving for the company.
What to do
Map your research data analysis to actual product outcomes. Illustrate how an insight is tied or related to an ROI, KPI, or user satisfaction. Showcase how the research applied business considerations and metrics.
8. The data is hard to understand or interpret.
Stakeholders or pod mates don't understand what the data is conveying or how it can be translated to their product strategy. Research reports are sometimes text-heavy and lack sequence or analysis. They often are too abstract, convoluted, and lack communication. This may be because the information is raw, it's dispersed, and not connected. If this happens, stakeholders will give up on trying to understand it, and it gets shelved.
What to do
Provide an analysis of the data through storytelling. Organize your data in a way that is consumable and easy to understand. Ensure there is a methodical approach to representing the data. Ensure stakeholders can easily consume it on their own without your narration if need be. Your job is to make complexity easy. Your research reporting should be as clear as your UI design solutions.
Summary
Designers have to take it upon theirselves to do what is necessary in order for them to acquire the appropriate and sufficient knowledge to design the most optimal UI for their required feature in a sprint. Identifying the right problems (ROI and KPI), understanding jobs-to-be-done, and determining the right UI will all be informed by user research. Showcase how the research proves your solution outputs and outcomes. Ensure you communicate clearly, involve your stakeholders, and drive the efforts methodically, quickly, and strategically.
About the author
Sean Lazo is a Principal UX Designer at [24]7.ai who leads the inception, assembly, and design of [24]7.ai Conversations, an industry-leading omni-channel AI chatbot SAAS platform. His passions are DesignOps, detailed design, research, and human relations.
Comments