Using a Research Mindset to Save Time and Reduce Risk
The greatest risk in any project isn’t going over budget, delivering late, or changing the scope. The greatest risk in any project is building something people won’t use.
This isn’t just a high-magnitude risk, it’s also highly probable. Failure to deliver value to users happens more often than many people realize. When someone does take a more rigorous look at value being delivered they usually find that “nearly everything fails.”
In one internal review, Microsoft engineers found that only about ⅓ of feature ideas had statistically significant positive results when tested with users. Another ⅓ of the ideas had neutral results, while ⅓ of the assumed-to-be-good ideas actually produced negative results.
Even where Lean and Agile methods are used, it could take months before the product or feature is exposed to users. In the meantime, time and money are spent on assumptions that could easily be refuted or refined with a bit of research or prototype testing.
Say you’re thinking of adding a new feature to your product or service. You might feel confident based on its popularity in other apps—e.g. chat, “stories” or photo filters/lenses—but what works for one audience and context might not work for yours.
Identifying and testing assumptions doesn’t need to turn into analysis paralysis or months of costly studies. When done well, approaching ideas with a bit of research-style discipline saves more time than it costs.
Before doing anything, ask a few key questions to get a sense of how risky your assumptions are. This is how we figure out how much research and validation is worthwhile.
- Who will use this?
- When will they use it (or what will cause them to want or need it)?
- What value or benefit will they get as a result of using this?
- Is this really the most efficient and effective way to deliver that value?
There’s a fifth question, which might be the most important. It often requires asking a few different ways before getting a good answer.
- How do we know these answers?
- How are we testing our assumptions?
- What results will tell us we’re right or wrong?
Spending a few hours reframing assumptions as testable hypotheses might mitigate months of uncertainty and disagreement. A few days of guerrilla research might achieve the same clarity and alignment as weeks worth of deliberation. Or a one-week design sprint might lead to a strategic pivot that would otherwise require months of development time.
Avoiding tough questions only delays inevitable answers. Skipping research doesn’t actually reduce research costs, it turns the whole project into a research cost. When approached openly, early questions and answers lead to more successful products sooner.
Sign up for our 1-day UX workshop to learn more about how to apply these principles to user research and strategy.
(An earlier version appeared at res.im on May 26, 2016.)