SharePoint Design System
2023–PresentTech Lead — Microsoft
The problem
Some systems get to start clean. This one didn't.
Not from scratch. Not the greenfield project, the clean slate, the blank Figma file. Most design system work happens inside something that already exists — legacy code, inherited decisions, teams that have been building their own solutions for years because nothing better was available.
The SharePoint Design System (SPDS) was built from a starting point of reality. A component library tied to business logic, feature flags, and migration debt. No shared token strategy, no documentation, no contribution model. The real work was not the migration — it was building the place where the solution could live once, so teams could stop repeating themselves and focus on what actually needed their attention: the product, the data, the experience.
That is what SPDS became. Not a design system that started from nothing, but a system built from what was real — and shaped into something teams could actually build on.
When Microsoft began moving from Fluent v8 to v9, the scale of the problem became impossible to ignore. Every feature team was being asked to solve the same migration alone. Bespoke components needed by multiple teams were being built in parallel — different implementations, different tradeoffs, growing debt with nowhere to share the solutions. The question was not only about how to migrate. It was how to build something that could absorb that migration — and the ones after it — without starting over each time.
The approach
The answer was to extend Fluent, not replace it. SharePoint-specific behavior lives at the surface — props, slots, composition, usage patterns — while the deeper foundation stays Fluent. That kept the migration path open and created a contribution path: components mature in SPDS, then move upstream when ready. If a migration solution is found for one component, it lives in SPDS once — consumed by every team. If multiple teams need the same pattern, it gets built once to a shared standard.
In practice
Storybook as alignment infrastructure
Designers had no way to interact with components before they reached production. Engineers had no single reference for implementation. Reviews happened late. The Storybook build, documentation structure, and internal publishing path were all part of that work — kept internal-access only to ensure it stayed within Microsoft. Once live, Storybook became part of the pull request process — each PR generated a temporary Storybook link, creating a visual review step inside code reviews. That made it possible to bring designers into the review process and give them approval privileges for design system code changes, alongside an engineering approver inside or outside the design system team. Design validation moved earlier. Implementation became inspectable before it shipped.
The Toolbar as the first proof point
The first SPDS component was the rich text editor (RTE) Toolbar — migrated from Fluent v8 to v9, documented in Storybook, rolled out to 100% of production without incident. It was built for reuse from the start and later adopted across Amplify Toolbars, Editorial Cards, FAQ, and other Microsoft 365 surfaces. It set the standard for what an SPDS component should be. When a custom typography feature was added to the RTE Toolbar built on SPDS, it was completed in days — the same work had taken over a month in the previous codebase.
Outcomes
- 100% production rollout of the SPDS Toolbar without incident
- Custom typography feature delivered in days — the same work previously took over a month
- Storybook integrated into the PR process, with designers as code reviewers
- Component adoption expanded across multiple Microsoft 365 surfaces
- Team grew from one UX engineer to a four-person UX engineering (UXE) team