Skip to content
How-to

How to run a business review for design

Most design reviews with leadership are a portfolio walkthrough that answers questions nobody asked. A structure for the quarterly account of a design organization, in the four sections a CFO already knows how to read.

5 min readSentia Labs

The quarterly design review usually goes one of two ways.

It is a portfolio walkthrough, where the design leader shows the best work of the quarter and the room nods politely at screens they cannot evaluate. Or it is a defense, triggered by a headcount question, where the leader argues for their org's value using examples chosen for how memorable they are.

Both fail for the same reason: they answer a question nobody in the room asked. Executives are not evaluating craft. They are deciding where to put people and money next quarter, and they need design stated in terms that compare against every other function making the same request.

Here is a structure that does that. Four sections, in the order a business audience reads.

1. Where the investment went

Open with allocation, not with work. This is the section that establishes you are running an organization rather than curating a portfolio.

What belongs here:

  • Coverage by company priority. Their list, your people next to it.
  • What changed during the quarter, and why. Every reallocation that happened, stated as a decision rather than a drift.
  • The unplanned load. Exec requests, partner-team support, the recurring commitments nobody costed.

The unplanned number is the one that lands. Most design organizations are absorbing a double-digit percentage of capacity in work that appears in no plan, and leadership genuinely does not know it. Putting it on a slide changes the conversation from "why is design slow" to "which of these should we stop."

A caution: do not present the average ratio for the org. It is the least informative number available and it conceals the thing worth showing, which is variance. One strategic initiative running at one designer against fourteen engineers is a finding. The org averaging 1:11 is not.

2. How the organization operated

This section is about the machine, not the output. It is the one most design leaders skip and the one that most improves their credibility, because it is the section their engineering counterpart already presents.

Three measures carry it:

Cycle time by stage. Brief to shipped, broken into ideation, critique, review, handoff. The aggregate hides everything interesting. The staged view is what tells you, and the room, where the constraint actually is.

Rework rate. How often work came back after being considered done, and from which stage. This is the cleanest available proxy for decision quality, and it is the number that catches the modern failure mode where AI-accelerated drafts push more decisions downstream and the saved time is spent in revision.

Where the drag was. One or two named bottlenecks with evidence. "Design review is averaging eleven days from request to decision, up from four" is worth more than any amount of process narrative.

Say what you are doing about each one. This section is a commitment, not a report.

3. What people contributed

Short, and specifically not a list of individuals. This section exists so that the people who did valuable invisible work are on the record, and so promotion and retention conversations later in the year are not starting cold.

Frame it as capability, not activity: the research that changed a roadmap, the system work that removed duplicated effort across four teams, the direction someone shaped on an initiative they did not own. Three or four items, each traceable to something real.

The reason to include it at all is that the contribution most worth recognizing is the contribution least visible from outside the function. If the design leader does not surface it, nobody will, and it will be missing from the room six months later when it matters.

4. What the work returned

The last section, and the one everything else earns the right to make.

Be more careful here than feels comfortable. The instinct is to claim outcomes: design drove the conversion lift, design improved retention. Executives discount those claims heavily and correctly, because a shipped outcome has many parents and everyone in the room is claiming the same one.

The stronger move is a traced path rather than a claim of causation. This priority, these decisions, these people, this measured change. Smaller than the claim design leaders usually want to make, and unlike that claim, it survives the follow-up question.

State it against KPIs the business already runs on. Not a design-specific metric the room has to be taught, which converts every discussion into an argument about the metric rather than the work. If the company runs on activation, speak in activation.

Include something that did not work. One decision that shipped and did not move what it was supposed to, with what you concluded. This costs less than it feels like it does and buys more credibility than the rest of the deck combined, because it demonstrates you are measuring rather than selling.

What makes this hard, and how to make it not hard

None of this structure is controversial. The reason most design leaders do not present it is not that they disagree. It is that assembling it takes a week of manual work every quarter, and the week has to come from somewhere.

The evidence is all there. Figma knows who touched which file on which project. Linear and Jira know what moved and when. The research repository holds the studies. Slack holds the decisions. Every fact in the four sections above already exists as a timestamped record somewhere in the stack.

What does not exist is the connections between them, which is exactly the part a human has to supply by hand, from memory, once a quarter, in the week they should have been doing something else. That is why the review gets skipped, or downgraded to a portfolio walkthrough, or written the night before.

A design organization that can produce this account continuously rather than quarterly gets a compounding advantage that has nothing to do with the review itself. Allocation drift gets caught in week three instead of week twelve. Bottlenecks get named while they are still cheap. Contribution accumulates as a record rather than a memory.

The review stops being a performance and becomes a readout of something you were already watching. Which is what it is for every other function in the building.