The Research Recommendation Engine
Research is like lunch.
When working from home, things like running errands, cooking, cleaning, taking care of a pet or family member, and the laundry list of other work impediments can put strain on work deliverables. But lunch is critical because it gives us not only the energy we need to do good work, but also it’s a fact that nourishment prevents terrible headaches. Making time for it can be so hard sometimes, especially when we’re not in an office where the environment slows down around noon to remind us. User research is no different from lunch. It’s critical for doing good impactful work, yet most of the stakeholders we as researchers support are not especially skillful at carving out time for it.
To help the people I support get better at dedicating time for user research — specifically for the projects that warrant it — I have created a 3-step solution, which I call the Research Recommendation Engine. You’ll be relieved to know it’s actually only 2 net new steps, and the whole thing only takes 5 minutes to execute.
The Product Owner prioritizes an idea. I’m a UX Research Lead at a large financial services company, and we use the Scaled Agile Framework. That means in my department this step occurs during what we refer to as the Pre-PI Planning phase. In other words, this step happens at the precise point in time when Product decides to take an idea out of the backlog and prioritize it.
The Product Owner assesses each newly-prioritized idea for UX Metrics (UXM) risk. This entails answering the below 6 questions about each idea to gauge where the enhancement falls on the spectrum of Low, Medium, or High risk.
1. Does this enhancement improve accessibility? If yes, that pushes needle towards Low
2. Does this enhancement fix a customer pain point that is grounded in observations? If yes, that pushes the needle towards Low
3. Has this enhancement been proven effective at improving KPIs elsewhere on the site? If yes, that pushes the needle towards Low
4. Does this enhancement have a strong possibility of hurting our most important KPIs? If yes, that pushes the needle towards High
5. Does this enhancement add friction or anxiety to the journey? If yes, that pushes the needle towards High
6. Does this enhancement deploy a UX dark side technique that has the potential to decrease trust? If yes, that pushes the needle towards High
Once these 6 questions have been answered as fully as possible, it should be clear how risky the new idea is from a UXM perspective.
As you’ll have noticed, the assessment in this step is powerful because it accounts for both qualitative and quantitative risks. The 6-question list can also be tailored for the specific needs of your department, and as long as it still thoughtfully takes both qual and quant impacts into account, it should remain effective.
The Product Owner uses this research recommendation model below to gauge how much UX research should be accounted for in project timeline, and at what points. Realistically speaking, there is not always the luxury of time or resources for research, but when there is, this guide can help stakeholders see the light at the point in time when it’s most critical for project success.
Note that this Research Recommendation Engine works especially well for digital enhancements, such as updates to a website, which is the type of projects my team helps support. It also works especially well for smaller batches of changes, where the UXM risk level is clearer to gauge. I will say I have found that for something like a full page redesign, where the volume of elements concurrently changing is larger, it should be designated as a medium or higher UXM risk level, and thus some degree of research is warranted. Aligning on the optimal research plan in that scenario might warrant a conversation between Product and Research.
The last thing I want to point out is that not every Product Owner is upskilled enough to know whether an enhancement will have an effect on accessibility, or whether a neuroscience technique is at play which has the potential to decrease trust. I’ve found that training stakeholders in the finer details of user experience has been helpful, and as a best practice I created an internal UX Research blog at my company to help facilitate UX training. Since so many UX decisions typically happen at the Jr. Product level, it’s especially important for us as user advocates to help upskill them to be effective user advocates as well.
I truly hope this UX Research innovation I created is helpful for someone out there, and know that I’m always happy to connect on LinkedIn to chat further.