In ADPList mentoring sessions, I see a recurring gap: many designers describe what they produced but not the decisions they changed.
Senior-level stories show how the designer understood the problem, tested an assumption, navigated a tradeoff, and improved the result. That frame reveals how someone works with a team—not only how polished their screens look.
Two ways to describe the same project
Consider two illustrative versions of the same project.
Version one: "I redesigned the onboarding flow. I did user research, created wireframes, iterated based on feedback, and delivered high-fidelity screens. The team implemented it and the metrics improved."
Version two: "We had a problem where 40% of new users dropped off by step three. The team assumed users did not understand the value, but interviews revealed a navigation problem. We removed two steps and rebuilt the flow around one decision per screen. Engineering shipped it in half the time because we reduced the scope. Drop-off fell from 40% to 12%."
These examples are illustrative. The numbers show how specific evidence changes the story.
The second version makes the designer's contribution visible. It shows judgment, evidence, and an effect on both the user experience and delivery.
Your story reveals how you worked
"I delivered screens" describes a handoff. "We learned X, so we chose Y" describes participation in a decision.
That distinction matters at senior levels. Teams need designers who can understand constraints, navigate tradeoffs, and shape what gets built.
This frame cannot be added at the end as portfolio polish. It comes from working close enough to the problem to answer a simple question: What did the team learn or decide because I was involved?
Three shifts that matter
From delivery to decision
"I designed the dashboard" tells the reader what you made. It does not explain why the work mattered.
A decision-led version might say: "The team needed to surface critical information without overwhelming clinicians. We tested three approaches and found that a tiered layout reduced cognitive load by 30% compared with a flat grid."
The first statement shows production. The second shows how design improved a decision.
From volume to learning
Research matters when it changes the team's direction. Show the initial assumption, what you learned, and what the team did differently.
For example: "User testing showed that our mental model was wrong, so we shifted the focus from feature X to integration Y."
That story shows adaptability. It presents design as an investigation, not a production line.
From collaboration to tradeoff
"Collaborated with engineering" says little because nearly every product project requires collaboration. Name the decision the collaboration produced.
For example: "Product needed to ship by Q3, so we prioritized the core flow and deferred personalization." This makes the tradeoff, timing, and contribution clear.
Why the frame matters beyond an interview
This is not a storytelling trick. Designers earn influence when they participate in the team's decisions, and strong project stories make that work visible.
If a story lacks the research finding that changed the direction, the constraint that forced a compromise, or the assumption the team corrected, look at the work itself. The portfolio may not be the only problem.
I have written about four ways designers earn influence. This is the same idea applied to a project story: show the reasoning that helped the team move.
At a career crossroads, ask: Can I describe my last project through the decisions I helped the team make?
If the answer is no, change the operating model before polishing the case study.