The Agile/SCRUM and UX design combo

If you have ever been the (only) designer in a team that works with traditional scrum, you know that you got stuck in the sprints sooner or later.

As a designer, you must do research (or outsource it), which takes time to prepare and execute. You are required to make prototypes, which take time to build and test. While you are working on those things, your team cannot move forward. This causes a sticky situation where team members may put pressure on you to finish quickly, or worse, you get sidelined as the team ‘steams’ ahead without you. In both cases, you, the user and the product suffer.

The Agile Manifesto caused this situation. Its 12 principles describe it (https://agilemanifesto.org/principles.html). I won’t read through all of them, but I will show you principle number 4, which goes like this: “Business people and developers must work together daily throughout the project.” The product owner represents ‘Business people,’ and the developers are, well, the developers. No designer is mentioned in any of the twelve principles.

So, bad news, right? Not necessarily.

I have worked on numerous projects. Large and small. New design and redesign. Large teams and small teams. The reality is that each project is different. Each team is different. Every company has its own character. Some are outright feature factories, and others do top-notch user-centred work. The truth is that there is no ‘one size fits all’ when it comes to synchronising design and scrum. Agile was never made for that. But this is what you can do:

1. Work outside of the sprints.
You can work outside of the sprints in a so-called Spike. A spike is a time-boxed period where you can do whatever you need to do without slowing down the rest of the team. When you are done (the time is up), you can send the value you got from your research back to the team.

2. Work two sprints ahead of the rest.
It is easiest to get done. Assuming your sprints are two weeks long, that will give you four weeks to do some user research and put together a solid report with recommendations.

3. Base your information on desk research web analytics and best practices.
Dicey. A poor man’s solution. A catch-22 but still a lot better than gut feelings, which I have also seen happen at prestigious companies. Let the web analyst make a list of the top 250 most visited pages if the website is that large and select from the top 50 or so to understand what people are looking for on the website. Then, get a Hotjar account and observe people walking across the pages. Now you know what people are doing; you only have to figure out the ‘why’. But that’s what user research is for. That is the catch.

Photo: Guillaume de Germain