Why Designers Have Less Freedom (And Why That's Good)

We moved to strict Storybook governance this quarter. The rule is easy to state and annoying to live with at first: if it’s not in Storybook, it doesn’t go in the design. Not a variant, not a “just this once” tweak, not a marketing-only pattern. If the component doesn’t exist in the source of truth, the design doesn’t get to use it.

I will admit I resented the rule for about six weeks. I’m past that now.

01. The rule

The governance itself is straightforward. Every shippable UI element, buttons, inputs, modals, cards, navigation chunks, lives in Storybook with its variants, states, and props documented. The design file in Figma mirrors that library exactly, nothing added, nothing invented. If I need something that doesn’t exist, the path is: propose it, design it properly, get it into the library, then use it in the feature.

What that path is not: draw it in the feature file and hope engineering infers the component.

The reason for the rule is older than this quarter. We’d accumulated, over two years, something like seven button “styles,” half a dozen card variants that were mostly the same card, and a rotating cast of one-off modals that each differed from the shared modal by small, unjustified amounts. All of that came from a well-meaning place: someone needed something, we made it, we moved on. The aggregate result was a UI that didn’t feel like one product.

02. Pushing back on one-offs

The hardest part, and this is the part nobody warns you about, is the conversations.

“Can we get a slightly different button here for the launch page?” “Can this card have a gradient border just for the holiday promo?” “What if this modal was, you know, a bit more special?” Every one of those requests is reasonable, in isolation. None of them is reasonable in aggregate.

I spent a lot of energy this quarter saying some version of “not without adding it to the system first, and I don’t think it’s worth adding to the system.” That isn’t a fun sentence to deliver to a product manager with a launch deadline. It’s also, most of the time, correct.

What I noticed is that when I pushed back, the requester almost never actually needed the one-off. They needed a decision. They’d identified that something about the flow wasn’t working, and a new component seemed like the shortest path to “working.” Usually, the actual fix was content, hierarchy, or a missing state in an existing component. The one-off was a symptom; the system hole was the disease.

03. What I did with the time

Here’s the part that surprised me. I figured strict governance would mean less work. It meant different work.

I spent roughly 80% of my month on user flows, edge cases, and error states instead of visual polish. Empty states. Loading states. The third screen in a three-step flow that nobody had bothered to design. What happens when the API returns partial data. What the component looks like when the user’s name is 40 characters long, or Arabic, or a single emoji.

None of that is glamorous. None of it got anyone’s attention in the review meeting. All of it made the product meaningfully better, and all of it had been hiding behind the time I used to spend picking between two nearly identical button treatments.

There is a version of design that is mostly visual taste, and a version that is mostly systems thinking. I’d been underweighting the second one for years. The governance nudged me, then shoved me, toward it.

04. Where creativity actually lives

The fear I had going in was that strict governance would flatten the work, make everything feel like a template, remove the joy. That’s not how it played out. The creativity didn’t die, it moved.

It moved from screens to systems. Instead of inventing a new button, I’m inventing better state behavior for the button we already have. Instead of a bespoke layout for one page, I’m finding the right composition of existing pieces, and occasionally, when the composition genuinely doesn’t exist, proposing a new primitive that pays its rent across the product.

The phrase I keep coming back to is this: creativity isn’t found in a custom border radius, it’s found in removing friction from the user’s flow. That realization is going to sound obvious in print. It did not feel obvious while I was the designer defending my twelfth variant of a button.

There’s a humility to it, too. A lot of what I used to call “design decisions” were really just preferences, and preferences dressed up as decisions are how design systems rot. The governance makes it harder to smuggle a preference into the product. That’s a feature.

---

05. Closing

I’d describe the last three months as a trade. I gave up a lot of surface-level freedom in exchange for being more useful. The product got more consistent, the engineers stopped asking me which button this was, and I finally had the time and the reason to pay attention to the parts of the experience that were actually broken.

If you’re a designer who bristles at the idea of a stricter system, I get it. I was that designer in July. What I’d say, from the other side of it, is that the freedom you’re protecting is probably freedom to re-solve problems you’ve already solved. Governance takes that away, and then it gives you something better: the time and the obligation to solve the problems you’ve been avoiding.