A director asked a software manager about the progress of a new design system adoption initiative. A reasonable question. The kind of question a director is supposed to ask.
The dev manager had already decided what he was shipping. The initiative was not on his priority list. It was on someone else's priority list, and the two lists had never been formally introduced. So he put together a one-page prototype. Not a progress report. Not an honest status update. A prototype built specifically for that room and that question — showing the director what currently existed and what the system should theoretically become. It looked like a plan. It was a rendering of a plan. The work required to build it was real. The alignment it implied was not.
The director left the meeting satisfied. The initiative did not move. The prototype was filed somewhere it would never be opened again. This is called a review.
The design review is one of the most consistently misunderstood processes in design system operations. It is treated as a quality gate. It functions, in most organizations, as an appearance of a quality gate. The gate is open before anyone arrives. The ritual of passing through it is preserved because the ritual itself signals alignment, investment, and progress. None of which are the same as quality.
A review that cannot change the outcome is not a review. It is a meeting with a predetermined destination and a seating chart.
Two Reviews. One Name.
Every design review falls into one of two categories. Most teams operate both simultaneously and cannot tell which is which.
The Quality Gate
A review with explicit criteria. The reviewer knows what they are looking for before the file opens. The decision can go either way. The work can be blocked. The review exists to catch something real — an accessibility failure, a token violation, a pattern that conflicts with an existing component. When it catches something, the system is better for it. When it finds nothing, the work ships faster because the team has confidence the review was genuine.
The Approval Theater
A review with no explicit criteria. The reviewer knows what they want to see before the file opens. The decision has been made. The review exists to give someone visibility, to satisfy a process requirement, or to create a paper trail that proves due diligence was performed. The work was always going to ship. The review is the documentation that it was considered.
Approval theater is not a design system problem. It is an organizational problem that uses design system processes as its stage.
The review that exists to maintain authority and the review that exists to maintain quality are not the same meeting. Scheduling them at the same time does not make them the same thing.
The Mid-Design Working Review
The structural fix is not a better review checklist. It is a different review format entirely.
The mid-design working review happens while the work is still in motion. Not after the component is complete. Not after the decision has been made and the Figma file has been handed to engineering. In the middle — when the direction is set but the details are not locked. When there is still something to catch and still time to change it.
The working review is not a presentation. The designer does not present a finished direction and wait for approval. They share a Figma file — in progress, explicitly labeled as such — and ask one specific question: does this conflict with anything already in the system? That is the only question the reviewer needs to answer. Not whether they like it. Not whether they would have made the same decision. Whether it conflicts.
A review question with a specific scope produces a specific answer. A review question with no scope produces an opinion. Opinions are not quality gates.
The mid-design review catches two things end-of-process reviews consistently miss. First: structural conflicts — a new component that duplicates an existing one under a different name, or a token decision that contradicts an established pattern. Second: scope drift — a component that has expanded beyond its original brief and now overlaps with three other components in ways that will create maintenance problems six months from now. Both of these are invisible at the end of the process because by then, the team is too close to the work to see them. In the middle, they are obvious to anyone with context.
Three Rules for a Review That Ships
Rule 1 — Define the Criteria Before the File Opens
Every review needs a written brief: what is being reviewed, what criteria apply, and what constitutes a blocking issue. Two sentences per criterion is enough. The brief lives in Notion for teams that want something lightweight and immediately shareable — free tier covers everything a review brief requires. Confluence for organizations already in the Atlassian stack. The format is secondary. The discipline is primary: the criteria exist before the reviewer opens the file, not after.
A reviewer who defines their criteria after seeing the work is not reviewing. They are rationalizing a reaction.
Rule 2 — Make the Review Asynchronous by Default
The synchronous review gets rescheduled twice. Then it happens standing up outside a conference room at the wrong time with the wrong people. Make it asynchronous by default.
Loom makes the async review viable for both sides. The designer records a three-minute walkthrough of the work in progress — what the component does, where it sits in the system, what the specific review question is. The reviewer watches it, leaves timestamped comments, and returns a decision within twenty-four hours. Free tier covers twenty-five videos. No meeting required. No calendar negotiation. The review happens when the reviewer has the context to do it properly, not when both calendars align.
Rule 3 — Version the Decision
Every review that results in a decision — approved, blocked, or revised — should be recorded with a date, the criteria applied, and the reasoning. Not a formal document. A line in a changelog.
GitHub handles this natively for teams already using it for component versioning — a decision log in the same repository where the system lives, free for public repositories and standard for most engineering organizations. The decision log is what converts individual review outcomes into institutional knowledge. Without it, the same conversation happens again six months later with a different reviewer who reaches a different conclusion. The system does not learn. It repeats.
The review that leaves no record made no decision. It performed one.
The Quick Win: Audit Your Last Five Reviews
Look at the last five design reviews your team ran. For each one, answer three questions.
Were the review criteria written down before the file was opened? Could the review have blocked the work — and if it had, what would have happened? Is there a record of what was decided and why?
If the answer to all three is no — you did not run five reviews. You ran five meetings that looked like reviews from a sufficient distance.
Pick one upcoming component. Write the review brief before the work starts. Three criteria. Two sentences each. Share it with the designer before they open Figma. Run the mid-design review at the halfway point. Record the decision.
That is one real review. Run it once before deciding whether the format works.
The Argument
The design system does not need more reviews. It needs reviews that can change something. The difference between a quality gate and approval theater is not the meeting. It is whether the outcome was possible before anyone arrived. Build the review that catches something real. Everything else is a calendar event with a Figma link.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a design review actually changed something before it shipped.
When was the last time a design review on your team blocked something — and the system was better for it? 🤔
