Case Study - A 36-Ticket Reskin Sequenced So It Never Blocked on Itself

Overview

A new design needed to land across every screen in the patient app at the same time a second, sibling product was about to need the same visual language and component set. Reskinning one app's screens one at a time, with no shared foundation, would have meant redoing the same work again within the year.

The problem

A design-system rebuild has an unforgiving dependency order: tokens and theming before any component, primitives before any page reskin, the app shell before individual pages — but the business needed checkout and the dashboard done fast, not last. Getting the sequencing wrong either means starting over halfway through, or shipping a foundation so rushed that the second consuming product inherits its shortcuts. Layered on top: accessibility and dark mode weren't cosmetic add-ons scheduled at the end — in a health product, a patient reading their own lab results needs contrast, focus states, and screen-reader semantics to actually work, not just look plausible in a demo.

Why it took a physician-engineer

The sequencing decisions on which screens got reskinned earliest were product and clinical judgment, not just backlog triage. The assessment viewer and the lab-scheduling flow — the two screens where a patient is reading their own health data or making a decision about their own blood draw — were treated as their own dedicated tickets with explicit acceptance criteria for data correctness, while lower-stakes screens could tolerate a looser bar. The same judgment shows up in what was explicitly scoped out: no backend changes, no CMS schema changes, no new features — the reskin stayed a reskin, so a purely visual initiative didn't quietly become a scope-creeping rewrite of systems that were already working correctly.

Approach

The sequencing was foundation-first, deliberately: shared component library and design tokens landed before any component work, since every later ticket depended on it; primitives — buttons, inputs, form controls, overlays, navigation — were built and parallelized across developers once the foundation existed; the app shell was reskinned before individual pages, so page-level work happened inside the correct chrome instead of needing a second pass later.

The library was structured from the start as a package a second, sibling product could consume — not something to extract later. That decision shaped implementation discipline throughout: components built generic enough to serve two products, not just tuned to this one app's exact needs.

Under the hood

React, TypeScript, and Vite, with Tailwind for the design-token and theming layer and Storybook as the component-development and documentation environment for the shared library. Every one of the 36 tickets specified type, phase, size estimate, and explicit dependencies, with a documented in-scope/out-of-scope split and checkable acceptance criteria — sized deliberately to transpose directly into a single sprint story. Dark mode, accessibility, and motion were each their own dedicated, gating tickets in the final phase rather than scattered line items.

Outcome

The reskin delivered full platform coverage — every screen from checkout through lab scheduling to the assessment viewer — against the new design, with a shared component library structured for immediate reuse by a second product rather than a one-off visual pass that would need to be redone. The highest-visibility, most time-pressured screens didn't have to wait for the full backlog to clear, while the highest-stakes screens still got dedicated correctness scrutiny rather than being rushed through on the same timeline as lower-risk pages.