Propose Broad, Ship Narrow
The Problem
At PariPassu, working as one of two designers on two products, I drafted a broader set of new components than the team actually needed, hoping to anticipate edge cases across Rastreador and CliCQ. Over a few weeks it became clear that a chunk of those variants were never touched. They added cognitive overhead without real payoff, and the perceived bloat slowed adoption.
What I Tried
My approach was completionist: "Let's anticipate all use cases and build them upfront." I mapped many button states, card variants, input types, and edge cases based on design thinking exercises, past templates, and patterns from mature design systems at larger companies.
Why It Failed
The premise was flawed. PariPassu was a fast-moving foodtech serving traceability and quality inspection. Actual near-term needs were a fraction of what I'd drafted. "Should I use CardStandard, CardCompact, or CardMinimal?" Without solving real problems, I was designing for hypothetical futures instead of validating current demand.
The Lesson
Design systems should grow organically with the product, not precede it. The best systems I've seen at larger companies (Bridge, Multidrop) didn't ship complete on day one; they started small and scaled as patterns emerged from real usage. Staying lean meant: (1) engineers understood every component because they used all of them. (2) We iterated faster, fewer decisions meant faster PRs. (3) When new patterns appeared, we added them deliberately.
The Outcome
Together with the other designer, I pruned the proposal to the components the team was actually using, kept documentation focused on those, and paired with devs to adjust tokens. The collaborative pruning made adoption easier and let us add new components only when real usage demanded them.
Impact
Faster design-to-engineering handoff, less decision paralysis, and a system that reflected how the product was being built instead of how I thought it should be built.