Increasing design system consistency & adoption
Web Pattern Library for Atlassian.com
Visuals are reconstructions.
Overview
Designers kept copying Atlassian.com components and drifting from the library. I rebuilt buttons and the tabs pattern so they work as-is. Buttons shipped on every page in the brand refresh, and the tabs pattern became the web team’s first usability-tested pattern. I owned the tabs pattern end to end. On buttons, a brand designer finalized the visuals.
- Team
- Web Platform designers
- Engineering
- Brand design for buttons
- My Role
- Product Designer
- Scope
- Buttons
- Tabs pattern
- Component documentation
- Timeline
- 2023–2024
- 6+ → 1
- Tab variants condensed into one pattern
- 1st
- Usability test for the web design system
- 40+
- Components with updated guidance
- Sitewide
- Buttons shipped across Atlassian.com
Design system: Audit
Why did copies keep drifting?
~30 designers and content practitioners used the library, but it was still evolving, so teams started from existing pages or outdated Figma files. They copied the whole tabs pattern, then changed its spacing, sizing, and font weight to fit their needs.
Shared updates didn’t reach those copies, so live pages drifted apart. My goal: make shared components flexible enough that designers didn’t need to rebuild them.
Illustration of pattern drift
Common pattern
Drifted pattern
Tabs pattern: Build
What should be configurable?
I started with an audit of the tabs pattern in use and found 6+ versions, each with its own pill size and spacing. Too little flexibility meant more breaks. Too much made the pattern useless.
I rebuilt it so tab count, content layout, and screen size could vary, including the newer layouts that came with the brand refresh, while spacing, sizing, and font weight stayed shared. I built it from linked components, so even when a designer broke the pattern, component updates still reached their copy.
Tabs pattern: A/B test
How do designers actually use it?
Flexibility only helps if people can find it. Instead of settling it in critique, I tested two ways to set the tab count. Eight designers who regularly used the library split across the two versions, then added tabs, removed them, edited labels, and changed the layout. I described only the result I wanted, so I could watch how they naturally approached the pattern.
A
4 designers
Configuration A · Rebuilt
B
4 designers
Configuration B · Rebuilt
With the pattern selected, designers set the tab count with checkboxes or a dropdown. Try both.
What the sessions showed
Tasks
- 1Add tabs
- 2Remove tabs
- 3Edit tab labels
- 4Change the layout
- 4 of 8
- didn’t find the tab count controls until the second task
- 2 of 8
- found them while editing labels in the panel, because their eyes were already there
- 2 of 8
- didn’t notice the controls until the very end
Designers didn’t consistently find the controls. Some edited layers directly instead.
That made the choice between two options the smaller question. The bigger one was how to make supported controls easier to find, because controls designers can find should mean fewer broken components. I documented the plan, tasks, and findings in detail so the team could reuse them. It was the first usability test for the web design system.
A surprise: because the tabs were built into the pattern, deleting one only hid it, which I hadn’t expected. Nothing broke, and some designers preferred hiding and unhiding tabs that way.
Tabs pattern: Impact
What the test changed
Configuration B won, and I rewrote the control labels and descriptions so designers could find them without editing layers.
What surprised me: I went in to compare two options and came out with a bigger question about how designers actually use a pattern.
Buttons: Build
What did a button need to handle?
A button looks simple until a label runs long or an icon joins it, so I started with the component’s specifications and construction.
I decided every spec: corner radius, padding, and sizes, how much text a label can hold before it wraps or cuts off, the rules for icons, and each interaction state, down to the motion from default to hover to focus.
Component anatomy
| Default | Hover | Pressed | Focus | Loading | Disabled | |
|---|---|---|---|---|---|---|
| large | Try now | Try now | Try now | Try now | Try now | Try now |
| small | Try now | Try now | Try now | Try now | Try now | Try now |
Handing off through a brand refresh
When the brand refresh came, the biggest change was color. A brand designer re-paired the button colors with the new palette, building on the foundation I’d set. I annotated specs for engineering and joined QA calls, and the buttons shipped across Atlassian.com. I also updated guidance for 40+ components (~80% of the library), so designers knew when to use a button or a link, which size to pick, and how to add an icon without breaking it.
Buttons: Impact
Shipped on every page of Atlassian.com
From sign-in to product pages, through the brand refresh. Guidance for 40+ components told designers when and how to use it.
Outcome
What the work delivered
- 6+ → 1
- Tab variants condensed into one pattern
- 1st
- Usability test for the web design system
- 40+
- Components with updated guidance
- Sitewide
- Buttons shipped across Atlassian.com
Across both, I connected Figma construction, the designers using it, and the specs engineers needed.
Want to hear more about managing a design system?
Ask me about the internal usability test, what the tabs pattern let designers change, and taking buttons through a brand refresh.