Building a design system

The product

Teams Admin Center is where IT admins set up Microsoft Teams for their whole organisation.

Open full-size screenshot in a new tabFull size

123

The design system

A design system is a kit of shared parts, like LEGO bricks: buttons, switches and dropdowns that fit together, with rules for using them.

The problem

Fluent wasn’t built for admin work, so designers filled the gaps themselves. Take one dropdown.

1. All domains

   In the library

   No status icon.

2. All domains

   Copy 1

   Detached (copied out of the library), icon added.

3. All domains

   Copy 2

   Copied from copy 1. New spacing.

4. All domains

   Copy 3

   Copied again. Icon moved.

Three versions, none written down. Multiply that by every component: outdated parts, colours that failed contrast, and code on Fluent versions no longer supported.

The approach

Not “just use Fluent”. Not another design system. A decision for each of the library’s 36 components, written down with its reason.

Three examples

Design system calls are subjective. The right one depends on the product, its users and how the team works, so the same component can be Adopt for one team and Invent for another. Three of ours:

Switch: a new component

Admins often edit several teams at once. When those teams disagree, Fluent’s switch can only say On or Off. Without an in-between state, we were functionally lacking.

Open full-size screenshot in a new tabFull size

Open full-size screenshot in a new tabFull size

Fluent’s answer is a checkbox, as the Microsoft 365 admin center uses. But every setting in Teams Admin Center is a switch, and swapping them all would disrupt a huge number of admins.

So we built a net new component, outside Fluent: a switch with a Mixed state, made from Fluent’s own colours and accessibility rules, and documented.

Team A

Edit sent messagesOn

Delete sent messagesOn

+

Team B

Edit sent messagesOff

Delete sent messagesOn

=

Team A + Team B

Edit sent messagesMixed

Delete sent messagesOn

Cost: one more component we maintain ourselves.

Padding: kept as Fluent’s

Fluent leaves space around some components for the keyboard focus ring. At rest, a form’s left edge goes ragged.

A settings pane at rest

FluentBy hand

Open full-size screenshot in a new tabFull size

8px

Open full-size screenshot in a new tabFull size

Lined up looked better, and the Fluent team agreed. We still kept Fluent’s spacing: hand-made fixes drift between teams, and when Fluent fixes it, every screen gets the fix.

Cost: a ragged edge, for now.

Table checkboxes: fixed once

A quality audit found a select-all that didn’t look clickable, and round checkmarks that suggested picking only one row.

Selecting rows in a table

BeforeAfter

We fixed the table component, not each page, so every table got the fix.

Keeping it consistent

• Smallest parts first

  Buttons and checkboxes before tables, since fixes flow up into everything built from them.

• Named colours, not codes

  Fluent’s named colours replaced hard-coded ones, so one change reaches every screen.

  A hard-coded colour code, replaced by Fluent’s named colour: #5B5FC7 became Brand Background

• One component per sprint

  Each documented as it shipped.

• Review before building

  Weekly office hours, and a design review before other teams change the product.

Outcome

• 36 components decided

  Each departure from Fluent written down with its reason.

• Three-quarters migrated

  Of the foundation components, moved to current Fluent or in review by mid-year.

• Review before building

  Became the norm for other teams changing the product.

No branded launch, by design. I moved teams mid-migration and handed over the tools and open questions.

What I’d do differently

• Publish decisions from day one

  The reasoning was the most valuable output.

• Measure off-system screens

  Detach counts alone under-reported the problem.

• Make review required

  Build it into code review, not goodwill.

• Write rules AI can follow

  Not just rules a designer can read.