Being a UX Researcher in an Agile Team.

Square
UXR in Agile teams

Most product teams are hungry for research. They know that to be able to build better products they need to know their user needs and goals. To get this coveted information they need help from the UX Researcher or UX specialist. The role of a UX Researcher is to discover the problems and needs of users, in order to be able to know if there is a real need for product or service in the market. The desired outcomes of the UX Research are to create empathy and help the team understand their users.

UX Researchers in Agile teams

To be able create empathy in the team, the UX Researcher needs to be actively involved in the team. Most teams these days work using Agile methodologies, like Scrum or Kanban with rapid iteration, experimentation and release.

To be able to work well in the team, UX Researchers need a solid understanding of their users, their touch-points as well a strong user journey to ensure that they are solving the right problem. Once this is achieved and the development process starts, the product teams need continuous and fast feedback from the UX specialist to be able to support their prioritisation. Teams need to learn whether their incremental improvements are headed in the right direction or if it’s time to pivot. The insight that the UX Researcher offers the team in this situation is key for the product to progress in the right direction.

However, many UX specialists have problems fitting into Agile teams, finding a lot of challenges along the way. The first challenge starts when the UX Researcher arrives in the team, being in many cases a solo UX practitioner in a team with a really small budget. To make matters worse, this is often after several development cycles have taken place, and there may be an expectation that the UX practitioner adds value immediately in the next development cycle. Without an existing set of personas, user journey and user stories… the UX Researcher has a lot of work ahead of them to be able to catch up with the team.

This bad start often makes the UX Researcher focus mostly in understanding their users, losing track of the work of the team. This gives them a bad reputation in the team, who see the UX Researcher as not very collaborative and offering little contributions to sprint ceremonies.

In the best scenario, when User Researcher is following the sprint cycle, they continue struggling to keep on track mainly because many of the classic methodologies used by UX Researchers take longer than a typical fortnightly development sprint. UX Researchers ultimately end up doing studies too narrow in scope and as a result, valuable features don’t make it into the final product.

New ways of working

Fortunately, things are getting better thanks to new ways of working like Lean UX.

Lean UX advocates autonomy and creativity. It places emphasis on iterative working and the continual delivery of value to users, in order to both improve their user experience, and also as a source of learning about user needs at the point of consumption.  Lean UX techniques include hypotheses and Proto Personas to be able to build a MVP (Minimum Viable Product) as soon as possible, and testing with users sooner rather than later. This methodology works really well in mature products, and also when the team is just making incremental innovation and minor changes with regular feedback coming in from the UX specialist.

However, Lean UX doesn’t work well if the product has been vaguely defined, the market is new or the expectations of the organisation aren’t clear. Failing to understand the users at the start of a project can set a project off in a downward spiral that no amount of Lean UX can rectify.

One way of tackling this comes from Jake Knapp and Google Venture and their Design Sprints. Design Sprints can be useful in challenging situations, such as high-risk projects. A sprint is a good time to check out initial ideas an change direction in a short time frame. It also fits in well when you are short of time to do test the outcomes of a project. The goal of a design sprint is to take all of the existing research about a problem, unpack its essence to a diverse group, then ideate like crazy. The ideations are then funnelled through the lenses of human centred design and those that survive are voted on by the team. Designers then build a low-fidelity prototype that is just barely good enough to test on potential users. The results of the test, if positive, create a target for designers to hit in high-fidelity; giving a quick good start to the Lean UX and Agile cycle.

Tips to overcome the problems

These new methodologies are helpful to overcome some of the UX Researcher’s problems and I am sure that eventually UX Researchers will be able to fit in, and give their full potential to their teams from the start of the project. But until companies adapt to these new methodologies in their teams, some small tips form UX Researcher always come handy: 

  • Start the research as early as possible. I know, sometimes this is not in your control.
  • Make sure the first research project you pick helps you shape the overall high-level user journey and the upcoming research-priority story.
  • Make the Business Analyst and Product Manager / Owner in your best friends. They will help you to understand the bigger picture and the assumptions you need to find out and validate. They also will be able to help when the length of your discovery activities do not fit into the sprint cycles.
  • Prioritise projects where success is most likely. Researching what has the biggest impact and is less time-consuming. This will help you in get credibility in the team.
  • Improve communication with the team: Use the same tools that they use to communicate and deliver information, this will help you to get quick feedback from them.
  • Try to be 2 or more Sprints ahead of development.
  • Be creative and flexible about your methods. Be able to flex the rules of traditional research methods.
  • To fit into the sprint cycle, break down research questions into the smallest possible hypotheses.
  • When you are short of time, consider more remote and unmoderated methods like video-conferencing.

Conclusion

Remember that learning is a team sport, and collaboration is key if we’re going to find our way to the place we want to be. Take time to develop strong communication with each other, and teams need to be aware and supportive with the constraints that every fellow team member goes through. We should embrace the things that work and learn from the things that don’t, in order to be able to grow as a person and as a team.