Build and ship a design system for legacy B2B SaaS

A mature clinical platform had grown through 15 years of incremental development

The application had accumulated features across many releases, developers, and business priorities. Its clinical workflows were valuable and familiar, but interface decisions were made locally as individual features were built. No formal design function, component library, or front-end ownership model existed. Engineering focused primarily on server-side behavior, while UI decisions were often made directly inside individual pages.

[Asset: Product timeline showing the platform’s age, technical stack, and release constraints.]

The interface had become inconsistent, brittle, and progressively slower to change

Typography, spacing, color, controls, language, and page structure varied across the application. Similar actions appeared differently, while unrelated actions sometimes looked identical. Table-based layouts, fixed dimensions, inline styling, and server-rendered markup made small changes difficult to predict.

Developers repeatedly rebuilt existing patterns, QA lacked a shared consistency standard, and users encountered changing rules across familiar workflows. The system needed modernization without disrupting a product hospitals relied on for time-sensitive work.

[Assets: Annotated legacy screen; inconsistent button groups; table-based form layout; verbose instructional copy.]

I treated the design system as delivery infrastructure, not a visual reskin

I considered three approaches:

• Apply a cosmetic refresh to color, typography, and spacing.
  
• Improve components opportunistically whenever a related feature appeared.
  
• Establish a complete token, component, layout, and governance foundation that could ship incrementally.
  

Design tension: The interface needed to become more consistent and maintainable without disrupting workflows experienced clinical users already trusted.

I chose the third direction because it addressed both visible inconsistency and the process continually producing it.

1. Preserve established workflows.
2. Build reusable tokens, components, and layouts.
3. Pilot the system on representative screens.
4. Ship patterns through normal engineering review.
5. Document components as they became production-ready.

The tradeoff was a slower visual transformation in exchange for lower implementation risk and stronger engineering adoption.

[Decision asset: Compare cosmetic refresh, opportunistic cleanup, and incremental system adoption.]

I refined each pattern through prototypes, browser implementation, review, and QA.

Webflow and HTML prototypes made behavior reviewable before production. Browser testing exposed cascade, responsiveness, and server-rendering issues. Product and SME review protected workflow continuity, while engineering and QA tested compatibility and regression risk. Production implementation revealed exceptions that needed to become part of the component rules. The project did not include formal task-based usability benchmarking, so its strongest evidence concerns delivery efficiency and system consistency rather than measured user performance.

[Validation asset: Prototype review, technical validation, QA, production learning, and unmeasured outcomes.]

Incremental delivery turned design-system thinking into working product infrastructure

The project demonstrated that a design system could gain traction in a technically constrained organization by solving immediate delivery problems rather than beginning as a separate design initiative. Building through active releases helped me earn trust, understand the application at implementation depth, and create standards grounded in actual product behavior. The strongest outcome was not visual consistency alone. It was the creation of a shared operating language across design, engineering, product, and QA. Tokens, components, layouts, documentation, and production code became connected parts of the delivery process rather than isolated design artifacts.

I would strengthen the system’s foundations, technical environment, and measurement

• Begin from first principles. I would establish the system’s rationale, principles, taxonomy, accessibility standards, and governance model before composing improvements feature by feature. The incremental approach was practical, but a clearer conceptual foundation would have made later decisions easier to explain and maintain.
  
• Advocate for migration beyond .NET Web Forms. The aging stack constrained semantic markup, responsive behavior, component architecture, front-end tooling, and the degree of implementation ownership design could assume. I would promote a planned move toward a modern, component-based platform before those limitations became an even greater product risk.
  
• Connect system adoption to user performance. I would add component-adoption tracking and baseline usability measures for high-frequency workflows. This would show which standards improved clinical work—not only which ones accelerated delivery.
  
• Create a versioned implementation library. I would evolve the system toward a testable, independently versioned component package or Storybook environment that could support multiple products without remaining tightly coupled to individual server-rendered pages.