The foundational design system
Creating a 100-person B2B SaaS company's first design system.
Role
- UX Designer
Timeline
- Jan — Mar 2026
Tools
- Figma
- Notion
- Claude Code
Skills
- System Design
- Design Documentation
Overview
Displayr did a major UI redesign in 2023. This redesign did not establish a design system, and over time, design inconsistencies developed as the software scaled and the company grew. In early 2026 I was brought in to audit the software, create a design system and remove inconsistencies in their UI.
Key moments
As this was my first time ever doing anything to do with a design system, I looked at other companies design systems. A few of them were Googles Material Design, IBM's Carbon and Adobe's Spectrum. I looked at how they were structured, how detailed they were, what the contents were and ultimately, what is required in a design system.
This was only a 3 month internship and with other things planned, and already almost a month in, time was running out. I'd fully documented about 5 components in just over a week and there was a total of about 40 to do. After a meeting with my Product Manager, it was decided that we scale down to the core components of Displayr, and build out the system from there, but also scrap some of the detail in the documentation. It was a version 0 after all and didn't need to cover everything
Result
In total, 27 components where catalogued. 3 of the 27, simple ones. Push them through their states and the spec underneath shows exactly what the documentation tells an engineer to build.
- Background
- periwinkle/400#5159F5
- Label
- midnight/100#F2F5FA
- Border
- None
- Height
- 26px
- Padding
- 2px 8px
- Radius
- 8px
- Label type
- 12px / 22px Regular
- Icon ↔ label gap
- 4px
Process
The first step to the design system was auditing the UI. This was key for establishing what rules were already present in Displayr’s UI which was better than creating rules from scratch because that would likely lead to creating more inconsistencies. I checked each rule against three criteria to decide which one would “win out” ranked as the following:
Which design/rule is most common?
Does it break a UX convention (i.e. green for success, red for danger)?
Is it accessible (i.e. minimum font size, WCAG 2.1 AA color contrast)?
The main people reading this documentation would be engineers turning it into code, so each component had to be written in the following ways:
Hex codes, px values and component states, not descriptions like "a light grey" or "some padding".
Clear black and white language. Where a rule could be read two ways, a worked example settles it.
Outcome
Without definitive values or rules, every design decision took time. In the 2–3 weeks after the system shipped, checking the documentation became a real answer. Only edge cases reached me or my PM, and each one was added to the docs. The company now had a single source of truth with a complete log of every change and why.
Prototyping
As I finished building the system, Figma released better integration with AI Agents through their MCP. Since each component had also been created in a Figma library, I could connect it, the documentation and Claude Code together and create a rapid prototyping workflow, completely grounded in the design system. This reduced ideation time by at least an hour, as well as increase the design accuracy of these prototypes.
Reflection
Looking back, my expectations were too high. I wanted to match the depth of the design systems I'd studied, which was unrealistic as the only designer on a v0. Design tokens, which define values in one place and reference them across the system, are essential for a large system but were the right cut here.
I learned a lot about Figma, engineering requirements and AI integration, but most of all about managing my own expectations. My Product Manager helped me do that, and it let me ship the system on time and spend the rest of my internship on UX research problems.