How to Talk About Research Impact in a Design Portfolio¶
Open ten design portfolio case studies and you'll see the same pattern in most of them: a "Research" section that says something like "I conducted user interviews and a competitive analysis," followed immediately by a "Design" section showing the final screens. The research is present, technically - it's just not doing anything. There's no visible line between what it revealed and what changed because of it, which means a hiring manager reading it can't actually tell whether the research shaped the outcome or just happened alongside it.
The Gap Between Mentioning Research and Showing Its Impact¶
Mentioning research answers "did you do it." Showing impact answers a different, more valuable question: "did it change your mind about anything, and can you tell me exactly what and how." The second question is what a hiring manager is actually trying to assess, because it's evidence of a real skill - synthesizing messy human input into a specific design decision - rather than evidence that a research step existed somewhere in the process.
What Actually Demonstrates Impact¶
A specific finding stated as a finding, not a summary of activity. "Users struggled to find the export function, mentioning it in 6 of 8 sessions" is a finding. "I conducted usability testing on the export flow" is an activity log. The first tells a reader something true about the world that they didn't know before reading it; the second just confirms a step happened.
A visible fork in the design, with the finding as the reason for the turn. Show the version before the finding and the version after it, with the finding sitting explicitly between them as the reason one became the other. This is the single highest-leverage thing a case study can do, and it's the thing most case studies skip - not because it's hard to show, but because it requires admitting the first version wasn't right, which feels more vulnerable than presenting a clean, linear story where the final design was obviously always going to happen.
A number or a direct quote, not a vague characterization. "Users found the onboarding confusing" could mean almost anything. "3 of 5 participants abandoned the third onboarding screen without completing it" tells a reader exactly how confused and about exactly what. If you don't have a number, a specific quote does similar work - it's concrete in a way a paraphrased vibe never is.
An honest account of a finding that didn't get acted on, and why. Every finding doesn't make it into the final design - business constraints, timeline, competing priorities all get in the way sometimes. Saying so directly ("we knew this was a real issue but shipped without addressing it given the launch deadline, with a plan to revisit post-launch") reads as more credible than a case study where every single finding conveniently led to exactly the right design decision with no friction anywhere. Real projects have friction; a case study with none reads as sanitized rather than impressive.
A Structure That Makes This Easy to Show¶
Rather than a single "Research" section followed by a single "Design" section, structure the case study as a sequence of finding-then-decision pairs: what we learned, what we did about it, repeated for each major turn the project actually took. This format makes it structurally difficult to skip the impact step, since each finding is immediately paired with its consequence rather than filed away in a research summary that the design section never has to reference again.
FAQ¶
What if my research didn't actually change anything about the final design?
That's worth being honest about rather than papering over - say what you learned, and say directly that it confirmed the direction you were already taking rather than changing it. Confirmatory research is still real research, and claiming a change that didn't happen is the kind of thing that falls apart under a follow-up question in an interview.
How much research detail is too much for a portfolio case study?
Enough to support one or two concrete findings that clearly connect to a design decision is usually enough - a portfolio isn't a research report, and drowning a real finding in methodology detail buries the exact thing you're trying to make visible.
Should I include a finding that made the project worse or more complicated?
Yes, if it's honest and you can explain how you handled it - it demonstrates judgment under real constraints, which is a more valuable signal than a project that reads as if everything went smoothly the whole way through.