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.

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 to find these inconsistencies, establish a database of them, and the findings would then lay the foundations of this design system.

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 lead to 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 an UX conventions (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 what looked at design systems, notably Material, Carbon and Spectural, 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 exact units engineers build with (hex codes, px values, component states)

2. To be explicit, with detailed examples if a rule is not clear

With all this set out, It now needed to be written. 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

Before the system, design decisions were made in the moment. Some components in Storybook but it documented what existed, not why. Values were chosen on feel, not rules. In addition, the legacy program, Q, was sharing some code still in Displayr making a complete Storybook system harder. As the sole designer, that meant engineers either guessed, or asked me. The system changed that. In the 2–3 weeks after the system shipped, design decisions were made based on the documentation and real decisions only occurred in edge cases. More importantly, when my internship ended, the knowledge didn't leave with me. Engineers had a single source of truth that could outlast any individual designer.

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 connected 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 overscoped it. 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 therefor 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, but as I was the only person working on the system at the moment, it could be cut.

I learned so much about Figma, design systems, engineering requirements, time management, 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.