User Research X Agile Product Devlpmt - The Research Backlog 4/4 - Deepstash

User Research X Agile Product Devlpmt - The Research Backlog 4/4

Importance — how important is it to answer this research question? Think about the business and customer impact — you may want to rely on the POs to guide you on this. L= Low importance, M = Medium importance, H = High importance.

When is it needed by? — Is there a deadline for this work?

Who/what else could we rely on? — It may make more sense for another team to pick up this research question e.g. Analytics, Customer Insights.

How much do we know currently? — What previous research has been done? Are there insights from other teams/sources which we could use to help answer this question.



Managing Research and feeding hypothesis and areas to test into a regular research cadence are critical for mature user experience teams and products


1 Comment

MORE IDEAS FROM Backlogs: The secret to managing user research

User Research X Agile Product Devlpmt - The Research Backlog 1/4

What’s the process of creating a backlog?

Step by step process:

1. Run a workshop with your team/s to first capture and prioritise research questions.

2. Using the template, move the identified research questions into the “Backlog” section. New research questions can also be added as they emerge.

3. Starting with the high priority questions, try to fill out as many of the columns as possible

4. Based on the importance and effort estimates, pull the research questions that you are confident you can deliver that month (you can change this to weekly/quarterly if needed) into the “Monthly Backlog”.



User Research X Agile Product Devlpmt - The Research Backlog 2/4

5. Set up a regular meeting (Every two weeks, or monthly) with you key stakeholders (Product, Design etc.) to review the Monthly Backlog and confirm what the high priority projects are.

6. Once you pick up a research question, move it into the “In Progress” section

7. As you progress with the project, you can update the “Status” column accordingly to keep stakeholders informed e.g. Planning, Testing, Analysis, Reporting

8. Once the project has completed, move it into the “Completed” section. You may wish to add a link to your final report in the “Status” column.



Backlog content

Squad/Tribe/Area — which squad/tribe/area would this work fall under?

Key stakeholders — who are your key stakeholders for this project?

Research question — what’s the question you’re trying to answer?

Type — is this evaluative or discovery research? Keeping track of this over time, will help you to ensure there’s a good balance.

What’s involved? — what UX research methods could you use to answer the question?

UX Researcher Effort — how much effort will it be for you to complete this research? 1 = Low Effort (e.g. days), 2 = Medium Effort (e.g. weeks), 3 = High Effort (e.g. months).



Deepstash helps you become inspired, wiser and productive, through bite-sized ideas from the best articles, books and videos out there.



The types of questions that you’re going to get asked are going to be completely dependent on the client, your job role and the project that you’re going to be working on. If going to be working on a project where you’re going to be expected to do a lot of user research and a lot of stakeholder management, then you’re going to get asked questions that relate to “how you work with stakeholders, what your user research process is about.”



What types of questions can you expect in a UX Design Interview?



Agile mindset

Agility is the ability to be quick and graceful. Agile mindsets focus more on core values such as: Respect, Accountability, Collaboration, Being adaptive to change, learning cycles and improvement.

An Agile mindset helps to easily overcome obstacles and not get stuck when unexpected events happen.




One of the most important times for a design review is at the end of a development sprint. A design review evaluates whether or not the developed product is in line with the original creative vision and user experience. In other words, it’s a review of the developed project which helps to verify all graphic and technical components display and function properly.

As the design gets passed from design teams to product owners and development teams, they each make changes due to temporal or business issues, which can mean the final product doesn't correspond with the design team’s vision.