Other reasons for reluctance can be due to not understanding how research can help. In this article, we\u2019ll look at some examples where this might occur, and some techniques for helping educate people and overcome these fears.<\/span><\/p>\n Helping teams learn about user research will help overcome their fears<\/p><\/div>\n Some teams assume that software needs to be nearly done before it\u2019s worth running user research studies. This belief relies on teams believing that any issue can be fixed with \u2018tweaks\u2019, and that there is no value in research until something representative of the final product exists. However, it\u2019s misguided for a couple of reasons.<\/span><\/p>\n The first problem is that waiting until it\u2019s \u2018ready\u2019 usually means waiting until it\u2019s too late to fix issues. The cost of making changes increases over time – it\u2019s much cheaper to change an \u2018idea\u2019 than an almost completed app. If the core idea of the app is misguided (and it frequently is), learning that just before launch is much too late. Early research studies, looking at how users perform similar tasks, and what\u2019s hard for them currently, can help make sure the idea itself is worth pursuing further, without wasting expensive development time.\u00a0<\/span><\/p>\n Another problem with waiting to test is that people also become more invested in their idea the longer they spend with it. Putting weeks of development work into a feature, only to be told it needs to change, can be hard to hear. This causes people to dismiss research findings and will reduce the impact of research studies.<\/span><\/p>\n Teams also assume that researchers can\u2019t work around bits that \u2018aren\u2019t ready\u2019 yet. However, combining carefully scoped research objectives, and an understanding of the intended experience, allows researchers to recreate the missing parts of the experience where required, allowing the study to go ahead before everything is complete.<\/span><\/p>\n To overcome this misconception, start with education about some of the above points, so that team members are aware of the risks of waiting too long. Time spent speaking with the team to understand their current priorities can also help identify relevant research objectives at every stage of development – a researcher can help suggest potential objectives that the team wouldn\u2019t have thought of independently. Strong communication with development teams will identify high-impact research objectives that can be addressed immediately, and which other objective moderators will need to mock-up or work around in their study designs.<\/span><\/p>\n It is true that it costs money to run user research studies. Finding the right participants takes time, and incentivising them to actually turn up requires giving them money. Similarly, inviting team members to view sessions is costing the company time, because it takes team member\u2019s time.<\/span><\/p>\n As user researchers, we believe that these activities are saving the company money later down the line. This can be hard to measure – although being hard to measure doesn\u2019t mean it doesn\u2019t exist. These studies help save money by allowing teams to get to the best implementation of their idea sooner, and reduce the time it takes to build a useful and usable product. Acting on research studies also helps earn the company money by increasing customer retention. I touched on some techniques for measuring the Return On Investment (ROI) of research in a <\/span>previous article for the Leading Research community.<\/span><\/a><\/p>\n Working out the ROI of user research studies for early, low commitment studies can help build confidence that research is useful and saves money. Researchers should work out which metrics are important to their company – finding more customers, keeping the customers they have, releasing sooner – and describe how their studies are moving these metrics. This makes a strong case for the financial benefit of running research studies.\u00a0<\/span><\/p>\n Most of the time teams already know some things that are wrong with their software. Prioritisation and deadlines mean that many known issues might have to be ignored. This can cause teams to worry that they will learn nothing new from a research study – it\u2019ll just tell them the issues they are already aware of, and not be useful.<\/span><\/p>\n To deal with this, the first step is to understand why the known issues aren\u2019t being fixed. Is it a lack of evidence, which research can help with? Or is it internal politics, such as friction between teams? Uncovering this allows the value of running a research study to be decided, and research objectives to be prioritised.<\/span><\/p>\n Even if some problems are already known, a research study can still provide value. Understanding the impact of the issue on users will help inform the priority for the problem. Understanding a user’s existing experience may also help inspire better fixes to known problems with fewer iterations needed, by bringing \u201chow it works\u201d and \u201chow people think it works\u201d into closer alignment earlier.<\/span><\/p>\n Another aspect to consider when navigating these conversations is defining appropriate research objectives. How will you work with the team to decide what the next study should learn? These should be informed by upcoming decisions the team has to make, and through setting appropriate objectives (and ignoring ones that are related to already understood issues), a research study can help discover new and interesting problems rather than things the team already knows.<\/span><\/p>\n Waiting for research findings<\/p><\/div>\n Research studies take time to run. To reliably answer research objectives requires users, and getting hold of the right kind of user can take a week or more. This can make teams worried that they will learn things too late to address them and that they will have moved onto other priorities, making the study pointless.<\/span><\/p>\n![\"Don't](\"http:\/\/www.stevebromley.com\/blog\/wp-content\/uploads\/2020\/09\/tonik-U0wwiY6nRGA-unsplash.jpg\")
\u201cIt\u2019s not ready to test yet\u201d<\/span><\/h2>\n
\u201cUser research is too expensive\u201d<\/span><\/h2>\n
\u201dWe know what\u2019s wrong already\u201d<\/span><\/h2>\n
\u201cUser research takes too long\u201d<\/span><\/h2>\n
![\"Laptop](\"http:\/\/www.stevebromley.com\/blog\/wp-content\/uploads\/2020\/09\/brad-neathery-nPy0X4xew60-unsplash.jpg\")