There is a particular moment in senior design recruitment when an apparently straightforward interview becomes a small piece of theatre.
You have a portfolio. It contains several detailed case studies. The interviewers have the link. In theory, they have already looked at it. Yet the invitation arrives with a request to “walk us through one or two projects”, and somewhere between the calendar description and the first interview, an invisible PowerPoint materialises.
Nobody necessarily says that you need a deck. They may not specify the number of slides, the shape of the story, or the amount of time you should spend describing discovery before arriving at the interesting bit. But in larger organisations, especially when interviewing for senior, lead or principal roles, there is often an unspoken expectation that you will arrive with a polished case-study presentation and deliver it like a calm, commercially literate documentary.
This is not entirely unreasonable. It is, however, unusually good at rewarding people who already know the ritual.
Your portfolio and your presentation do different jobs
A portfolio is designed to be explored. A good one lets a reader move at their own pace, inspect the details that interest them and skip the parts that do not. It can show breadth: different sectors, different problems, different kinds of design work. My own case studies are built for precisely that kind of browsing.
A presentation is designed to be performed. It is linear, time-bound and social. It has an audience who may interrupt. It must survive screen sharing, nervous pacing, a late-arriving stakeholder and somebody asking, twelve minutes in, whether you considered a completely different business model.
These are not the same artefact.
When I have walked interviewers through my portfolio, I have sometimes felt that I was presenting perfectly useful evidence in the wrong ceremonial container. The work was visible. The decisions were documented. The outcomes were there. But the interview seemed to be testing whether I could turn that evidence into a particular kind of spoken narrative.
At senior levels, that distinction matters. The panel is rarely assessing screen-making alone. They are listening for judgement: why this problem mattered, what you chose not to do, where the evidence was weak, how you brought people with you and what changed because of the work. A deck can make those decisions easier to see. It can also make an ordinary project sound remarkably heroic, which is where things become slightly less scientific.
The hidden curriculum of the case-study deck
People who have spent years around large design teams often learn the format by osmosis. They have seen promotion reviews, design critiques, quarterly business reviews and conference talks. They know that a senior case study usually needs a recognisable rhythm:
Here was the situation.
Here was the important problem hiding inside it.
Here was my role and the complexity around it.
Here were the decisions, disagreements and trade-offs.
Here is what changed.
Here is what I learned and would do differently.
Nobody hands you this sequence when you enter the profession. It is simply waiting in the room when you apply for a bigger job.
That creates an access problem. Designers arrive through increasingly varied routes: graphic design, research, engineering, service design, operations, customer support, bootcamps, self-teaching and careers that did not previously contain the word “design” at all. Some candidates have been coached by experienced managers. Others have only the job description and a portfolio they built at midnight.
If the interview depends on knowing an unstated format, it measures familiarity alongside ability. Those things overlap, but they are not identical.
The same problem appears elsewhere in hiring. Research on structured interviews consistently finds that clearer, more consistent questions improve the quality and fairness of assessment. Google’s re:Work guidance, for example, recommends structured interviewing because candidates can be evaluated against the same criteria rather than a collection of impressions. Yet the design presentation is often left curiously unstructured: “Show us some work” followed by private expectations about what good looks like.
What the panel is actually trying to learn
The useful response is not to dismiss the presentation as corporate pageantry. A well-run case-study conversation can reveal things a portfolio cannot.
The panel wants to see whether you can create clarity from complexity. Senior designers spend a surprising amount of time explaining difficult things to busy people. Can you identify the decision that matters? Can you give enough context without recreating the entire company history? Can you distinguish your contribution from the achievements of a capable team?
They also want to understand your judgement under constraint. In my work on refining operations with artificial intelligence, the interesting story is not simply that an AI co-pilot was designed. The useful evidence sits in how customer interviews were translated into actionable product decisions, how uncertainty was handled and how the interface supported consequential work. A screenshot can show the result. A conversation can expose the reasoning.
Similarly, a design-system case study such as building ShipServ’s design system is not really about a library of components. At senior level, the questions are about adoption, governance, compromise and the slow business of making consistency useful rather than merely tidy.
A strong presentation therefore does not recite the portfolio. It edits the work around the panel’s unanswered questions.
The decisions are the case study
Many case-study presentations devote ten slides to process and one sentence to judgement. There are photographs of sticky notes, reassuring diamonds and a workshop in which everyone appears to be pointing at a wall. The candidate says they empathised, defined, ideated and tested. The panel waits politely for something to happen.
The memorable material is usually a decision:
We thought the problem was speed, but interviews showed it was confidence.
The elegant interaction failed because it hid operational responsibility.
We removed a feature because the exception handling cost more than the value it created.
Two teams wanted incompatible outcomes, so we changed the service boundary rather than decorating the disagreement.
The prototype did not validate the concept; it exposed the assumption we had failed to test.
Decisions reveal your standards. They also allow the panel to disagree with you, which is useful. A senior designer is not expected to have operated in a world where every workshop produced alignment and every usability test confirmed the prototype. They are expected to notice friction, make a defensible choice and adapt when reality objects.
This is why “we” and “I” both matter. “We” acknowledges that serious product work is collaborative. “I” tells the panel what they would be hiring you to contribute. Use “we” for the outcome and “I” for your responsibility: we changed the quoting workflow; I identified the repeated hand-off failure, framed the options and led the team through the trade-off.
A practical way to prepare without becoming a conference speaker
You do not need to transform every project into a forty-slide epic. In fact, please do not.
Choose one case study with enough complexity to demonstrate the level at which you want to work. Build a short narrative around five questions:
1. What was genuinely at stake?
Describe the business, user or operational consequence. “We redesigned the dashboard” is an activity. “Operations teams could not tell which failures needed intervention, so work was delayed and accountability was blurred” is a problem.
2. What did you personally make clearer?
Senior contribution often happens before the interface. Perhaps you reframed the problem, corrected a misleading metric, changed the research plan, challenged the roadmap or connected teams that were optimising different versions of reality.
3. Which two or three decisions best demonstrate your judgement?
Do not present every artefact. Present the evidence required to understand the decision. A rough diagram with a meaningful consequence is more valuable than six immaculate screens without an argument.
4. How did the organisation affect the design?
Products are built inside companies, not in the serene vacuum of a portfolio mock-up. Explain the approvals, technical limits, policies, incentives and operational habits that shaped the result. This is especially important in enterprise work, where the organisational interface is often more complicated than the product interface.
5. What would you change now?
Retrospect is not an admission of incompetence. It demonstrates that your judgement continued developing after the launch. The suspicious case study is the one in which the candidate made every correct decision in precisely the correct order.
Then rehearse to time. A useful rule is to prepare less material than the slot appears to allow. A thirty-minute session does not contain thirty minutes of uninterrupted presentation unless the panel has been replaced by unusually courteous furniture. Leave room for questions and decide which sections can be shortened without making the story collapse.
What hiring teams should say out loud
The responsibility is not entirely the candidate’s. If an organisation wants a presentation, it should state the rules.
Tell people how long they have, how many projects to cover, who will attend and what will be assessed. Say whether the team cares more about craft, systems thinking, leadership, commercial judgement or research. Explain whether confidential work can be anonymised. Allow alternatives when candidates cannot show polished artefacts.
Better still, provide the assessment criteria. This does not give away the answer. It removes the need to guess the exam format.
Clear instructions are also a design signal. A company that talks publicly about inclusion but relies on candidates discovering its interview folklore is creating avoidable exclusion. The UK government’s guidance on inclusive recruitment makes the broader point that recruitment processes should remove unnecessary barriers. An invisible presentation convention is exactly the kind of barrier that feels trivial to insiders and bewildering to everyone else.
Make the ritual visible
I have come to see the senior design presentation as a legitimate format wrapped in an unnecessary mystery.
The format is useful because design leadership involves narrative, judgement and the ability to help different people understand why a decision matters. A portfolio alone cannot fully demonstrate that. But the ability to perform the format should not be confused with the ability to do the work, particularly when candidates have never been told that the format exists.
So yes: prepare the deck. Treat it as a guided version of your strongest case study, not a slideshow copy of your website. Show the decisions, the awkward constraints, your contribution and the consequences. Practise the transitions. Remove half the process diagrams. Leave enough time for a sceptical engineering director to ask the question you hoped nobody would ask.
And if you are running the interview, say what you expect.
Unwritten rules are still rules. They are simply rules that reward the people who already know them.
