SehatQ | Building Design System
As SehatQ scaled, inconsistent components, unclear documentation, and uneven adoption created recurring design debt. I surfaced the issue through a product audit, proposed a shared learning and system-building initiative, and contributed to establishing a more structured design-system foundation.
Recorded progress:
75% of the project checklist was completed by mid-June 2023. Final completion and adoption status need verification.
What exposed the problem
During an initial audit of SehatQ’s doctor-consultation, prescription-delivery, and Store experiences, I found recurring inconsistencies in components and visual assets. Conversations with the team showed that the issue was not simply missing UI elements; it involved structure, documentation, adoption, and review practices.
Although our team already has a UI Kit or components library such as design system, the structure and documentation are still not well organized and not clear to use.
In addition, many team members are still not accustomed to using the UI Kit for the design.
Some team members still need to deepen their knowledge about the design system and how to use it.
Due to the lack of a review system for tasks or projects done by team members, there are often inconsistencies in the use of assets and components on various pages and features.
Turning an observation into a shared initiative
I brought the findings to the team lead and proposed that the team develop its design-system practice together. The initiative aimed to create a shared language for designers and engineers, reduce repeated decisions, and make consistent implementation easier as multiple teams shipped in parallel.
Why this mattered
Without a structured design system, SehatQ risked slower iteration cycles, increased rework, and fragmented user experiences—especially as multiple teams shipped features in parallel.
The design challenge
How might we turn an underused and inconsistently structured UI kit into a shared system that designers and engineers can understand, adopt, and evolve together?
Audit, inventory, and prioritize
We inventoried the components and assets already used across products, grouped them using an atomic structure, and turned the inventory into a delivery checklist. This made the scope visible and allowed the team to prioritize frequently used foundations before expanding into more complex patterns.
How we built trust and adoption
Each foundation and component was documented beyond its visual appearance. We explained its purpose, anatomy, variants, usage guidance, dos and don’ts, and examples inside actual product interfaces. This helped the library function as a decision reference rather than a collection of reusable assets.
We introduced the system incrementally. At approximately every 25% milestone, we shared the new scope with the wider team and explained how to apply it. The published Figma Library became the shared reference across teams and projects, particularly for new initiatives such as the centralized Geolocation experience.
The system did not extend to a coded component library. However, we aligned its structure and intended usage with Engineers. They supported the initiative and used the Figma components and documentation as an implementation reference for greater consistency.
Decisions that supported adoption
1. Make the active location visible and contextual
Components, create components using the atomic design methodology.
2. Offer flexible ways to set a location
Documentation, each component we create should be accompanied by documentation that includes the principles of the component, its variants, and dos and don'ts for using the component.
3. Let users save and manage multiple addresses
How to work, create a usage guide to help team members become more familiar with using the design system easily.
Progress and outcome
The team completed 75% of the planned component checklist. At each approximate 25% milestone, we introduced the additions and usage guidance to the wider team instead of waiting for the library to be “finished.” The Figma Library was adopted across teams and used as a reference for projects, especially new work such as the centralized Geolocation experience.
The project did not reach 100% because the company ceased operations and the team was laid off. This was an organizational endpoint rather than a design-system completion decision.
The strongest supported outcomes are adoption of a shared Figma Library, recurring team enablement, consistent documentation, and Engineering’s use of the system as an implementation reference. We did not maintain formal baseline metrics for delivery speed, rework, or implementation accuracy, so those remain intended benefits rather than quantified impact.
Reflection
The project showed me that a design system is an operating model, not only a component library. Its long-term value depends on ownership, documentation, contribution rules, design-code alignment, and team habits. If I continued the work, I would formalize governance and measure adoption from the beginning.
