User Research in the Age of Agile
Read Part One in my series on User Research here.
Agile has taken the world of software development by storm, and rightly so.
It has many benefits: an incremental approach, the ability to change direction based on customer and stakeholder feedback, and short timeframes that keep the teams focused.
However, the methodologies are focused on developers, and emerged out of attempts to solve common pain points experienced during big software development projects. It doesn’t include UXers, or account for the time, resources, and research they need for the design process.
Although agile practices vary from company to company, there’s a shared set of values and principles that prioritises:
- Rapid, continuous release of live code
- Collaboration across cross-functional teams and users
- A commitment to responding to changes
Agile teams are cross-functional, and work on a series of short sprints (usually 2 week timeframe) to create working code. Unlike more traditional approaches to software development, there aren’t any distinct stages dedicated to discovery research, requirements definition, design, development, or testing.
This can pose challenges to UX research, as it means there isn’t as much dedicated time to thoroughly understand users and their contexts — instead it means figuring out the design requirements just in time for development to begin, and working in parallel to rapidly reiterate on design decisions.
It can seem daunting, but there is a silver lining.
It means we get to quickly respond to the changing needs of the team and users, constantly uncovering and acting on opportunities to improve the experience.
Due to the relatively short sprint cycles, it also means we need to rethink the methods that we use for UX research. Who doesn’t love shaking things up and innovating the innovation process? When you choose different methods you still need to consider the same things:
- Translate specific research questions and assumptions into hypotheses to be tested
- Uncover whether you’re looking for trends or reasons
- Confirm the context(s) of your research, and
- Whether you need to look at behaviours and/or attitudes
To integrate well with Agile, you need to break down research questions into the smallest possible hypotheses, so that they can be tested quickly. You’d then need to plan which methods will be most appropriate, and how you can get meaningful results within a sprint.
More often than not, the best thing to do is a study that tests multiple hypotheses, and brings a number of methods together. For example, your team may want to test the usability of an existing app, and also need to follow up to understand why different features aren’t being used. For the first part, you’d do some usability testing, and for the second part, you could add interview questions to understand the “why”.
Another thing to consider is prioritisation. Two things that can help you prioritise what to research are:
- Which aspects will have the biggest impact, and;
- The time taken to conduct the research
There will be a lot of unknowns that need to be discovered and validated, so list these out as individual research items. Then, map them out based on least to most impactful, and least to most time consuming.
Prioritise those which are high impact, but fast to research and validate.
It’s important to keep in mind that the core tenets of UX research should remain the same. UXers are creative and innovative at heart, and reimagining the methods we use offers a unique and playful opportunity. Who knows, perhaps being flexible, agile, and still delivering robust research results will make you question why you ever did things any other way… and you may never look back.
If you’re interested in finding out more about how we practice UX and software development at Propellerhead, you can reach out here.
You can also read Part One in my series on User Research here.
