How can we fit user research within agile delivery?

(Disclaimer: From the point of view of a User Researcher)

How user research “fits” within agile delivery is always a hot topic for debate. There may be frustrated researchers on one side, technical teams stood up ready for development on the other, then design and content stuck somewhere in the middle. All with pressure to meet tight deadlines. Agile teams usually work in focused 2-3 week sprints, with the aim to deliver a feature or specific part of a product, but research can apply to multiple features and often takes longer to complete. As a result, design and user research can fall into a pattern where research is lagging behind, whilst there’s a lot of pressure on design to “do something” to fit within project plans. When valuable research insights do become available, they can often be shelved due to timelines, and the intent to be user-centred can become a bit, well, lost.

Researchers can fall under many titles including ‘User Researcher’, ‘UX Researcher’, ‘UX Consultant’, ‘Design Researcher’ and ‘Usability Consultant’. Someone recently asked me what the difference was between all of the roles, and my response was fundamentally, nothing (also a hot topic for debate, and this is of course just my opinion). However, in the context of agile delivery teams, the more recent terminology ‘Design Researcher’ perhaps helps to communicate that whilst we are carrying out research, our end goal is to help inform design.

Whether a User Researcher or Design Researcher, ensuring user insights are central to design is the biggest challenge. There isn’t a simple solution to how we fit user research within agile delivery teams, but we’ll share some things that we’ve found useful. From a user research perspective, of course.

Take the team on the research journey

Often, we see design and technical teams being unaware of the user research activity that’s been happening or where requirements have come from. No one enjoys requirements being “thrown over the fence” without knowing the background, and this doesn’t have to be the case. It’s the responsibility of User Researchers to make any research a team sport (and to keep everyone honest!).

Working closely with Product Designers, Content Designers, Analytics and the tech team to plan, run and playback research will help everyone to feed into key areas of interest and get more involved in productive discussions around product requirements. Product Owners, Delivery Managers and Business Analysts should be involved throughout, helping to champion the user research activity happening within the project and communicating with tech teams.

Continue with discovery

Teams can often become focused on the specifics of a product before any discovery has taken place. Depending on what stage a User Researcher joins a project, it can be difficult to unpick the origin of features and any previous research conducted to support needs. This can lead to a reactive approach, without stopping to ask the fundamental questions that should have been investigated during the original discovery phase.

Encouraging a culture where the whole team asks questions ensures continuous learning, whether this is from existing insights or new research. This is essential when the direction for a product can change quickly both within and across sprints. Discovery shouldn’t just stop after the discovery phase. It should be ongoing.

Make research activity visible to the wider team

In stand ups, user research activity should be represented on the board. Technical teams are usually extremely interested in the work research are doing, and even if they don’t need all the detail, stand ups are perfect to give a headline view of what’s coming next.

Within each sprint, user research tickets might include participant recruitment, running the sessions, analysis and playback to the team. Following research, new tickets can be added to the backlog for fixes and new areas to explore. Lean on the Project and Delivery Managers to get any key user research messages out.

Establish ways of working

It might seem like an obvious requirement, but sometimes the pressures of deadlines and people rolling on and off projects, can make it difficult for teams to get into a cadence. Establishing good relationships where everyone is clear on roles and responsibilities within the team can take time, when there isn’t a lot of time available. Accepting that this is “just the way it is” however, makes for bigger issues in the long run.

Investing a little bit of time in clarifying ways of working up front (along with any refreshers, when needed), can lay a great groundwork for team communication. Make sure that a visual overview, whether it be on Miro, Mural, Confluence or somewhere else, is available for anyone joining the project at a later point. And that reminds me, a good onboarding pack for new starters goes a long way!

Show, don’t tell

No one really has the time to read a 40-page report when they’re under pressure to meet tight deadlines. Researchers also don’t usually have time to create them when they’re working within sprints. This means that insights need to be succinct and presented in a way that makes it easy for teams to get the key information, quickly.

Make use of Slack or other channels the team use daily to communicate, by posting a summary of what’s happened in research sessions each day. It could be a rundown of each participant or just any key themes that have been emerging (with a caveat analysis is yet to be carried out). Creating a “one pager” template can help, also setting expectations amongst the team on they type of outputs user research will provide.

User researchers know it’s important to have some time to carry out analysis, and sometimes there’s a need to push back on some meetings, when it’s really needed. So, think about a more in-depth co-analysis workshop following the research, with the immediate team and the higher level, visual “one pager” summary for sharing up. Project Managers, Delivery Managers and Stakeholders will likely need a different level of detail to the Design team.

Two of our researchers  worked with the Compare the Market’s agile delivery teams on discovery around a range of new, future thinking concepts.

“The System Concepts Team have been a great support to our UX team and the wider business. They’ve been proactive, bring deep expertise and are able to provide excellent direction with very little briefing. Our teams have found them very easy to work with and their output highly valuable.”

Dema Metreweli, UX Research Head, Compare the Market