One System, Many Surfaces
How product-specific UX needs became a scalable design-system operating model across four Microsoft Security portal pillars — a security-focused layer on Microsoft Fluent that grew from components and page templates into security, Copilot, and AI pattern collections and frameworks: flexible enough to compose whole applications, and now part of the AI chat canvas itself.
Start hereThe quick context
- What is SFE?The Security Fluent Extension — a security-focused design-system layer built on Microsoft Fluent patterns, tailored for Microsoft Defender and Security experiences.
- What is Fluent?Microsoft's design system and UX framework foundation — the shared language SFE extends for security-specific needs.
- The roleA shift from product-team representative to design-system adoption and clearance lead — translating security UX needs into reusable system guidance.
- The shiftFrom "contributing to a component library" to standing up the operating model that lets many teams adopt, migrate, and contribute coherently.
The problemSimilar problems, solved a dozen different ways.
Across a complex security product surface, teams were solving similar UX problems in different ways. Multiple design systems and component libraries caused confusion and inconsistent portal experiences; migration work surfaced inconsistent quality, design-engineering misalignment, and UX gaps caught late.
How might we give many product teams one coherent, security-focused system to build on — without slowing any of them down?
The through-lineFour portal pillars, one coherent system.
The goal wasn't a bigger component library; it was an operating model spanning four Microsoft Security portal pillars — a shared system plus the workflows, handoffs, and rhythms that make adoption the path of least resistance.
Four portal pillars, one system. Across four MSEC portal pillars, scattered libraries and one-offs converge onto a single security-focused system built on Fluent — the same UX problems, solved once and reused everywhere.
The flagship patternThe Listpage — security's most common surface, standardized.
List pages are core to security workflows: analysts and admins use them to triage alerts, review entities, manage assets, inspect recommendations, and move into investigation flows. Across MSEC portals the same surface — dense lists, filters, tables, actions, status, and investigation entry points — was being rebuilt differently every time.
The Listpage work turned a repeated, inconsistent pattern into a coherent, SFE-backed page standard across Microsoft Security portals — defining how list pages should behave, not just how they look: page structure, command areas, filtering, search, selection, bulk actions, empty / loading / error states, details panels, responsiveness, accessibility, and Fluent/SFE alignment.
Identify the repeated UX patterns across MSEC portals, consolidate them into reusable SFE guidance, and help product teams adopt a more coherent structure — so users get a predictable experience moving between Microsoft Security products, and teams stop reinventing the pattern per product area.
It's systems design in practice: connecting product needs, portal-level coherence, design-system governance, and practical adoption across teams.
Inside the systemOpinionated, documented guidance — not a component dump.
The Listpage ships as a documented standard: page anatomy, filtering and navigation patterns, and insight placement, each with clear rules for when and how to use it. A few pages from the library — tap any to view:
The operating modelMaking the right way the easy way.
A design system only matters if teams actually adopt it. The connective tissue around the components — the layers that turn a library into something teams reach for by default — is what made it stick.
The operating model. Templates to start, a contribution path to grow, migration to adopt, accessibility to ship inclusively, and support rhythms to keep everyone moving — the system plus everything that makes it stick.
Where it's headingBeyond components — patterns, collections, and the canvas.
The system didn't stop at components and page templates. It grew into security, Copilot, and AI pattern collections and frameworks — components rebuilt to compose flexible applications, and patterns that now live inside the AI chat canvas itself.
From a component library to an AI-native pattern system. The same foundation now spans reusable components, security & Copilot pattern frameworks, flexible application building blocks, and the AI chat canvas.
What was builtThe proof points.
- The Listpage standardTurned security's most common surface — lists, filters, tables, actions, and states — into one coherent, reusable page standard across portals.
- Reusable page templatesGave teams a proven starting point, reducing one-off layouts and design drift.
- Contribution workflowsDefined how new patterns get proposed, reviewed, and folded back into the system.
- Migration enablementPlanning and guidance to move existing Defender surfaces onto the system.
- Accessibility enablement & handoffMade accessible patterns the default and clarified the design-to-engineering handoff.
- Prototype infrastructureStood up shared prototyping so ideas could be tried and validated faster.
- UX–engineering alignmentClosed the gaps between design intent and the components teams actually shipped.
- Office hours & support rhythmsA predictable cadence that kept adopting teams unblocked.
- Cross-team coherenceAligned many product teams around one security-focused visual and interaction language.
- Copilot & AI pattern frameworksPattern collections and frameworks for security and Copilot experiences — guidance, not just components.
- Flexible-application componentsComponents rebuilt to compose whole applications, not only single pages.
- AI chat canvas patternsExtending the system into the Copilot canvas so AI experiences stay coherent with the rest of the portal.
Ways of workingAdoption is a relationship, not a mandate.
Getting many teams onto one system is a people problem as much as a design one. The work stayed close to product, engineering, design, and accessibility partners throughout — earning adoption rather than enforcing it.
- Translator. Product-specific security UX needs were turned into reusable system guidance the whole org could apply.
- Design-to-engineering alignment. Intent and implementation stayed in sync so patterns shipped the way they were designed.
- Enablement over enforcement. Templates, clear contribution paths, and office hours made adoption the path of least resistance.
- Accessibility as a default. Inclusive patterns were built into the handoff instead of leaving each team to rediscover them late.
ImpactWhat changed.
| Area | Outcome |
|---|---|
| Coherence | Many teams converged on one security-focused system built on Fluent. |
| Adoption | Templates and a clear contribution path made the system the default starting point. |
| Accessibility | Inclusive patterns moved earlier — built in, not caught late. |
| Design–eng alignment | Fewer gaps between design intent and the components teams shipped. |
| Team focus | Less time re-solving solved problems; more time on product-specific UX. |
Outcomes are described qualitatively; specific metrics are omitted unless approved for external publication.
One-line takeawayAn operating model, not just a library.
Product-specific UX needs, turned into a scalable design-system operating model across four Microsoft Security portal pillars — growing from components and templates into security, Copilot, and AI pattern frameworks that now reach all the way into the AI chat canvas.