A design system built to scale across 5 product teams.
My Role
Lead Designer. Built the system from scratch and drove adoption across design and engineering, from component audit and token structure to the developer documentation portal.
Overview
Qrvey's platform is split across 5 independent development teams. Without shared components, each team interpreted Figma designs their own way: buttons with slightly different radius, inputs that didn't match, spacing that varied section by section. The more the product grew, the worse it got.
The fix wasn't just a Figma library. It needed to work for two very different audiences: designers in Figma and developers in code. That shaped every decision about how the system was organized.
Results
95%
Less time on UI adjustments. Changes that used to take 15 to 20 minutes per section now take seconds.
5
Product teams now building from the same shared library
60+
Components across 21 categories, including analytics-specific pieces built only for Qrvey
2+
Years in active use, growing with the product
Overview
Qrvey is an analytics platform built by 5 separate development teams, each working on a different section of the product. Without anything shared between them, every team read the designs and wrote their own code their own way, which meant the product kept looking more inconsistent the longer it went.
We built the Qrvey Design System to fix this: a shared component library and documentation site for both designers and developers that brought visual consistency to the product and changed how the company ships UI.
Results
The system became the one place both design and engineering could actually trust as the real reference. UI adjustments that used to take 15 to 20 minutes per section now take seconds. 5 teams build from the same components, and the system is still in use 2+ years after launch, growing with the product.
01 - The Problem: Building Without a Shared Language
Qrvey's platform is organized into 5 distinct product sections, each developed by an independent team. Before the design system, the workflow was fully manual: a designer produced screens in Figma, and each team independently interpreted those screens and wrote their own code. No shared tokens, no shared components. Just individual implementations of what was supposed to be the same UI.
The result was visible inconsistency across the product. Buttons with slightly different radius. Inputs that didn't quite match. Spacing that varied from section to section. Not because the teams weren't good, but because when nobody's coordinating, things drift.
→ Manual overhead was massive. Every layout change had to be applied separately, section by section.
→ Inconsistency was baked in. With 5 teams building in parallel, things got more inconsistent with every release.
→ Design decisions got reinterpreted. What we designed and what ended up in the product kept drifting apart.
02 - How We Structured It
Early on we decided this couldn't just be a Figma library. It had to work for two very different people: designers in Figma, and developers in code. That shaped every decision about how we organized it.
We split the documentation into 5 sections, from basic setup to advanced analytics components:
→ Getting Started: How to get set up in Figma (design side) and how to start implementing (dev side).
→ Guidelines: How to use things correctly, accessibility rules, and the visual style of the product.
→ Components: 21 categories, each with variants, states, and usage notes.
→ Layout: Grids, spacing, and how things behave on different screen sizes.
→ Analytics: Components built specifically for Qrvey's analytics features.
03 - Two Portals for Two Audiences
The system lives in two separate portals. One for designers, one for developers. Each speaks a different language.
Design Portal: Visual Library
The design portal covers the visual side. Each component is shown with its variants, states, and usage notes, connected directly to the Figma library so designers have a reference they can actually use.
Developer Portal: Code Documentation
The developer portal shows the same components in code. Live examples, modifiers, settings, and markup you can copy directly. This is what actually stopped the inconsistencies — developers stopped guessing and started looking it up.
04 - The Component Library
The library has 21 component categories, averaging 3 variations each, for a total of 60+ components. Every component includes variants, states, and usage notes so any team can build with it without second-guessing.
A few components worth calling out:
Inputs & Forms: Default, focus, error, disabled — all states covered, all using the same tokens.
Analytics components: Built specifically for Qrvey's features: Column Visualize, Connection JSON, Filter Panel, Formula Editor.
Navigation: Breadcrumbs, Tabs, Bartabs, Dropdowns — all states, all aligned on spacing.
Complex interactions: Drag & Drop, Rich Editor, Modal, Filter Control. These are the components that do most of the heavy lifting in the product.
05 - The System in Action
This is what the speed difference actually looks like. A quick walkthrough of the Figma library showing component properties, variables, and states in use — changes that used to take 15 to 20 minutes done in seconds.
06 - Results & Impact
95%
Less time on manual adjustments. Changes that used to take 15 to 20 minutes per section now take seconds.
5
Product teams now building from the same library. No more separate interpretations of the same components.
60+
Components across 21 categories, covering every major UI pattern in the product, including analytics-specific pieces built only for Qrvey.
2+
Years in use. It has grown with the product rather than becoming something everyone forgot about.
The efficiency gains were real, but the bigger change was cultural. Designers and developers started speaking the same language, handoff got cleaner, and it didn't matter which team built a feature — it looked right. It also ended up defining how the company writes markup and frontend code, which wasn't even the original goal.
07 - Key Takeaways
→ A design system is not something you deliver and move on from. Year one was mostly building. After that it started paying off — every feature shipped faster and looked more consistent because the work was already done.
→ The developer documentation was just as important as the Figma library. Without it, teams would have kept guessing. Building both portals is what actually got everyone on the same page.
→ This only worked because engineering was part of it from the beginning. If it had been purely a design project, it would have stayed in Figma and nobody in dev would have used it.