The challenge is to identify which one is right for the problem you want to solve and to allocate sufficient time to run it and get value from it.

User Research Myths

When you introduce User Research to an Agile Team, you’ll hear things like this,

“Going in depth takes too long”

“It’s somebody else’s work”

“Oh no, that’s expensive”

“It’s very difficult”

“We’re an Agile team, there’s no time in this Sprint”

These myths are the result of a shipping mentality. Work is rewarded based on how many features are shipped and not on how much we are changing user behavior towards our business goals.

Typically under Agile there is no distinct discovery step. Discovery research and requirements are oftentimes conflated. Development is guided by a mock that may or may not reflect what users really want.

Typically this “discovery” work does not have an owner. There is no dedicated time to explore users’ motivations, expectations, or how they use your product. At best, product owners come up with design specifications barely in time before development starts.

Breaking the Myths

To incorporate User Research activities in your Agile process the whole team must shift to a user-centric vision of the product. Change begins when learning about users is at the core of their work. Yes, you will still ship features, but these will be aligned to change user behavior and improve the product.

1. Test small hypothesis

Evaluate small portions of your product by formulating a hypothesis on how to solve a problem with a new design or feature. For instance, you could say, “In order to lower support tickets by 30%, we could add a moderator role to the interaction.” (We have a webinar about this)

All of a sudden the work changes. Now the goal is to reduce tickets, not shipping a particular feature. This means that the team will explore options like creating a moderator role. They can research that simple idea with customers.

Test small and often.

2. Assign the discovery work

In order for UX Research activities to be taken seriously, they have to be visible and be prioritized. It has to be included in the backlog. And it can’t be ignored.

This is another step to shift from a culture of delivery to a culture of learning.

3. Customize the activity

The fast pace of the Sprints might not allow to go deep into user research. You must get creative about the methods you use. For example, you can test the usability of a small portion of the product with regular interview questions. This way you maximize the time.

You can also recruit users familiar with the product so they don’t spend tons of time going through the learning curve.

You could schedule regular research sessions with users. This makes it a weekly routine and everybody knows it’s “User Research day.”

In the end what matters is applying the right technique to find the answer to your question.

4. Involve the whole team

To build a shared understanding of the user problems there’s no substitute to inviting everybody from the team to the sessions. Witnessing users struggle with the product will motivate people to go and fix it immediately.

Ideally, instruct others to run the sessions themselves. Initially they could take notes, speak to the customers, and ask single questions. Over time they will get so used to the process and will be capable of running in on their own.

Tips for On-site Teams

Atlassian did a great work building their own User Research lab. Theirs is by no means an expensive, fancy lab. It’s more about creating a space where this discovery work can be done. More than that, it is creating the right team mentality around user problems.

User Research within Agile is Possible (and Desirable)

It will take time, but you can help your team integrate the voice of the customer into their work. The time spent making this happen is worth every second.

Everybody from your team will benefit,

Product Managers will save money. They can make sure they’re building the right thing, and they will save time to keep grooming the product even further.

Designers will be confident about their design decisions. They will have a better understanding of the problem, and they will constantly validate their assumptions with real users.

Developers can see their work being used in the wild. They can ideate alternative solutions to the problem being observed, and they will develop empathy for the mere humans utilizing what they produce.

You cannot create meaningful solutions without customer input. And people simply won’t buy products that don’t fit their needs.