Decision-Shaped Stories

The feedback that changed how I prepare for interviews came from a debrief I gave myself after a flat one. I had walked the panel through a project methodically: the research, the wireframes, the iterations, the handoff. Everything was accurate. Nothing was memorable. The panel was polite and we parted ways. That version of me was missing something, and it took me a while to name what it was.

The issue was not my work. It was the shape of the story I was telling about it.

Process-listing versus decision-framing

When you describe a project as a sequence of phases, you are telling the interviewer what you did. Research, wireframes, testing, launch. The problem is that this shape is identical for every project, and identical for every designer. It gives the listener no point of differentiation and nothing to evaluate. It is accurate and forgettable in equal measure.

A decision-shaped story is built differently. It names a moment where two reasonable options existed, identifies what you chose, states what you gave up, and says what happened next. That shape is specific to you, to that project, to that call.

The structure sounds simple. In practice, it requires finding the hardest moment in the project and making that the spine of the narrative, not the background.

Why interviewers are listening for decisions

A panel reviewing candidates is not trying to understand your process. They already know what the process looks like. They are evaluating judgment: whether you can read a situation, weigh competing constraints, and make a defensible call when reasonable options are in conflict.

Judgment is only visible at decision points. It does not show up in the phases between them. When you describe research you conducted, you show thoroughness. When you describe a wireframe you made, you show craft. Neither of those reveals judgment. What reveals judgment is the moment you chose one approach over another and can explain why, what you gave up, and what it cost.

That is what the interview is designed to surface. A process walkthrough does not give the interviewer anywhere to find it.

The question I now start with

When I prepare a project story for interviews, I no longer ask myself "what did I do on this project?" I ask: "what was the hardest call?"

Usually there is one moment that stands out. The research pointed in a direction that conflicted with what the product team wanted. Two interaction patterns both had real tradeoffs and testing was inconclusive. A constraint arrived late and forced a rebuild of something I had already shipped internally. These moments are uncomfortable to sit with during the project. In an interview, they are exactly where the story gets interesting.

I look for the decision that had a real cost. Not "we considered two options and chose the better one." The better version names what was lost: the feature that got cut, the user need that got deprioritized, the timeline that got extended. Cost makes a decision real. Costless decisions are just choices.

What the framing does for the listener

A process story asks the interviewer to follow along. A decision story asks them to engage. By the time you name the options, a good listener is already forming a view on what they would have done. When you reveal your choice, they are comparing notes. When you name the cost, they are checking whether you saw what they see.

That is a different kind of conversation. It feels less like a presentation and more like two practitioners comparing notes on a hard problem. And practitioners interviewing candidates are looking for that feeling.

It also makes the story portable. A project walkthrough only makes sense if the interviewer knows what the product was and why it mattered. A decision story is legible in any context: there was a fork, you chose a path, you understood what you were trading. That holds without background.

Preparing with this frame

Before any interview, I go through each project I might talk about and find its three hardest decisions. Not three highlights. Three calls. For each one I write: what were the options, which did I choose, what did it cost, what happened.

Four sentences per decision. Then I stop. The discipline is in not explaining too much. A confident decision story does not need extensive justification. It states the tradeoff clearly and lets the evidence speak.

The projects I thought were hardest to talk about turned out to be the easiest once I found the decisions. The complexity that made them difficult is exactly what makes them interesting in this frame.

The practitioner a panel wants to hire is the one who can name the moment things were genuinely hard and explain what they did there. Three decisions per project. That is where the story lives.