EN 28: When was the last time you talked to a user?

Hi 👋 ,

I was thinking this week about one of the times I’ve talked to a user.

Looking back at the conversation, there was no preparation whatsoever. I didn’t know about it until it was happening. There were no interview questions to uncover opportunities (user needs, pain points, desires…) and it was, in the end, a casual conversation with no focus and no particular insight was gained from it. There were a few typical mistakes:

• Leading questions

• Narrow and close-ended questions

• Asking the user what they think about the product or what they want us to build

Generally, in that type of interview, we want to ask interview questions to make users tell us stories. Stories about how they use the product, how they do certain activities in their life that we care about, the challenges they are facing in a particular situation, etc. From the stories we can gain a more profound understanding of our users and see potential needs, pain points and desires. Why stories? Because if you ask them what you really want to know, they won’t tell the truth, not because they lie, but because people are heavily biased. They can tell the solutions they think they’d want, the things you want to hear… Remember that users are not experts in the solutions, they are only experts in their own problems.

Coming back to the interview, a type of question that was used a lot was the close-ended question, questions like “do you like the product or feature X?” that will normally get you a yes or not, and then you have to follow up with a why. Even if they answer why, while some answers could be good, some could be biased. A similar thing happens when asking a user things like “what did you like about feature A?” A better situation would be to get the user to elaborate on an experience around the feature or the product. That way, they can explain what they did and thought in detail, as well as explaining the context in which it happened. The typical “tell me about a time when…”.

As a developer, it’s depressing to think about the times I’ve talked to a user or had the chance to understand them. I can easily count the times I was directly involved in an interview with one hand. What’s concerns me is the general and accepted lack of empathy for the users we except from the people that design and create products. Yes, a PM, designer or UX research might do interviews, but it’s not something that tends to trickle down to developers.

The fact is that having developers come in early in discovery is a game changer. I say developer here because it’s the role that gets forgotten in discovery by default. Designers can face the same issue and suffer the same destiny as us “code monkeys”, becoming “UI monkeys”, specially with product management taking discovery responsibilities that designers have always been taught to do. I’m all for a software version of Rise of the Planet of the Apes.

One of my inside sources in schools told me a story the other day about the main software they use. It turns out that one day, after an update, they couldn’t do much of their day-to-day activities with the software, they only had permissions to do some tasks. Obviously, chaos ensued, and they were unable to do much with the software. Most likely, a team of developers or the product manager assumed certain tasks could only be done by specific people. I assume that no one in the team actually talked to any of their users to understand the school workflow, responsibilities of each worker, etc. otherwise they would’ve immediately realised that that change was not aligned with their users.

Now imagine what happens with other products that can be more critical or that are widely used in society. The famous situation of a hand dryer that only works on light skins, or airport scanners that only contemplate binary human bodies. Products and software can be used to discriminate or oppress, and it can be done inadvertently, and most likely there might not be an evil individual in the shadow. The systems in which the software is built is critical.

A question I’ve heard from product managers or some tech leaders is the following: how can I make the developers care about the product, the business, and the users? When I hear it, my mind immediately goes to their systems, the way they’re organised, their incentives, feedback loops, etc. As you might imagine, the developers in these situations typically are far removed from users or business outcomes. They don’t have a say in any feature built or the goals of the team, don’t collaborate or don’t have a share understanding. They generally only exist to produce code from tickets. It’s no surprise that devs won’t be the most interested in the business or the product. Still, plenty of them are keen to understand the users and the business, even thought the systems they work with don’t make it easy. In contrast, people with the most power or responsibility, involvement in the product or the business, and with the most information, will typically be the most engaged.

Interesting links