Calling customers, reading the comments and traces they leave and following up on their requests, questions and support tickets is a crucial way for product teams to stay on top of what’s happing on the user side on things. Listening in, in order to feed back to the rest of the team what users say, think, experience and struggle with is an equally important mechanism. It not only ensures that the user is heard, but also informs the product work to improve, fix and re-orient it in ways relevant to its users. That is, if it’s done right. Here are some thoughts and quick tips on how product teams can improve the user research they do.
1. Take more thorough notes of conversations with users
Seeing how some product teams take notes of their conversations with users (say, a follow up call), I get the impression that more than speaking for the user, the notes become an artefact of the team’s own world views. These notes tend to be rather short, chopped into bullet points and divided up into product-relevant silos with headings that match internal product lingo. By doing this, the team (unwillingly) let the users only say what they already believe to be true.
My quick tip: Try to make your notes more like a very light version of an interview transcript. Make them longer in word count and incorporate more details and verbatim, as well as entire sentence as you hear them from users. Infuse your notes with your users’ way of speaking and use the terms they use, especially if they appear to be the users’ own internal lingo and there’s something you’ve never heard before. Also, steer away from excessive interpretation as you write and edit your notes. Instead of organising the transcript into neat sections with headings, try and add your thoughts as ending notes or comments into the document. That way you keep your view and theirs more seperate.
2. Take product-off days
It doesn’t have to be a full day. Installing a recurring 1 hour weekly or monthly meeting into your team’s agenda will also do the trick (even better). This is about making time and space for your team to step back from their usual perspective and their day-to-day work on product roadmaps and features.
In this meeting, no one is allowed to refer to the product, let alone use its name. No one should make reference to the new add-on or feature that’s in the pipeline. Instead, take your improved customer call notes with you into the meeting and speak about the frustrations and problems that users go on about. Discuss why they’re so frustrated and what it must be like for them, in their role. Afterwards, feel free to ponder on what your team can bring to the table and how and what your product might or might not solve for them.
3. Do a closer translation: A user problem does not equal a single feature solution
Once you’ve carved out some time and space to just focus on the user and their way of seeing things, now it’s time to be more deliberate about the translation work that comes after. You’ve figured out the user side of things but putting that back to a product lens is not a straightforward process.
Very rarely does the need of a user translate neatly into one specific feature. It’s usually a series of options and alternatives – which is great! What teams need to do more of is actually talk about these alternatives. More than often, teams take the short cut, pick one of these alternatives as the most self-evident and close themselves off to better or just simply different solutions. That’s where good design sparring comes in. Individual features (e.g. a like button) should always be put to scrutiny and be up for debate, always linking them back to what prompted their discussion in the first place.
4. Just bring in a trained researcher
While reading through these, did some of these tips appear impractical or perhaps even a little bit ridiculous to be seriously considered in your team’s day-to-day work? I wouldn’t disagree.
A proper researcher is properly trained in their field, just as a designer is trained in their design field. Having someone with the appropriate expertise in the team not only reduces the workload for others but also means that others can focus on the tasks they were hired for. But more importantly, a team can seriously benefit from the constant duality of user perspective vs. product perspective. Someone who’s role is to be some sort of advocate and voice for the user can always be brought in to question and challenge product perspectives, and together with those who defend and maintain these perspectives, they can collaborate on moving things forward the right way.
Also, hi there, I just so happen to be a researcher.