Torrent Diagnostic — Brand & Design System
Cutting design inconsistency with a reusable brand and UI system. One identity, one component library — powering the patient app, the phlebotomist field app, and the clinical web. Built from scratch.
TL;DR
- Built a brand identity + design system foundation from scratch — used across 3 distinct product surfaces under the Torrent Diagnostic umbrella.
- Established semantic token architecture (background / content / border × primary / secondary / tertiary) so any surface can theme without touching component internals.
- Cut design inconsistency at the source — engineers across product teams now compose from the same library instead of inventing their own components.
The 3-product context
Torrent Diagnostic was launching three products in parallel — the consumer-facing Patient App, a field-collection app for phlebotomists, and a clinical-side web tool. Three different product teams, three different audiences, three different platforms.
Without a shared foundation, we'd ship three products that visibly belonged to three different companies — even though they all carried the Torrent name. Worse: every product team would re-solve the same component problems badly and slowly.
Hard constraint: no luxury of a "freeze and build the system" phase. The system had to ship alongside products, not before them. So I inverted the usual order — brand first, then system, then components — because brand was the part that had to flex across audiences without forking.
Brand foundation
Healthcare branding usually defaults to sterile blues and whites. Torrent's audience — seniors with chronic conditions, phlebotomists in the field, clinicians at desks — needed something different. Calm, but warm. Trustworthy, not clinical.
Brand and system live in the same Figma source of truth. Drift between brand and system is the most common system failure I've seen — keeping them coupled prevents the gap from opening.
Token architecture
Three tiers. Brand tokens at the bottom (raw values). Semantic tokens in the middle (intent-named). Component tokens at the top (component-scoped overrides). Each tier consumes only the tier below it. Designers change one brand token; the impact propagates without manual sync.
The pipeline: Tokens Studio (Figma) → Style Dictionary (CI) → platform outputs (CSS variables for web, XML for Android, JSON for React Native). Designers change a token in Figma; engineering picks up the diff in a PR. No hand-syncing.
Component anatomy
Every component in the library has the same documentation shape — anatomy, variants, states, do / don't. Worked example: the Trend Card, used across the Patient App for HbA1c, cholesterol, LDL, and similar lab values.
Governance + contribution
A system without governance becomes the worst kind of liability — it looks like a foundation but acts like a shared mutable global. Three rules carried us:
- The system has one owner. A small architecture committee (2 people) reviews every system-level change. Speed without bottleneck.
- Anything that affects more than one team's UI is a system change. One sentence — but it has prevented more drift than any tool we've built.
- Consumer teams contribute via RFC. A 1-page proposal for any new pattern. Reviewed in 48 hours. Either accepted into the system or kept as a vertical extension.
Component scope at v1 was deliberately tight (~40). The long tail (specialised data tables, complex forms) was deferred to v2 candidates. Tightness now → contribution velocity later.
Outcome
The Patient App and Phlebotomist App both shipped on top of the system. The clinical web is in flight. The next product Torrent launches will start from this foundation in a fraction of the time the first three took.
What I'd change
I'd have shipped contribution tooling from day one — PR templates, automated changelogs, RFC process for component proposals. We added them in month four. Done at month one, the contribution velocity from the consumer teams would have been double.
And: I'd have invested in a system Storybook earlier. We had Figma for the design layer but engineering's component documentation lagged behind for the first quarter. A live Storybook from day one would have been a forcing function for parity.