Reusable component library
Tokens, primitives, and composed patterns covering every recurring surface — from form fields to multi-step layouts.
Back to work
Case Study · Systems
A design system built for speed, not just consistency.
Petavue's product velocity was climbing, but the design infrastructure underneath it wasn't. Screens were being rebuilt from scratch, handoffs stalled in interpretation, and every new feature inherited a new set of UI decisions. The system we built closed that gap — and made shipping the default state.
Role
Founding Designer
Scope
End-to-end product system
Timeline
15 days initial · ongoing
Team
Design + Engineering partnership
The problem
Every new screen was a first draft.
Features shipped fast, but the cost showed up downstream: inconsistent spacing across flows, three patterns for the same empty state, and design-to-dev handoffs that turned into translation work. The team didn't lack discipline — it lacked a shared, reusable foundation that made the right choice the easy choice.
Key insight
Consistency is a side effect. Reuse at scaleis the actual product — it's what turns a system from a style guide into infrastructure.
The solution
One foundation. Three things it had to earn.
Rather than starting with a component library and hoping adoption followed, the system was scoped to the patterns that actually recurred across flows — and built so that picking up a component was always faster than re-drawing one.
Plug-and-play layouts
Predictable page templates so a new screen starts at 80% and the team only designs the interesting 20%.
Shared design ↔ engineering language
Components named, propped, and documented identically across Figma and code. Handoff became a copy, not a conversation.
Design decisions
What we chose, and why.
Scope
Ship the 80%, evolve the rest.
We resisted the urge to model every edge case up-front. The first version covered the most-used patterns; the long tail was added as it appeared in real product work.
Ownership
Built with engineering, not for them.
Component APIs were co-designed so the Figma layer and the React layer matched 1:1. No translation tax meant adoption stuck.
Evolution
Usage-driven, not roadmap-driven.
New components were added when the same pattern appeared three times in product work — not because a backlog said so.
Outcomes
Faster screens. Fewer decisions.
Within a quarter of rollout, design time on new screens dropped 60–70%. Engineering handoffs shortened because there was less to interpret. Onboarding new designers became a one-day exercise instead of a one-month one. Most importantly, the product looked like one product again.
60–70%
Reduction in new-screen design time
1 day
Designer onboarding to first shipped flow
1 system
Across design, engineering, and docs
What I took from it
A system is infrastructure, not a style guide.
The temptation with design systems is to optimize for the system itself — the docs site, the token taxonomy, the contribution model. The work that mattered was the work that made shipping faster. Every decision was tested against one question: does this make the next screen quicker to design and easier to build?
Up next