INCYT's problem wasn't just visual inconsistency, it was that three departments were operating off three different understandings of the same product. A design system was the answer, but only if it could serve as a shared language across design, engineering, marketing and sales.

INCYT had three departments. Each one was operating off a different understanding of the same product. Sales and Marketing was promising features based on what the software looked like in decks. Engineering was building based on what made technical sense. Design was validating in a vacuum, handing off to developers who had no shared reference for intent. Nobody was wrong exactly. There just wasn’t a single source of truth that all three could point to.

That’s what the design system was actually for.

Fragmented components, duplicated patterns, hardcoded quirks — those were visible. But they were the result of a deeper misalignment: each department had developed its own mental model of the product. Sales marketed what they could show. Engineering built what they could scope. Design validated what it could test. Without shared language and shared rules, every handoff was a translation exercise with room for error.

A design system creates a single source of truth that all three can work from. Not just a component library for designers, but a documented set of rules and intentions that makes the product legible across the organization.

Before writing a single token, I needed to know what actually existed. A full component audit across all three platform areas — cataloguing what was there, what was duplicated, what was hardcoded, and what could be salvaged. The same component existed in multiple flavors with no clear owner. That inventory became the foundation for everything that followed. You can’t make decisions about what to standardize if you don’t know what you’re standardizing.

The system was built in Figma with design tokens, variants, and documentation written for the people who would actually use it — not for a design review. Component specs in language engineers could act on. Variants that covered real edge cases. Every decision with a reason attached to it.

That last part — the reasoning — was the piece that made it work across departments. Sales needed to understand why something was designed a certain way to communicate it accurately. Engineering needed intent, not just specs, to build it faithfully. Documentation that only told you what wasn’t enough. It had to tell you why.

The design system became INCYT’s first real shared language across design, engineering, and sales. Handoff time dropped by 50% — a number I tracked and can stand behind. Collaboration workflows and delivery timelines improved by 20% across the team. New features could be assembled from existing components rather than designed and built from scratch each time, which meant fewer QA cycles and fewer misalignments between what was promised and what was shipped.

The WCAG accessibility work brought components to a compliance baseline that hadn’t existed before. That one mattered beyond efficiency.

What I’m less certain about is long-term maintenance. Design systems need a keeper after the person who built them moves on. I built it to be maintained, with documentation, with reasoning, with the junior designers who worked alongside me understanding not just how to use it but why it worked the way it did. Whether it held is a different story.

The audit was thorough but slower than it needed to be. Cataloguing everything before building anything felt rigorous but delayed value. Starting with the highest-traffic components and shipping those while continuing the audit would have given departments something to align around earlier, and built organizational trust in the system faster.

The documentation was solid. What I’d add: a structured cross-department onboarding session. Not a Figma walkthrough for designers, but a session where sales, engineering, and design sit in the same room and work through the system together. That shared experience of understanding the rules at the same time, together, is something no file can fully replace.