Lately, U1 has been undertaking a lot of research for companies working in a mostly agile environment. Naturally, we’ve been working really hard to refine our research techniques and methodologies to work effectively and keep up with the fast pace – without compromising on research insights, quality and ethics. Along the way, we’ve had to jump a few hurdles and I thought I’d share a few of the lessons we have learned. Most of these lessons can be applied to any development environment, whether you’re working in agile or not.
Keep UX (including research) one step ahead at all times
Too often, we’ve found ourselves integrated into a sprint, project, or iteration of a design too late. This prevents any research from being effective, as design decisions are already made. Unfortunately this can lead to being unable to objectively uncover what it is that users really want, or provide feedback to clients that will be useful for everyone.Think of user research and UX as laying the foundations for the rest of the team. Jakob Neilsen (I know, I know) reiterates that UX folk should be “at least one step ahead of the sprint”. That includes the research activities that you do as well.
Be realistic about resources and deadlines
Something that seems epidemic across most designer/development teams is a lack of resources. We get it. But this lack of resources and pushing of deadlines seems to be a common thread that threatens success across many agile environments. We understand that you might need to take a shortcut for the greater good, but it is important that everyone remains realistic about the resources available, and meeting appropriate deadlines. The key to researchers working well in an agile environment is flexibility; we can run research on just about anything, but we need to ensure everyone acknowledges and understands the bare minimum viable product that is required for useful research (which, by the way, is usually paper prototypes/sketches; they don’t have to be fancy). Too often, we see designers losing the big picture and getting bogged down in the detail when we just don’t have time for it. A better idea is to focus sprints and content for user research around fidelity, rather than functionality.
Consistency and communication is essential
Something we quickly learned is that a consistency in process helps members of large teams familiarise themselves with our approach. Plus, it also helps us juggle resources internally. A consistent approach to research and all-contained processes will not only help you stay sane, but ensure everything runs a little more smoothly. Let’s be honest, we just don’t have time for any nasty surprises! Similarly, clear communication between teams is critical to the success of the user research. We need to clearly understand your objectives, hypothesis and assumptions before we go into research. This helps all aspects of the process, from selecting the right type of research for a sprint or design iteration, to ensuring the participant is given the correct tasks or context to ensure the research really gets bang for it’s buck.
Little research is better than no research at all
We know time is critical, especially during sprints, and we have often heard the complaint “I/we just don’t have time for user research”. There is really no excuse to not engage users in a sprint or any design process; in fact, leaving users out of the process deviates from the user-focused spirit of agile that makes it particularly great.
Designs always remain assumptions until they are validated with the right audience. Talking to even just a few users will provide you with a wealth of guidance, insight and validation that you would be otherwise missing.
Don’t forget to think holistically
One of the biggest challenges we’ve observed in the agile space tends to occur when each sprint focuses on a particular feature or component of a greater part. This is because it can be more difficult to uncover useful insights when a user is missing the context of a feature, and/or we cannot test a broader workflow.
Decisions and recommendations made in an early sprint may be ineffective when seen in full functionality or in conjunction with other features. Therefore, it is important to always think holistically, and remember to follow up each sprint or feature testing with end-to-end product validation. Where possible, try to combine outputs from previous sprints before testing with a participant. Otherwise you run the risk of developing an assumption without testing the product in a holistic sense.