Why should developers get involved in user research?

Sarah is a top developer. She writes code that has no bugs. Her tickets are well estimated, features well tested and when she’s in the zone, typing at 100 miles per hour, you can almost feel problem solving energy around her.

Amanda is a junior user researcher working with Sarah. She has a user research session planned and naturally wants to get her colleague involved.

“Hey Sarah”. She asked, waiting for her colleague to part with her headphones. “Would you like to be an observer in any of the user research sessions next week?” Sarah’s look of confusion was impossible to miss. It was as if she was thinking, ‘do you know who I am? Do you know how important the work I do is?’ After a few seconds, which felt like hours to Amanda, Sarah replied.

“Nah, I’m alright. Got a bunch of features to finish so I’ll probably get back to it if that's alright”. With that, Sarah put her headphones back on and got back to work.

I hope it’s clear that Sarah and Amanda are both fictional characters. This may sound silly but I felt similar to Sarah the first time I was asked to take notes during a user research session. ‘I might do it wrong.' ‘Can't someone else do it instead?' But after doing a lot of them, I can firmly say that it’s something all developers should do and I’m going to give three reasons why.

1. Straight from the horse’s mouth

There’s a game in the UK that school kids play called ‘Chinese whispers’. I don’t know the origin of the name but the way it works is that everyone sits in a circle, someone whispers something into someone's ear and then they do the same and then the next person does the same until they get back to the original person. You probably guess that the original whispered message would have massively changed by the time it goes around a circle. Adults are, for the most part, just big children and this happens to us as well.

If a developer is not involved in any of the research sessions and they get all the information from a user researcher who most likely analysed and compressed the information to the simplest form. There are little nuggets of secondary information that don't get passed along. Eye movements, body language, tone of voice. These are small but important when it comes to deciding what improvements should be made to a product.

2. Steer the conversation

This point carries on from the previous point a bit. As well as getting to see someone use a prototype or the tool that you have been working on, if your user research session hasn’t run over you usually get to ask the participant any question you want at the end.

I’ve always found this helpful not only so that I can question some of the decisions they made during the session but so I can ask tech-specific questions that would benefit a developer, for example; what browser do you use? What devices do you use more, your mobile or your desktop? How computer literate would you say you are?

3. Think more about the user when you’re building

Before doing any form of user research, whenever I developed a product, I always thought of the user as myself by default. This would be okay if I was developing a product for myself but most of the time I’m creating a product for other people who are most likely not like me. Observing multiple rounds of user research quickly changes that way of thinking because the issues that other people have will not be the issues I have, and the things they notice or ignore will be different to me.

One very specific example of this happened during my work on the electronic apostille project where we added a link to the bottom of a page for experienced users to skip some questions. If I were designing this for myself I would have left it as it was because I noticed the link at the bottom each time I used the site. However, during user research we discovered that nobody else saw it, so we changed it from a link to a whole page, and of course, it was difficult for users to miss.

Let’s face it, there aren’t many companies out there that do user research, and out of those companies, there are few that do it well, so it's highly likely that user research might be something you've never experienced. I think it’s great that Caution Your Blast is one of the few companies that do user research well and tries to get the whole team involved.

If you’re a developer who wants to use user-centred design in your next project or want to know how we do it at CYB I am genuinely down to have a chat with you.