The foundational design system

Context

Displayr is an advanced, AI-focused data insights and dashboard platform used by leading market research agencies worldwide. I completed a three month internship with them in early 2026, where I was the sole designer.

Overview

Displayr did a major UI redesign in 2023. This redesign did not establish a design system, leading to design inconsistencies as the software scaled. I conducted an audit of the software and found 87 groups of inconsistencies. These results laid the foundations of their first design system, containing 27 components, with documentation and Figma assets.

Process

The audit was key for establishing what rules were already present in Displayr’s UI. This was better than creating rules from scratch because that would likely lead to creating more inconsistencies. I checked each rule against the following criteria to decide which rule would “win out”:

1. Which rule is most common?
2. Does it break a UX convention (i.e. green for success, red for danger)?
3. Is it accessible (i.e. minimum font size, WCAG 2.1 AA color contrast)

With the rules now established, I had to work out how to structure the documentation. I looked at other design systems, notably Material, Carbon and Spectrum, to give me an idea of the structure and requirements of design system documentation.

When developing the design system I had to make sure it did two things

1. Written in the language engineers build with (hex codes, px values, component states etc)
2. To be explicit, with detailed examples if a rule is not clear

When tackling a project of this scale, I find it is best to approach it with the 80/20 rule in mind. That is, I can cover 80% of the use cases, with only 20% of the documentation. This made it much easier to create rules for many components quickly, then coming back to give more detailed documentation.

Outcome

Design decisions used to take a lot of time as there were no definitive values or rules set. On top of that, Displayr also had to maintain a legacy program, Q Software, which was sharing some code with Displayr.

In the 2–3 weeks after the system shipped, design decisions were made based on the documentation, only escalating to me or my PM in edge cases, which were then added to the system docs. The entire company now had a single source of truth that could outlast any individual, with a complete log of all changes made, 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 a few hours, minimum, as well as increase the design accuracy of these prototypes.

Reflection

Looking back, I was overambitious. I wanted to ship something comprehensive, with complete coverage to a similar level of detail as the design systems I viewed. As the only designer in the company and therefore the only person working on this system, it was unrealistic, so some cuts had to be made. An important part of a late stage design system is design tokens. These allow values to be defined in one place, then referenced across the system. For a large scale design system, tokens are a necessity, to reduce inconsistencies while providing use context. As I was the only person working on the system and this was a version 0, it was cut.

I learned so much about Figma, design systems, engineering requirements, time management, AI integration, but also about managing self-expectations. I expect a lot from myself, and certainly did that here. My Product Manager helping me manage this was a huge help and it allowed me to get the design system done in a timely manner, and work on more user facing problems for the rest of my internship.