SPH Deep dive of the DHuO case
Sphere — Design System
The design system of the DHuO ecosystem: scale and consistency across modules and teams.
A shared library · design ↔ engineering alignment
SPHThe system
A design system as a product.
-
Foundations
- tokens
- color
Decision: consistency across modules and teams
-
Components
- Atomic Design
- components
Decision: a shared library
-
Engineering
- documentation in Figma
- integration with development
Decision: design ↔ engineering alignment
Foundations, components, and documentation — made for adoption by designers and developers, not only for a handsome file.
Context
Several products in the DHuO ecosystem needed a shared language so they could grow without fragmenting the experience.
Problem
Interfaces and styles that diverged across teams created rework and inconsistency.
My role
Co-creation of Sphere with the design team — foundations, components, and alignment with engineering.
Decisions
Atomic Design + tokens + documentation in Figma, for a system designers and developers can actually use.
Solution & artifacts
Screens and project details.
A system designers and engineers can use
Sphere treats the design system as a product: foundations, components, tokens, and documentation in Figma — made for adoption, not only for a handsome file.
- Atomic Design + tokens as the contract between design and engineering.
- Documentation in Figma to reduce ambiguity in implementation.
- Governance and consistency across modules in the DHuO ecosystem.
What we discarded
Problem
Interfaces and styles that diverged across teams created rework and inconsistency.
Result
A shared library · design ↔ engineering alignment
Impact
The results expected in the original case (speed, consistency) have no numeric metrics published here. Testimonials (Luca, Rafaela) support the collaboration and the structure of the system.
What I learned
A design system is a product: governance and adoption matter as much as the Figma file.