The design and research communities are very close in Hippo — we have open-door policies for our community meetups, and more often we’ve been delivering “mash-ups” — where two people from different specialisms come together to solve shared problems through discussion.
Recently, two of my colleagues ran such a session, exploring the relationship between designers and researchers; aptly named “brutal honesty”. We were asked to reflect on a number of questions and post our thoughts down on a Miro board. Questions included for reflection included:
“What’s the best thing you’ve ever seen a designer/researcher do?”
“What skill would you like to learn from a designer/researcher?”
“What’s the one thing that designers should know about researchers?” (and vice versa)
“I cringe when….”
“The thing that no-one’s dared tell designers is…”
The open feedback culture we have within Hippo and these two communities mean that everyone was very honest and open about their experiences in a constructive way.
One set of responses stood out for me (and I include one of these responses as my own):
Adding in “recommendations” to user research playback decks has been standard fare in many (if not all) government teams I’ve worked in — in fact, when given client template decks to use, they often include a pre-written placeholder slide titled “recommendations” or “recommendations for design”. I have only started thinking about this as something problematic recently, and this is why:
- I am not our users
My job as a user researcher is to enable my team to better understand our users, their behaviours, motivations, barriers and goals. Once that had been achieved, any possible iterations or ideas for solutions should come from the team after a discussion. I do not ‘own’ user insights.
2. I am not a designer
I am not a designer. Heck, I barely scraped a C grade in GCSE art. By making design recommendations, I am bypassing the knowledge and expertise of my colleagues. I am making assumptions. Jumping to “you should fix this in this way” instead of “let’s discuss why we think this is happening and what our options might be” is not only likely to get my design colleagues’ backs up, but we’re also missing the deeper picture.
3. Solutionising closes doors
If I make design recommendations, it frames the findings in a specific way from the get-go.
The risk here is that people’s thought processes fixate on these solutions “Make this bold! Move this button! Change this copy!”, rather than us being able to be imaginative and creative in how we approach problem-solving. We might miss opportunities if we have a narrow perspective.
So what do we do instead?
A research playback is like a story — you have a beginning (what were we trying to find out, who did we speak to, what did we do), a middle (findings, observations, insights), and an end (traditionally, ‘recommendations and next steps’). The ending is the “so what” part — as researchers we want people to listen to our findings, we want them to empathise with our users, and we want our colleagues to help us fix the problems our users are encountering. But a research playback is not the time to “fix the thing”.
I am planning on removing all “recommendations” from my playbacks from now on, and instead of using “How Might We’s”.
Most people in this space will be familiar with the use of “How Might We?” statements for design ideation, project kick-off meetings, planning sessions etc. A properly framed How Might We doesn’t suggest a particular solution, but gives you the perfect frame for innovative thinking.
I think they fit really nicely as an “ending” in research playbacks because they allow people space to think about the “what next” and it invites a future collaborative discussion between team members (not just design and UR) to think about “How might we respond to what we’ve learnt in this round of user research?”
“How might we respond to what we’ve learnt in this round of user research?”
You can e-mail me at [email protected]
