Feedback Meets Fan Fiction
An analogy for giving constructive criticism with heart
Some details of the topic have been altered for confidentiality.
One of the first design research projects I worked on was to create a journey of creating an emotionally sombre and serious gathering in a digital space. The digital part was new for the client, so there were many pain points to map between the known offline version and the unknown online one. In the final presentation, I did what I traditionally do: share the motivation and scope, approach, user stories and pain points, key design principles, and the recommended core features of the new service.
After the presentation, we had around of feedback. I remember one of the attendees — an advisor and long-time collaborator of the client — commended the effort, asked thoughtful questions and at the end, he said something that stuck with me for years until now. To paraphrase:
The insights were great, but I wonder if there could be some happy moments in the user journey as well?
At the time, I didn’t quite know how to take the comment. On the one hand, I was a little confused, perhaps even annoyed, that out of everything that I’ve done, he chose to highlight the part that wasn’t in the scope. The point of the project was to create a new service that maps the seriousness and formality of the event into the virtual space. There was no room for overtly happy moments, I thought.
On the other hand, I blamed myself for missing this important part of the human experience. Addressing pain points doesn’t mean we should forget the more positive moments. Even though this particular type of gathering would involve tears, sometimes happy memories are shared with each other too. Isn’t part of the designer job to make life a little better?
For a long time, I didn’t know how to process it.
There are many reasons why someone would give feedback. A client could give feedback to help direct the researchers to explore potentially meaningful areas of knowledge, or to provoke discussions around certain contentious areas of disagreements. For product teams, feedback serves to steer the direction of future features of a product, and comments should be as specific and actionable as possible. Functionally, feedback is about communicating a desired direction of attention.
As a design researcher, my job is to immerse ourselves in the stories of our users and help my partners — startups, venture builders, policy makers, educators — make better decisions about their products and services. Any research I do is a collaborative process, where I share the pains and insights on behalf of the users, and partners would make decisions on what they will prioritize on addressing.
A big part of my job is thus to bring our partners along and into the lives of our users to understand the insights in their specific contexts — and to discuss details within a certain scope of the research, lest we slide into
“whataboutism” that risks bringing irrelevant information to the discussion.
In my case, I probably had failed to paint the full and vibrant lives of the people that I interviewed about organizing these emotionally-charged events. After all, an empathetic view of any human experience would surely include the good parts as well as the painful points we want to avoid.
But I also wasn’t sure what to do with that feedback either. If the scope of work was to think about how we can make serious online gatherings seamless and pain-free, then designing deliberate happy points along the user journey can be rather relevant. It took me years to understand that I was a bit hard on myself, that the comment was probably a curious “what if…” thought spoken out loud.
How, then, should we think of feedback?
It’s important that you understand the reasons for why you are giving feedback and how the feedback will be used and useful. If I was giving feedback, I would think about the big picture questions of the project itself, and try to address that objective when engaging with the insights.
I would think about the desired outcome of the project: Why are we doing this user research? What decisions are being made with these insights? I might also think about the process of arriving at the insights: What is the methodology used and why? (Though this should really be agreed to before any research is done). What evidence led to particular insights? Do the implications of the insights to our work make sense?
I imagine that a big part of giving feedback must feel a little like writing a good fan fiction, where you have to first really immerse yourself in the original story and swim in all the dirty details before forming an opinion.
You must first discover why are the characters afraid of certain things, or feel sad in some moments, or the actions of that led the readers to a particular conclusion. You can think about the journey that the users are on: is it a rags-to-riches story you are trying to accelerate or a tragedy yearning to be rewritten? Only when you understand the stories do you get to put your own spin on the source material into ways that is meaningful for you.
As a client or partner, this doesn’t mean you cannot have a personal opinion on the project, more so that your opinion should be refracted through the lens of the users’ stories. You can give feedback to add to the richness of the stories, to spot the gaps in the researcher’s reasoning, to point out potentially meaningful threads to pull on. These objectives will help set a stronger foundation for whatever product or service your team is going to develop next.
Practically speaking, when I do give feedback, I try to be ultra careful to stick within the scope of the work and ask questions that are specific to what’s in front of me (e.g. can we follow-up on this question you asked in the next interview, or can we revisit how you arrived at this insight?). I try to give suggestions that are as actionable as possible (e.g. let’s create a new way to visualize this data, or can we talk to this other group of users instead). I try to link the feedback to the decisions I would need to make. I try to make it clear that when I “wonder” about something, sometimes it is not necessarily useful to this project.
I am confident that there is a mountain of literature on how to give good feedback and how to communicate well interpersonally (I find Connect a particularly helpful read). At the end of the day, I just wish that feedback given is a token of trust that reaffirms how, in any good project, the client and the researchers are really on the same team.
