Why We Bring Engineers to User Interviews
At some companies, user research is a lot like flossing: we know it’s good for us but we aren’t doing it enough. Here at Change, we floss all the time — and we make sure to floss together. This means that when we talk to users, we make sure that all members of the product team hear what they have to say. This includes the engineers.
There are many benefits to having engineers participate in user interviews, but they mainly fall into three buckets:
It creates empathy toward your users
Every developer has looked at error reports or logs and wondered aloud, “what the hell is this idiot user doing? They must be daft.” This is wrong. The best antidote to this toxic thinking is actually meeting your users and learning about how they use your product.
You start to have thoughts like, “oh, that link is kind of hard to find, isn’t it?” and “ouch, I never noticed how confusing that navigation is — I always shortcut it and manually enter the url.”
Your goal should be to have a mindset where you look at the error reports and think, “well, given that this user is not an idiot, what did we do to mess up their experience?”
It creates a common language among your team
Hearing feedback directly from a user’s mouth cuts through any mental blinders we may have when we only read research reports. No more can we say, “oh, I bet they didn’t mean it that way.”
In our case, both the lead engineer and product manager attend user interviews. This means that as we plan features, we can easily talk about “users like Ray & Ruth” or situations like “the Schlossberg dilemma.”
It energizes you!!
One good user interview can leave you with a “I want to build stuff for them!” attitude.
Having looked a user in the eyes and chatted with them can help you keep a high level of quality when you are working through particularly hard problems. I like to take it one step further and end the meeting by giving the interviewees my business card — then I’m definitely on the hook to build a good product.
Operational tips
I’m a fan of hacking my own habits to make myself more productive, so I wanted to include some guidance for any engineer attending an interview.
Be the note-taker
The person running the interview is focusing on the interviewee and digging out their wants and needs — they shouldn’t be taking notes. Typing up notes during the interview keeps you in the moment but too busy to speak much (see the next tip). Post interview, cleaning up & annotating the notes is a good way to review what was said and will help you retain the findings.
STFU — seriously.
User interviews are all about listening. Resist the urge to offer solutions, especially if the user isn’t using your product “correctly.” This is usually the hardest part for everyone (especially engineers) to do in practice.
If you have to speak, don’t stray far from “that’s interesting, tell me more about that.” If you see that the user is missing some important piece of functionality and you feel compelled to offer a solution, at least wait until the very end of the interview.
John Mertens — Principal Software Engineer
