Why User Research Should be Embedded Into Your Agile Process
For many teams, user research is a bit like spring cleaning: they know it would be beneficial, but they rarely get around to it. For some, it happens occasionally, mostly at the beginning of a big project. For others, user research is an ongoing process of communication with their users.
Most teams seem to operate somewhere in between.
If you are lucky enough to have a dedicated user researcher (or multiple user researchers!), you’ll know there is often tension surrounding where exactly user research should fit into the broader software development equation.
When I joined Refinery29 in mid-2017 as a user researcher, the relationship between user research, product, and software development looked something like this:
User research and product marketing were essentially operating in our own separate department, split from the agile teams we supported, often working weeks and even months in advance of the developers. We conducted large foundational research studies at the beginning of large projects, or at the end to assess the success.
This was challenging for 4 reasons:
- The obvious problem with this process was that we were essentially stuck in a siloed ‘waterfall’ cycle, while the rest of the team was iterating continuously. The further research insights are from their practical use, the less impact they are going to have.
- We didn’t participate in agile ceremonies, and therefore often missed out on the valuable insights that emerged, especially unclear pain points that could have benefited from usability testing.
- The separation of teams made it hard to circulate the results of larger research studies we developed, such as personas, which are representations of the goals and behaviors of our target users.
- This in turn made it challenging to align with Product & Engineering priorities for future studies.
Standing Up For Our Users
In late 2017, we rethought how and where user research fits into the Refinery29 Product & Engineering universe. We decided what type of studies should be embedded within the agile team structure, and what should remain separated.
When we began to think about how we could better integrate our user testing into our development process, the question we kept coming back to was:
“How can we reach a state of continuous learning?”
One of the superpowers of user research is that it can give you a continuous feedback loop available between your users, your product managers, and your developers. The challenge is finding the right balance of testing small hypotheses often, and larger, more abstract research studies.
How We’re Approaching User Research Moving Forward: Two Key UX Processes
Given we are a relatively small team, the balance we are working towards is something like this:
80% iterative research —
- When we test: Continuously throughout the development sprints
- What we test: Straight-forward hypotheses
- Method: Usability testing (remote + in person), 1:1 interviews
- Timeline: Less than a week of testing
- Outcome: a 1-page document on the specific outcomes, with recommendations.
Example: During the redesign of our global navigation, I ran a series of usability tests and provided specific UX suggestions based on the results.
20% foundational research —
- When we test: In the generative or evaluative stages of a project
- What we test: Larger assumptions about our users
- Method: Diary studies, extensive interviews, focus groups
- Timeline: 2 weeks +
- Outcome: Personas, Large Reports.
Example: As a part of launching our Refinery29 shopping experience, I created shopping personas to help illustrate the wants and needs of our users.
We’re still in the early days, and this balance is something I suspect will continuously fluctuate depending on the products, projects, and team resources, but we are already reaping the benefits of this new structure! Stay tuned to see how we used this new structure during our recent website redesign.
PSA — if you couldn’t tell, we do a lot of user research! Sign up here to participate!
