User research doesn't have the best reputation for fitting well into agile project teams. Agile requires speed - getting useful insights to an agile team quickly can be difficult to achieve.
There are 5 things that have helped us make user research more effective in agile:
- Dedicate a user researcher to each project team
- Do research in every sprint
- Evaluate the now/explore the future
- Gather both tactical and strategic insights every sprint
- Communicate research to your team in many ways
It’s taken us a while to settle on those 5. I’m going to explain what we used to do compared to what we do now.
1. Dedicate a user researcher to each project team
We used to treat user research like an internal consultancy. Teams would brief a researcher to do a piece of work and the researcher would either run the research themselves or procure the work from an agency.
In those days, a 4-week turn around was considered fast for user research. By the time the research came back, chances were high that the team had moved on a sprint (or more) and the research was irrelevant.
Also, because the researcher knew little about the project when they were called, there was no guarantee they were researching the right thing.
What we do now
We now aim that researchers have at least 3 days each week sitting with the team.
This lets us design better research projects and we’re able to learn useful things at the right time for the project's needs. We can do more than just usability test interface elements and, because we’re now sitting with the team, we can make sure that designers and product owners are able to make practical use of what we’ve learned.
2. Do research in every sprint
We think that agile sprints are one of the best things to have happened to user research.
When a user researcher joins a project team, the first thing they do is make sure a round of research happens in every sprint.
We mostly do lab-based, 1-on-1 depth sessions - it’s the easiest way for everyone in the team to observe the research and get exposure hours. We use other research methods in addition to this regular ‘heartbeat’ of research.
User research is a team sport - an important team mantra.
The wins
Researching in every sprint helps the team maintain a learning attitude throughout the project. This is the best and most valuable outcome of integrating researchers into agile teams.
It also allows us to experiment at low cost with a range of different approaches to service design and we're continually learning about our audience - what’s important to them and how best to design the service to their needs.
3. Evaluate the now/explore the future
We don’t worry about how many sprints we should be ahead of the developers - we believe researchers need to be all over the service all of the time or at least traversing the 'now' and the ‘future' on a very regular basis.
Evaluating the now
The role that people seem most familiar with in digital teams is evaluative.
Evaluation asks, through usability testing, whether the thing we’ve designed is doing a good job of meeting user needs and is easy to use or not.
Exploring the future
Regular experimental research (using a light-weight prototyping environment) gives the team the opportunity to explore a range of different approaches to design and content and to understand whether the effort to bring those things to reality would be worthwhile.
This is critical in the earliest project phases (alpha and beta) but also supports the continuous improvement required by the Digital by Default Service Standard.
4. Gather both tactical and strategic insights every sprint
Agile research doesn’t restrict you to 'tactical' insight only.
Research in each sprint should be both tactical (answering design hypotheses) and strategic (understanding the audience and what’s significant to them in the context of the service).
The trick is to make sure you're asking strategic questions regularly then making time to update your models and communicate them back to the team so they’re useful.
Our researchers create models, personas, journeys etc. to capture strategic insights, which they update and share with the team as they learn.
... which forms a nice segue to the last point.
5. Communicate research to your team in many ways
Different teams have come up with different ways of communicating key strategic insights to their team, from posters to slide decks.
We don’t produce research reports in agile teams. They take too long to deliver and, when you’re involved in day-to-day design decisions and prioritisation of the backlog, they're not necessary.
We have another mantra:
Don't do research for researchers, do it for the team.
Communication is our way of delivering on that.
Sit with the team
Communication happens because the researcher is co-located with the team and can represent the end user when the sprints are being planned and stories are being prioritised.
Communication also happens when the researcher is sitting next to the designer while the interface is being designed - they can provide feedback then and there based on what they know from research.
Present and share
Researchers present at regular show-and-tells (where we show videos from research) and find opportunities to 'play back' the research to team members who weren't able to attend.
We also share the results of strategic research on walls - personas, journey maps and interfaces annotated with research findings.
In conclusion
These 5 points have made a big difference to the effectiveness of user research in our agile teams. We hope you'll find them useful too.
We'll be writing more about each of these points in coming weeks. Are there any other tips you've found useful for researching in agile? Feel free to comment.
Keep in touch. Sign up to email updates from this blog.
2 comments
Comment by Simon H posted on
Thanks, this has been really useful 🙂
Comment by amy h posted on
Thank you! Very interesting and helpful!