The permission tax: what design review is for when building is cheap
Approval layers were installed to prevent expensive mistakes, and building is no longer expensive. Which reviews to keep, which to automate, and which to drop.
Every approval step in a design process was installed to prevent something expensive, and building has become cheap enough that the step now costs more than the thing it prevents. A uxdesign.cc piece on the shape of design teams calls this a permission tax: approval layers that once controlled costly mistakes now slow teams more than building does, and its remedy is for leaders to supply context and support so that teams stop needing a sign-off at each step. The practical question for a design leader is which approvals still buy something, and the way to answer it is to list them.
On my own site I stopped approving agent changes by reading the code. Tests, lint, and typecheck gate every merge, and a change that fails any of them does not land, whether or not I have looked at it. Reading every diff by eye could not keep up with the volume the agents produce, and the checks look at the same things on every change without getting tired. One human gate stays, and it is the one described below.
Reviews worth keeping
A review earns its cost when what it catches is expensive, hard to see from the inside, and hard to undo. Accessibility passes that test, since the problems are invisible to whoever made the thing, they compound across every surface that copies the pattern, and they cost far more to fix after release than before. Conformance with the design system passes too, because drift stays silent until a hundred screens have it, and by then nobody can say which version was correct. Everything else on the list has to justify itself. A review that mostly confirms what the designer already decided costs more than it returns, and so does a review whose main job is making the reviewer comfortable. If the reviewer can't name the specific failure it exists to catch, cross it off.
Move the mechanical questions into the build
Most of what a conformance review checks can be written as a rule, and a rule runs on every change without a meeting. A color pairing either clears its contrast minimum in both themes or it does not, a generated file either matches its source or it does not, and a component either comes from the system or it does not. A designer who changes a color finds out within seconds, inside the work, with the exact pair that failed, and nobody scheduled anything. The case for automating the keepers grows with output, because a team that reviews by hand at agent volume spends its week in the queue.
The gate I keep by hand
The plan I wrote for a full review of this site lets every working session fix, test, and commit without asking, and it writes down one exception: design-system changes (a new component in the ui folder, deleting one, a new shared utility) are proposed to me first and never built on the spot. The reasoning follows the test above. A new component changes what everyone downstream can build, it is hard to undo once other code depends on it, and in a pull request it looks like any other diff, so it is exactly the kind of call that a green build cannot judge. A single human gate on a short list of expensive decisions, with the cheap work around it left to run, keeps my attention on the places where it changes the outcome.
Give people the context so they don't need your approval
Context works when it is specific: what good looks like in a given area, who has made similar decisions before, which constraints are real and which are leftovers, and what you want to hear about early. A senior designer with that in hand doesn't need my sign-off to move. I stay in the approvals a report has no authority to make and in political alignment, where my presence helps, and I find out a deliverable is drifting through shared visibility in docs, dashboards, and standups, so nobody has to remember to tell me. The fixed 1:1 then holds the conversations that need thought. A leader who keeps approvals as the main form of control has to reread every decision, while a leader who writes the context down gets to read it once.
I encourage mistakes made while moving quickly, since a team that learns to move without asking permission recovers faster, and the occasional miss that a second pair of eyes would have caught costs less than every designer waiting a day for feedback on every piece of work.
Be the first to rate this article.
Let's work together.
Open to select projects and collaborations — design systems, accessibility, and AI-native product work.