My report answered questions before anyone asked them
I applied multiple perspectives to a focus group report with ten support staff at a telehealth startup. The product manager, user researcher and design lead views added priorities, evidence checks and a clear design direction, so the report answers stakeholder questions upfront.
3min read
A report isn’t finished when I’m happy with it;
It’s finished when the people who read it can act on it
| Context |
When I finish a research report, I usually feel done, but a few minutes later the first question came back: “So what do we fix first?” the product manager asks. The design lead asks what it means for the screens. And I go back to my notes again.
Recently I joined an online masterclass workshop from IxDF by Rafael Hernandez, and one technique stayed with me: add multiple perspectives from different roles to your design process. Before you share your work, look at it through the eyes of the people who will use it.
I learned two main reasons for doing this:
It saves time. If my work already answers the questions a product manager or design lead would ask, we skip a lot of back and forth.
It makes my output more reliable. Each role notices details I could easily ignore on my own.
How I applied it
I tried it on a report from a focus group with ten customer support staff at Dr.Saina, a telehealth startup. They shared the problems patients face when they call or use the platform. The first part of the report was my usual analysis: pain points, staff suggestions, insights and next actions. Then I added three sections, each one written from a different role’s point of view.
The product manager asked where money leaves the system. This section ranked the problems as Now, Next and Later, based on severity and business impact. It also named trade-offs. For example, telling patients about doctors’ off-hours before they pay could mean fewer refunds, but it might also lower conversion at checkout. It listed outcomes to track, like refund rate by reason, and admitted that none of them has a baseline yet.
The design lead turned the findings into one direction: make the promise clear before payment, and the status honest after it. It mapped where the journey breaks and listed the states to design, like payment pending, failed or booked, and refund requested, in progress or paid. It also pointed out something easy to miss: support staff are users too. Their internal tools belong in the design scope, not only the patient app.
An Important Point Here
I wrote these perspectives as a skill, and it covers more roles than the three I used here: a user researcher, a junior designer, a design lead, a design director and a product manager. I built it this way so I can adjust it for each project and pick only the roles that fit. For this report, the user researcher, the design lead and the product manager were the ones I needed.
What changed
The report got longer, but not heavier. It now answers the questions my stakeholders would ask before they ask them, so the conversation can start from decisions instead of clarifications. It’s also more honest. It shows what we know, what we’re only assuming, and what we still need to check with real data, doctors and patients.
The biggest lesson for me: good research isn’t only about what users say. It’s also about what the people around the table need to act on it. Now, before I share my work, I want to ask myself one question: who will read this, and what will they ask me?
Want to Contact?
I’d be happy to meet for a coffee or have a chat online.
