Design systems for 200-person programs: lessons from enterprise healthcare

For nearly five years I worked as a UI designer and UI developer on a healthcare program with a team of more than 200 people. The goal was to revamp a suite of legacy web applications into modern, responsive products: a vendor management system for healthcare staffing, a credentialing and compliance platform, and a mobile app for travel nurses and allied professionals.

When that many designers and developers ship across several products at once, one thing becomes obvious: the design system is not a nice-to-have. It is the only thing that scales.

Consistency cannot depend on memory

In a small team, consistency lives in people's heads. In a 200-person program it cannot. People join and leave, teams work in parallel sprints, and each product has its own deadlines. Without a shared system, every team quietly invents its own buttons, panels and charts.

The program had a shared UI framework used across design teams. Contributing to it changed how I worked: instead of designing a screen, I was often designing the piece that dozens of future screens would be built from.

What went into the framework

The parts that paid off most were not the glamorous ones:

Logos and lock-ups for each product, so every app header looked like part of one family
Image treatments, so photography felt consistent across products
Summary side panels, a reusable template for showing details next to a list
Charts with agreed colours, labels and spacing
Text fields with every state defined: default, focus, filled, error, disabled

Define the states, not just the happy path. Most inconsistency hides in error and empty states.

Patterns, not just components

Components are the vocabulary; patterns are the grammar. On the staffing product, staff lists needed to work for very different users and devices. We defined a pattern instead of a screen:

A default overview and a search state
Filter dropdowns with consistent behaviour
A dense grid layout for desktop power users
Card views that reflow for tablet and mobile
An empty state that guides the user to narrow the search, instead of showing a blank table

Once the pattern existed, new lists across the product were faster to design and easier to review.

Close the loop between design and code

I worked on both sides: creating wireframes and visual designs, then building ReactJS components and pages and fixing HTML and CSS issues so the product matched the design. That dual role taught me a few things:

Name things the same way in Figma and in code. It removes a whole class of misunderstandings.
Share dev-ready assets and links early. Waiting until the end of a sprint creates rework.
Write UX and UI user stories with the product owner. A story with clear acceptance criteria is the best spec a developer can get.
Fix the system, not the screen. If the same bug appears twice, the component needs changing.

Accessibility belongs in the system

Healthcare products are used by people under pressure, on every kind of device. Building accessibility into components, with contrast, focus states and labels following WCAG 2.1, means every team gets it by default instead of retrofitting it later.

What I would do on day one of any large program

Agree on the small set of foundations first: colour, type, spacing, states.
Pick two or three high-traffic patterns and standardise them before anything else.
Give the system an owner and a simple way for teams to contribute.
Document decisions, not just components, so new people understand why.

A design system for a large program is less a library and more an agreement. The craft is in making that agreement easy to keep.