Datasaur Design System
Company
Timeline
How I helped
Built the design system foundation Led the design team's transition to Figma
Designed UI components and implemented features
Coordinated with engineers and oversaw component implementation in vulcan-ui
Maintained the design system and kept it up to date
113
components defined
295
icons created
~200
pages impacted
01
Overview
Before we implemented the design system, our workflow for UI components was fragmented and inconsistent. Designers would hand off final designs with new components, but there was no dedicated documentation to guide engineers. This often left engineers making implementation decisions on their own, and code reviews happened at the feature level—mixing components and product features in the same repository.
Challenges
Disconnected knowledge: Designers could only see the component in the completed UI, while engineers weren’t always aware of modifications or whether changes should be treated as variants or new components.
Lack of documentation: Missing details and behaviors made it difficult to scale the UI components consistently.
Reinventing the wheel: Engineers sometimes duplicated components or overrode existing ones, leading to wasted effort and inconsistencies.
These issues highlighted the need for a structured design system that would centralize components, standardize implementation, and create a shared source of truth for both design and engineering teams.
02
Solution
To address the challenges, we established a structured workflow and centralized component system:
Component creation: Designers start by creating new components in the Playground (Figma), allowing early exploration and iteration.
Initial review: Engineers review the component early to confirm feasibility and catch potential issues before development begins.
Final approval: Once the design is approved, the component is moved to Dev Handoff (Figma), serving as the final reference for implementation.
Implementation: Engineers develop the component in the Vulcan UI library.
Collaborative review: Both designers and engineers review the implementation in the Storybook to ensure visual and interaction fidelity.
Publication: Once approved, the component is published to the shared library, ready for use across products.
This process ensures clear communication between design and engineering, reduces duplicated work, and maintains consistent component quality.
03
Result
Benefits
Engineering
Access to code examples for implementing specific components.
Components are centralized and consistent, reducing duplication and rework.
Clear documentation in Storybook ensures alignment with design intent.
Design
Ability to review components before they are merged and used in production.
Test interaction and visual fidelity directly in the Storybook’s Playground.
Maintain and update the design system efficiently, ensuring long-term consistency.
Best practices established
Engineering
Always request a designer review when adding new components.
Include Figma links and documentation for every component in Storybook.
Document new features within the component story.
Check Storybook for existing components before creating new ones to avoid duplication.
Design
Regularly update and maintain the component library.
Include additional documentation to support design system usage.
Keep Playground and Master files separate to maintain manageable file sizes.
04
Extending the system
As Datasaur's product surface area grew, the existing color system — built from individual hex values rather than a structured scale — made supporting dark mode difficult to do consistently. I led an effort to rebuild the color architecture using OKLCH, a perceptually uniform color space that keeps lightness and contrast predictable across different hues, unlike traditional RGB or HSL.
The new system is structured around semantic tokens — neutral, brand, and status/alert families — with each token carrying both a light and dark value, so switching themes doesn't require overriding colors per component. This also made it possible to systematically verify accessibility contrast ratios across the entire palette, rather than checking colors ad hoc as they came up.
Like any design system, this isn't a closed chapter — new components, product surfaces, and edge cases continue to surface, and maintaining the token architecture as the product evolves remains part of ongoing system ownership.