Three Crises, One Design System

A Figma file built from day one grew into the system that carried a startup through a rebrand, a regulatory shift, two team transitions, and ~40 shipped features.

TL;DR

• Problem: A seed-stage healthcare startup needed design infrastructure that could survive unpredictable organizational change without starting over each time
• Key decision: When CQC regulation changed the product, I restructured the entire system, replacing reusable organisms with complete clinical templates because the domain demanded page-level specifications, not composable building blocks
• Approach: Three design system versions across two years, each rebuilt to handle a different kind of crisis
• Outcome: A rebrand absorbed at the token level, two designers onboarded and produced consistent output from their first feature files, ~40 features shipped during the most turbulent period, and CQC certification achieved for the UK's first free remote PrEP service

Key Outcomes

• 3 design system versions across 2 years, each responding to a different organizational crisis
• Rebrand absorbed at the token level: brand identity lived in design tokens, not components, so the entire rebrand landed without rebuilding validated patterns
• 2 designers onboarded, both produced consistent output from their first feature files
• ~40 features designed during a 7-month production sprint with 3 simultaneous disruptions (regulatory pivot, designer departure, product bottleneck)
• CQC certification achieved, the design infrastructure behind the UK's first free remote PrEP service, featured in Forbes, Sifted, DIVA, and The Times

Quick Facts

From Accelerator to CQC Certification

LVNDR Health (formerly Troglo) is a digital sexual health startup building the first LGBTQ+-focused sexual health platform. They went from a pre-seed accelerator with a 3-5 person founding team to the UK's first free remote PrEP service with CQC registration, ISO 27001, and DTAC compliance. The design system spanned that entire journey, supporting a dual-platform product (patient mobile app and clinician web dashboard) through every organizational crisis along the way.

The Challenge

Three crises hit in sequence over two years. None were planned for. Each demanded a fundamentally different system.

• Crisis 1 (2020): Ship a 17-section MVP at accelerator speed while maintaining trust-critical consistency. First design hire alongside another designer, 3-5 person founding team, Techstars London
• Crisis 2 (early 2021): Absorb a complete brand identity change (Troglo to LVNDR) without rebuilding validated components, tied to a £1.5M seed round with Octopus Ventures and 16 angel investors
• Crisis 3 (2022): Restructure the system for CQC clinical regulation while onboarding a replacement designer mid-sprint. The previous designer departed, a new one joined, and the product roadmap flipped from wellbeing-first to clinic-first

Rebuilding from scratch was never an option the business could afford. Each time, the system had to absorb the change while the team kept shipping.

What I Built

Three versions of a design system, each a structural response to a different pressure:

• v1 (Troglo, 2020): Atomic Design architecture built from day one at accelerator pace
• v2 (LVNDR, 2021): Token-driven rebrand absorption with team onboarding infrastructure
• v3 (Clinical, 2022): Template-heavy clinical specifications with developer handoff architecture

The system's value was not consistency. It was that it kept working when everything around it changed.

Decision 1

Why I Chose Atomic Design Before the Team Existed

I was the first design hire at a pre-seed startup, joining alongside another designer, with a 17-section MVP to deliver for Techstars investor demos. Five product deck versions shipped in a single month. Digital sexual health demands consistency. When users share sensitive health information, one mismatched interaction erodes trust.

I adopted Brad Frost's Atomic Design from day one: Foundations, Atoms, Molecules, Organisms, and Templates, visible in the Figma export structure from v1. I built WCAG 2.1 AA accessibility guidelines into the Foundations layer. Every element followed naming conventions a new teammate could learn in an afternoon.

The shape of v1 showed where the product was: most of the design work lived in reusable components. We were building the visual language fast. Templates were nearly empty. The product hadn't reached page-level complexity yet. That would change.

Tradeoff: Slower initial velocity while building out the architecture. At a startup shipping 5 deck versions in a month, every day spent on infrastructure instead of screens felt expensive. The bet paid off when the first additional designer joined during the rebrand phase and produced consistent output from her first feature file. The naming conventions and hierarchy gave her a self-serve onboarding path I hadn't explicitly designed for.

Decision 2

How Token Architecture Absorbed a Complete Rebrand

Troglo became LVNDR. New name, new visual identity, new positioning. Coral and salmon shifted to purple and lavender, tied to the £1.5M seed round. The name LVNDR carried LGBTQ+ cultural resonance (the Lavender Scare, lavender menace reclamation). Everything about the brand changed. The question was whether the design system had to change with it.

The design team had grown to two designers plus a PM. A full component rebuild would have stalled us for weeks during a period when Octopus Ventures was evaluating the product.

I updated the Foundations tokens (colors, typography, spacing) and let changes flow through the hierarchy.

The architecture held. Foundations expanded significantly to absorb the entire new brand identity: colors, typography, spacing, iconography. Meanwhile, the validated interaction patterns in Organisms stayed stable. The system grew from 6 sections to 10, gaining an Intro page, a bin for deprecated components, App Store Assets, and Social Media Guidelines.

Components that were too tightly coupled to the old Troglo brand moved to the bin section rather than being deleted, kept as reference for patterns that might return in a different visual language.

The Visitor Manual in the Intro page gave developers a structured onboarding path: Atomic Design hierarchy diagram, component naming conventions, and prompts ("Why? What tradeoffs?") that embedded design thinking into the handoff process. It was originally written for the first designer's onboarding and became the standard for every new team member after that.

Tradeoff: The architecture proved that brand identity lives in design tokens, not in components. But it also revealed that some components were too tightly coupled to specific brand elements. The Troglo Score gamification cards, for example, couldn't be re-themed because their visual language was inseparable from the old brand. They went to the bin, and were later abandoned entirely when the product shifted to clinical credibility.

Decision 3

Restructuring the System for Clinical Regulation

This was the hardest version to build.

CQC registration accelerated. The product roadmap flipped from wellbeing-first to clinic-first. Clinical PrEP consultations, appointment booking (the largest engineering investment at T55+P34 story points), and clinician workflows all jumped to the front of the queue.

Clinical screens were too context-dependent for organism-level abstraction. A PrEP history questionnaire, a kidney function test date screen, a pre-consultation check-in with "Are you somewhere private?" and emergency resources: these needed complete page specifications with real clinical content, state coverage for every pathway, and developer handoff annotations. Not building blocks developers composed without guidance.

At the same time, the previous designer departed mid-sprint. I went solo for a period, then onboarded a replacement, walking her through designs, documentation, and the design system personally, into a system I was fundamentally restructuring.

The restructuring was deliberate. The system's centre of gravity shifted from reusable components to complete clinical specifications:

• Organisms went from the largest layer to the smallest: only four components survived (illustration card, cancellation dialog, cancellation policy modal, push notification card). Everything else was too context-specific for clinical workflows
• Templates became the dominant layer: complete PrEP clinical pathway screens with full state coverage for every user journey
• I consolidated Atoms with rigorous state coverage instead of breadth. Buttons: 3 tiers (Filled, Outline, Text) x 3 states (Enabled, Pressed, Disabled) x icon variants = 18 combinations. Form inputs: 6 states (Inactive, Active, Active clear, Warning, Attention, Disabled)
• Foundations continued to grow as the system's anchor. Design tokens, accessibility guidelines, and brand infrastructure now made up the largest share of the system

I established a standardized Figma page hierarchy: README, Handoff, Feature, Backbone, consistent across all production feature files, using a Feature-Scenario-Story naming convention (e.g., AB-S1-N01 = Appointment Booking, Scenario 1, Notifications, Story 1). I split Figma into three flavors: Production (what developers build from), Development (what's in active design), and Experimental (what's being explored).

Biweekly Design × Development meetings produced shared technical contracts: SVGs with timing specs for simple animations, RIVE files for complex interactions, and an interaction-by-interaction haptic feedback plan confirmed feasible by the Flutter developers. These contracts eliminated the "that's not what I designed" conversation because both sides had signed off on the same specification.

Tradeoff: Letting go of validated, reusable components was an admission that the domain had changed and the architecture had to change with it. Clinical screens required page-level specifications that CQC auditors could trace. Holding onto an elegant composition model when your team needs complete specifications is its own form of design debt.

Decision 4

The System That Outlasted Its Designers

The hardest test of a design system is not whether it produces consistent screens. It is whether it keeps working when the people who built it leave.

During the 7-month production sprint (May to November 2022), three disruptions hit simultaneously:

• Regulatory pivot: CQC acceleration flipped the roadmap, deferring the wellbeing features that defined LVNDR's differentiation. Every deferred feature traced to a "Post-CQC" tag with documented reasoning
• Designer departure: The previous designer departed mid-sprint. I went solo, absorbing her in-progress work while keeping the pipeline full for the dev team
• Product bottleneck: 2 product people serving a team of 14-16. The VP of Product flagged: "Product will be the more significant bottleneck"

The infrastructure held. Not because I worked harder during the solo period, but because the system had enough structure to absorb the disruption.

When the replacement designer joined, she produced consistent output from her first feature file. Not because I spent weeks onboarding her. Because the standardized Figma hierarchy (README > Handoff > Feature > Backbone) made the system self-documenting. The Visitor Manual, originally written for the first designer's onboarding, served its purpose a second time. Her annotations are visible in the consultation flows she designed.

I co-designed the sprint structure with the dev lead. The principle: "Product works ahead of dev." Discovery, ideation, and prototypes feed epics before dev sprints begin. Rework stays in design, not code. When the CQC pivot flipped the roadmap, the design pipeline had enough buffer to rework features in Figma while engineering continued building from the existing backlog. Zero sprint delays from the regulatory pivot.

We ran on a fixed cadence: Monday Roadmap Review (30 min, all-hands), daily standups (15 min, Product + Tech separately), Friday Demo Day (45 min, 5-minute demos per person), quarterly OKR ceremonies. INVEST framework for user stories with Fibonacci dual-axis sizing (Tech estimate + Product estimate with UX/UI split percentages).

The team shipped ~40 features across the production sprint. The system's real contribution was that those features shipped at consistent quality during a period when the team was simultaneously absorbing a regulatory pivot, a designer transition, and a structural bottleneck. Design changes landed in Figma before reaching the codebase. Rework was absorbed in design, not code.

Tradeoff: The process infrastructure consumed time that could have gone to feature design. Biweekly DxD meetings, structured Figma hierarchies, detailed handoff pages, dual-axis sizing: each added overhead. During the solo designer period, maintaining that overhead while covering the departing designer's workload meant longer days. But when the replacement arrived, the overhead paid back in days, not weeks. And when I eventually left the project, the system continued to function without me. The best validation of infrastructure is that it outlasts its designer.

Reflection

A design system is not a product. It is a team's shared language, and it has to evolve when the team or the product changes.

The hardest decision was not building the system. It was accepting that what worked before was wrong for what came next. v3 meant letting go of the reusable component library I had built over two years and replacing it with clinical templates, because the domain now required page-level specifications that CQC auditors could trace, not composable building blocks that developers assembled differently each time.

If I were building a fourth version, I would invest earlier in the standardized page hierarchy. The README > Handoff > Feature > Backbone structure did more for team alignment during v3 than any component architecture decision. The replacement designer was productive within her first feature file. The Flutter developers knew which designs were ready to build. The hierarchy made the system self-documenting.

Infrastructure that helps people work together scales better than infrastructure that helps components compose.