STEPHANIE SULLIVAN
FLUENT 2 // DOCUMENTATION CASE STUDY
Making a system
understandable.
A cross-functional sprint to turn Fluent 2 guidance into a useful documentation experience.
✦DOCUMENTATION ✦ DESIGN LANGUAGE ✦ WEB COMPONENTS ✦ CONTENT DESIGN ✦ PARTNER ALIGNMENT ✦ ILLUSTRATION ✦
THE PROJECT
Fluent 2 documentation site
THE TEAM
Design + content + engineering
MY FOCUS
Design language + component pages
THE PACE
Cross-functional deadline swarm
01 // THE ASSIGNMENT
A design system needs more than components. It needs a way in.
The Fluent 2 docsite had to translate a broad design language into guidance that people could find, understand, and apply.
With a deadline approaching, design, content, and engineering swarmed the work together. I contributed pages within the Design language section, created web component pages, gathered and refined source material with partner teams, and produced illustrations that helped the guidance land visually.
Aa
Content
Shape raw subject-matter expertise into clear, structured, usable guidance.
</>
Engineering
Turn the documentation model into a working site under a shared delivery timeline.
*
Design
Build page structures and visual assets that reinforce what each guideline means.
02 // INFORMATION MINING
Collect the information. Find the structure. Refine through experts.
The Layout page began with information collected from experts across partner product teams, not with a finished story.
I audited the available guidance, identified what belonged on the page, and refined it through repeated partner conversations and review checkpoints. The work was as much about synthesis and alignment as visual design: deciding what readers needed, in what order, and how diagrams could make spatial concepts easier to scan and understand.
03 // THE OUTCOMES
Two kinds of pages. One coherent system.
The foundational guidance explains how Fluent works. Component pages show teams how to put it into practice.
Design language
Foundational pages that make principles, such as layout, concrete enough to apply across products.
Web components
Reference pages that connect component behavior, visual examples, and implementation guidance.
04 // THE DETAILS
Visuals helped the guidance land.
I created illustrations to make system concepts easier to recognize and remember while scanning the documentation.
The artwork was not decoration. Each visual reinforced a concrete point in the surrounding guidance showing page structure, spatial relationships, or how parts of the system connect.
Final thoughts
01
Documentation is product work
Readers need coherent information architecture, clear interactions, and useful visual explanation, not a repository of facts.
03
Swarming requires trust
A shared deadline works when design, content, engineering, and partners can move in parallel while staying closely aligned.
02
Checkpoints create quality
Frequent reviews reveal gaps while there is still time to improve the structure, content, and assets together.