If you’re thinking that Agile development has almost completely taken over software development, you’d be correct. In fact, according to one 2015 survey, only 2% of companies still operate using purely traditional Waterfall practices. In short, Agile is everywhere.
While there are many benefits to Agile, it’s meant that those of us in the user experience field have had to examine and adapt our practices to stay in tune. While we’ll no doubt continue to face working in this new world, a little creativity and flexibility can help keep your UX research on track.
What is Agile, anyway?
Before we get too much further, let’s first be clear about what we mean when we talk about “Agile.” Agile is an approach to developing software. Agile practices vary from company to company and even team to team, but there is a shared set of values and principles that prioritises rapid, contiguous release of live code, collaboration across cross-functional teams and users, and a commitment to responding to changes.
Agile teams are cross-functional, and aim to create working code in very short cycles called sprints. There are no distinct stages for discovery research and requirements definition, design, development, or testing, like more traditional development methods, often called Waterfall.
For those of us in user experience, this means we no longer have dedicated time to thoroughly explore users or perform extensive discovery research, and we’ll be figuring out the specifics of the design just in time for development to begin. That’s a little scary for some of us, but it also means we get to respond to the rapidly changing needs of the team and users, constantly uncovering and acting on opportunities to improve the experience.
What about Lean?
Lean is a set of business principles derived from the Lean manufacturing system.The principles are centered around increasing efficiency and value, removing waste and designing the system and teams in place to maximize those efforts. While the principles are similar to those in Agile, Lean is more focused on the holistic business and can be used in any industry, whereas Agile is specifically focused on software development.
One more piece of jargon, just for fun
To make things even more confusing, there is also a specific new product development approach called the Lean Startup methodology. The Lean Startup is centered around iterative experimentation cycles and using the learnings from each to inform product development decisions.
Lean, Lean Startup and Agile are not mutually exclusive. Often, companies will embrace the ideas of including constant validated learning from the Lean Startup, approaches to reduce waste from Lean, and use the Agile development approach to organise their teams and work structure.
While there are certainly well-documented challenges in incorporating UX successfully into Agile practices, there are also tremendous benefits. Read on to hear about some of the specific considerations of adapting UX practices to Agile.
Determining research methods for Agile
There are many existing resources on the best ways to determine which UX research method you should employ to best answer your open questions. I especially like Christian Rohrer’s summary (outlined in the table below), which lays out a 3-dimensional decision-making framework and provides notes about the position in the product development cycle.
| Product Development Phase | |||
|---|---|---|---|
| Strategize | Execute | Assess | |
| Goal | Inspire, explore and choose new directions and opportunities | Inform and optimize designs in order to reduce risk and improve usability | Measure product performance against itself or its competition |
| Approach | Qualitative and Quantitative | Mainly Qualitative (formative) | Mainly Quantitative (summative) |
| Typical methods | Field studies, diary studies, surveys, data mining, or analytics | Card sorting, field studies, participatory design, paper prototype, and usability studies, desirability studies, customer emails | Usability benchmarking, online assessments, surveys, A/B |
Christian Rohrer’s summary of a 3-dimensional decision-making framework.
While his suggestions are spot on, when working in an Agile setting, there is no longer dedicated time to focus on research, and you can’t always spend time on the lengthier methods. Instead, you have to work research into the relatively short sprint cycles – sometimes as short as 2 weeks.
The considerations for choosing research methods in an Agile environment remain the same. You still need to:
- Narrow down a specific question to answer and hypothesise about
- Determine whether you’re looking for trends or reasons
- Consider the most appropriate context for your research, and
- Think through whether you need to look at behaviors or attitudes.
However, due to the limited timeframe in Agile, you often need to make a few tweaks to successfully integrate your research. Tactics like breaking down research questions into the smallest possible hypotheses and being willing to flex the rules of traditional research methods are a huge help in keeping up high quality UX in an Agile environment.
Smaller hypotheses
For instance, let’s say that you’re working on a new version of an editor for an existing online blogging platform, and you want to make sure that it’s easier to use than the original version.
In traditional waterfall development, you’d fully flesh out a new and improved version of the editor and it’s many features, then set forth to test the hypothesis that your new design will perform better than the last. You’d probably create a high-fidelity prototype and do a series of competitive usability tests comparing the two experiences, making sure to include several rounds with each target persona. The whole thing could take months.
In an Agile environment, you’d approach things quite differently. Let’s start with the hypothesis that the new design will “perform better;” you could easily break that into several hypotheses, each centered around specific features or user groups.
For instance, you might write one hypothesis that goes something like, “If we implement drag and drop formatting, our non-technical users will find it 30% easier to lay out their blogs” and a follow up that goes something like, “If we provide image editing, users will value our service more and include at least 10% more imagery in their blogs.” You’d then work to prototype and test the first element, drag and drop, before you start working on the image editing.
Franken-methods and flexibility
In addition to focusing on investigating smaller components, you may need to get creative about the methods you use to ensure that you make the most of your research time and maximize results.
For instance, maybe you have a few hypotheses about different elements of the product that are in different phases. You want to test the specific usability of an already-prototyped interaction, and also need to follow up to understand why an existing feature isn’t being used much. You’d typically want to run a usability test to answer the first question and interviews to answer the second. But instead, you could add a few interview questions at the end of the usability test. Because the sessions are so narrowly focused on the specific interaction, you should have plenty of time to mesh the two.
I’ve also found that as we need to push to faster and faster timelines, we’ve been using more remote and unmoderated methods. There are well-documented cons to not being able to be face-to-face with a user, but if your choices are to skip interviews or do them with video-conferencing, definitely choose the latter.
There are many other ways to flex methods that take some getting used to for those of us who come from rigorous research backgrounds. For instance – maybe you test a specific interaction’s usability with colleagues who aren’t familiar with the project instead of recruiting outside users or don’t worry whether you’re going to have statistically relevant results for a survey response. Maybe instead of writing up a thorough findings report, have a short debrief meeting where everyone shares their key takeaways and document just those.
One trick that I find endlessly useful is to go ahead and proactively schedule regular research sessions with users, especially if you can build up a panel of willing participants. The logistics around scheduling participants can be time-consuming, so setting up an ongoing process will streamline the process and remove the excuse that you won’t have time to find and schedule participants. With so many things in a state of perpetual flux, I guarantee you’ll always have something to investigate.
Remember, the core tenets of successful UX research remain the same regardless of the other considerations in your specific environment. Being creative and flexible about your methods doesn’t let you off the quality hook, but it does allow you to gain valuable insights in a way that makes most sense for the collective team.
