Brightspeed BusinessEnterprise Design systemSelf-initiated

QA in an hour, not a day or two. Brightspeed Business’s design system, rebuilt with a spec sheet for every component.

Brightspeed Business already had a design system when I joined the account, and QA kept catching the same misses. I asked the developers what would help, then took the system over, rebuilt its foundations, cleaned up every component, and gave each one a spec sheet they could build from and check against.

Role
Product Designer, the only designer on the account
With
Developers
Company
Brightspeed Business, via CGI
Year
2024
Scope
Design system, tokens, component cleanup, dev specs, design QA
What happened
QA went from a day or two of my time to an hour at most, with far fewer rounds of back and forth after it.
The color page The typography page The Solutions Card spec sheet The spacing page The buttons page

52color primitives

75tokens

48text styles

The misses

QA kept catching the same four things.

Spacing, font sizes, component details and how things behaved. Every QA round meant going through the build, screenshotting what was off and writing up what the spec said. That took a day or two, and the back and forth went on after it.

The specs existed. They just weren’t all in one place.

The spacing page: the space between sections, titles, headlines and paragraphs, in pixels, at desktop, tablet and mobile
Spacing, the most common miss
Foundations

Rebuilt from the tokens up.

The dev team was newer and still learning how to build some of these patterns, so every QA round took a lot of my time. I asked the lead developer what would get the team up to speed. His answer was one source of truth, somewhere I could point them to.

I’d been leaning that way already. Hearing it from inside the dev team settled it. It would make their job easier, and mine.

I took the system over and rebuilt its foundations: the color primitives, the tokens that point to them, and a type scale and spacing rules for desktop, tablet and mobile.

Then I went through the components themselves. Some weren’t built on the spacing system, some used the wrong text styles, and some didn’t respond to screen size at all. I rebuilt each one so it lined up, stayed clean and worked at every breakpoint.

52 primitives, 75 tokens and 48 text styles, under about 30 pages of components.

The color page: the bright palette of yellows and oranges, then tints of black for text
Color
The typography page: a type scale for desktop, tablet and mobile, with font, weight, size and line height for every style
Type
The buttons page: spacing and anatomy for each button at desktop, tablet and mobile
Buttons
The specs

Every component comes with a spec sheet.

Each sheet answers the four misses before anyone asks, at desktop, tablet and mobile: padding and gaps in pixels, the text style on every line, and every state the component can be in.

Everything a developer needs to build it, in one place.

The Solutions Card spec sheet for desktop: spacing redlines with padding and gap values on the left, and the anatomy on the right, naming the text style, font, weight, size and line height of the title and body
The Solutions Card, desktop spec sheet
QA

In QA, a link instead of a screenshot.

Once the system rolled out, developers built from it. When something was off in QA, I pointed them to the page that covered it instead of writing it up from scratch.

The Solutions Card component breakdown: its properties, then the default and hover states, each with the settings a developer needs
Properties and states, desktop
Outcome

Faster builds, fewer rounds.

With every spec in one place, developers built faster, and there were far fewer rounds of back and forth after QA.

I can’t say for sure how much of it reached the live site. What changed was how the team worked.

Pages from the Brightspeed design system side by side: the Solutions Card spec sheet, typography, spacing, buttons and color

1 hrof my time per QA at most, down from a day or two