Quick note from me
I went quiet for a bit, because I was traveling around China. But coming back to reviewing portfolios for hiring processes in startups and helping designers with their interview preps, I see progress.
More designers are trying to tell story-driven project stories. There are fewer walls of process, but most still operate around action steps. "I did this, then this, then the project got sunsetted."
They separate themselves from the decisions and from the results, like they're afraid of something. Projects are messy and it's hard to share stories about them, especially after a while.
Below, I'm sharing 5 shifts to help you prove your project ownership without hiding behind process steps.
Story outline
Shift 01: Tell a sequence of decisions, not a sequence of screens
Shift 02: Show the invisible work
Shift 03: Zoom into the change and explain the decision
Shift 04: Make impact legible with before, after, evidence
Shift 05: Build ownership snapshots
Shift 01
Tell a sequence of decisions, not a sequence of screens
Execution sounds like: “I did research, then personas, then wireframes, then UI” or “I designed this feature, then this one, and that one”.
Ownership sounds like: “I noticed X. I chose Y over Z. Here’s what it cost. Here’s what changed”.
For design stories, I use my problem → change → retrospective framework.
The general UX project story framework:
Problem: what was the user and business problem, what was at risk
Change: what transformation options you suggested, what you chose and why, what you gave up
Retrospective: what changed for user and business, what you'd repeat or avoid
If your case study doesn’t have all three, it’s a process document and not an ownership story.
Example: Problem → Change → Retrospective
Shift 02
Show the invisible work
If you only show artefacts, you look like execution. Ownership lives in the stuff that doesn’t make it into Figma.
Defining the problem when nobody else will
Aligning stakeholders on scope
Choosing constraints and living with them
Pushing back politely on bad requests
Turning feedback into a better decision, not another iteration
One line you can drop into any case study:
“The hardest constraint was X, so I decided to Y”. That one sentence signals more maturity than a screen of polished UI.
One-liner example
Shift 03
Zoom into the change and explain the decision
As a hiring manager, I listen for the change. That’s where ownership lives, and that’s where most portfolios or interview answers go vague.
Inside the change, zoom into 2 to 3 decisions. For each one, use the framework below.
The UX decision story framework:
Context: the specific situation in the project (e.g. quick fix vs full redesign, how much research before committing, user segment, JTBD)
Tension: what made this hard (constraint, conflict, ambiguity, risk)
Options: what you considered (pros and cons)
Trade-off: what you picked and what you gave up (why)
Consequence: what it unlocked or prevented (for user, business, process etc)
One project story usually contains 2 to 3 decision stories like this.
Decision framework example
Shift 04
Make impact legible with before, after, evidence
You don’t need numerical metrics, but you definitely need contrast. This is how you fill in the consequence of a decision and the retrospective of a project.
Before: what users and business were experiencing
After: what became easier, faster, safer etc.
Evidence: tickets down, fewer handoffs, faster onboarding, adoption up, higher task success
“I improved the UX” is not a story. “Onboarding went from 11 steps to 4 and as a result setup tickets dropped by half” is.
Contrast example without numerical metrics
Shift 05
Build ownership snapshots
The highest-leverage thing you can do before a job search. Snapshots combine both frameworks from above. The top level framework for the full project story is problem → change → retrospective, and the meat is the decisions.
The ownership snapshot framework:
Headline: one sentence that names the decision
Use when asked: ambiguity, stakeholder pushback, influence without authority, hard trade-offs etc.
Problem: what was happening, user and business problem
Change: 2 to 3 decisions, each with context, tension, options, trade-off, consequence
Retrospective: consequence of all decisions, impact on user and business, and what you'd do differently
One snapshot feeds an interview answer, a portfolio story, a case study presentation. Tag each one by theme so you can pull the right story fast. Most people freeze because they're searching their whole career for an answer. Create a master file, a database with snapshots so that you can have everything prepared.
Ownership snapshot example
🫶 Together with Granola
The AI tool that doesn't want to be the hero
I test new AI tools almost every week. Most I delete within a day. Granola stayed. For over a year now, because it makes every other tool in my stack work better.
Why I keep it open every day:
It's an AI notepad - It transcribes every call in the background and there’s no bot joining my meetings
Type / in any note to pull up a recipe with prompt library: follow-up email, summary, todos
It connects to Figma Make, Claude, Notion. So my notes turn into briefs, decks, prototypes without me copy-pasting anything
Every other AI tool I use got better because Granola sits in the middle of them.
Try Granola on your next meeting. Get 1 month for free on any paid plan
My Designer Toolkit 🛠️
Tools I actually use in my workflow. Some links support this newsletter.
Want help with your UX portfolio? 🎁
Build your UX Portfolio with this course
Book a portfolio strategy call with me
Questions? Reply directly.
Keep designing ✨
Aneta
