Blog

I’m the scrum master for a small team developing a new service for a government agency. The team has been working in an agile way for 20 months. I have been with them for 15 of those months.

Our team is made up of user researchers, a designer, a BA, developers and testers.

Dealing with users isn’t new to me, before joining my current team I worked in IT operations and service management, dealing with angry and frustrated users was a day to day part of the role.

However I have found user research to be one of the most frustrating parts of my current role. When a new feature is being misused, panned or worst of all ignored I can see the frustration on the devs and testers faces.

They have put effort and care into nurturing this feature into existence and making sure it passes all tests and doesn’t make anything blow up. You can see them willing and hoping or worse praying that a user behaves in the way we expected them to.

Users never do.

How it feels to watch a user test your product for the first time. pic.twitter.com/WqYqYoxmfq

— Farbod Saraf (@farbodsaraf) August 9, 2016

…but you should do it anyway.

If being a product owner is about delivering the best product you can, being a scrum master is about developing the best team you can.

A bad user research session can be terrible for morale and badly handled can lead to friction in the team.

But you should still do it.

User research takes a bit of getting used to, especially if you come from a requirements driven waterfall background but it has saved our service many times.

The first time I became aware of it’s power was when the team were building a payment platform.

We were using a shared platform with other services and were concerned about how the change of style would affect peoples perception.

We started worrying about how we would reconcile branding our service versus having to regression test all our current services if we did change the style.

We gritted our teeth and tested the service with the current payment platform with no style changes. We expected to get destroyed we thought they style jump looked crap, we worried that users would not trust the service, we thought it looked terrible and jarring.

Users didn’t bat an eyelid.

Most responded with comments such as:

‘Oh this uses worldpay I know that.’

We totally misjudged reactions and as a result we saved a ton of work restyling and regression testing our payment platform.

User Research is a team sport.

So user research makes you want run into the room screaming JUST CLICK THE BUTTON RIGHT THERE!!!

But expose the team to it anyway, it teaches humility, it teaches us to question why we are building the things we are building, and it teaches us to think ‘what would I do in a user shoes.’

So how do you do effective research without the team breaking down in tears every lab session:

1. Stay respectful, User researchers are just the messengers, devs are just doing the best they can with what they know at the time. Stay respectful when things go wrong.
2. Take the dev team to labs as often as possible or if not get a live feed going.
3. Get video feedback to the team as quickly as possible. UR feedback is important but there is nothing better for investigating strange bugs or behaviours than seeing it happen (make sure a clock is visible in the video to compare events to log files).
4. Make the time to feedback research findings and modify the backlog as a result.
5. If possible test features in live, it is better to deploy a feature that can be improved than not to deploy and test in a less realistic environment. You can also reinforce UR findings with wider analytics evidence.
6. If you are a product owner take your stakeholders to user research, let them see the consequences of decisions, how well or badly a user responds to what can feel like a good idea in a boardroom or stakeholder workshop.
7. Keep testing the full service, you may want to focus on a particular feature but you always get feedback about existing features and how they all work together, does the whole flow still make sense?