A content system for Microsoft's design-system docs

CxD's products are built on Fluent 2, Microsoft's enterprise design system, and consume its global tokens. But Fluent 2 serves all of Microsoft, so on its own it's too general to guide CxD's teams. They needed their own documentation, specialized for how Teams, OneDrive, and SharePoint actually use it.

That guidance had almost no clear ownership, and people had stopped trusting that what they found was current. The expectation was an audit: gather the scattered guidelines and consolidate them into the new doc site. I made the case for something more durable. A consolidated doc would be stale the day it shipped, so the real job was a content system: an IA, a content model for every page type, and a CMS schema precise enough to build without interpretation. I led the team there.

This was a content-first project from beginning to end, and it started with investigation on two fronts: the people who would use the docs, and the medium they would live in.

I started with the people, because a doc site nobody trusts is just more noise. The CxD designers told me the same thing in different words: they couldn't find what they needed, and when they did, they couldn't tell if it was still true. Then I turned to the artifacts, auditing every foundation token by token across three products and four platforms, to see how deep the drift really ran. Color made it concrete:

⤢

Part of the foundations audit: color tokens traced across products and platforms, each flagged for gaps and contradictions

By the end of the investigation, three findings had reframed the whole project:

The drift wasn't only in the docs. The products themselves sat on Fluent 2 unevenly, which is exactly why "audit and consolidate" was never going to hold:

That was the turning point. The ask was to audit and consolidate, but the evidence said consolidation alone would never stay current. We didn't need better documentation, we needed a system that produced it, and I made that case to the team. The brief became clear: a content system for the CMS that serves everyone who touches the docs, the designers, content designers, and engineers who read them, and the authors who keep them current.

I rolled off before launch, but the system was built to keep growing. Four frameworks were scoped and shaped, each ready for the team to take further.

Governance workflow

The content models plug into a contribution workflow, so a guideline moves from idea to published page on one defined path instead of an ad-hoc request.

⤢

The contribution workflow: author, review, ship, on one defined path

By the time I rolled off, the system was real end to end: an IA across the product ecosystem, a content model for every page type with a complete Statamic Blueprint schema, a component library for the reader-facing site built with a visual designer, and the site itself producing pages from the CMS. I had audited all the foundations and authored the content for the launch site.

An engineer built the Blueprints straight from that schema, no interpretation required. I handed off the forward frameworks with their shape defined: the token architecture, the notification framework, the design-system principles, and the governance workflow. The system was built to cut a support burden measured in hundreds of hours a month and to make "if it isn't there, it doesn't exist" actually true.

I was hired to consolidate documentation. The most valuable thing I did was reframe the job: a consolidated doc would have been obsolete on arrival, so I made the case for a system and brought everyone with me. That is the work, the judgment about what to build, not just the building.

Most documentation work stops at Phase one: write the page. Phase two builds a template: define the sections and give contributors a guide. This needed Phase three, a field-level Blueprint where every slot named its data type, its prompt copy, and the editorial rule behind it. An engineer built the CMS from that spec without asking what I meant.

That is the same pattern I carried into TurboTax Canada: designing the system that determines how content gets made, not just making the content. The through-line isn't the tools or the domain. It's the altitude, working on "what is the system through which this work happens" rather than "what should this one thing say."