Work/Behavox · 2020
Design systems · accessibility

Design System 2.0 in three weeks

One designer, one front-end developer, 112 documented usability issues and a platform that had never had a design practice.

Role

Senior Product Designer · sole designer, from audit to handoff

Team

1 designer · 1 FE developer

Timeline

3 weeks to build · 2 months to ship the pilot

Outcome

Green light to roll the system across the platform

The situation

Behavox had no design practice until the design team was founded in 2020. The visual language had grown as features were added, which is to say it had grown in every direction at once. By the time I arrived the platform carried three problems at the same time:

The gap that started the project: the brand as marketing presented it, and the product as customers actually met it. The gap that started the project: the brand as marketing presented it, and the product as customers actually met it.
The gap that started the project: the brand as marketing presented it, and the product as customers actually met it.

Two months to design and build it, and a team of two: me and one front-end developer. So the plan was to dream big and act small.

Goals

Bringing order first

Before any pixels I wrote a RACI roadmap naming who was responsible, who was accountable, and who needed to be consulted or informed. Once the CPO and the design director signed it, the work had a mandate rather than being one designer's side project.

The RACI roadmap. Naming who was responsible and accountable turned a good intention into a project with a mandate.
The RACI roadmap. Naming who was responsible and accountable turned a good intention into a project with a mandate.

Choosing a pilot. A small pilot lets you make your first mistakes cheaply and win over the people who doubt the whole idea. I scored the candidates against Dan Mall's seven criteria, filled in together with the dev team. The admin interface won clearly.

Scoring the pilot candidates against Dan Mall's seven criteria, filled in together with the dev team so the choice was shared rather than announced.
Scoring the pilot candidates against Dan Mall's seven criteria, filled in together with the dev team so the choice was shared rather than announced.

Process

Colour. The legacy palette had drifted to almost a hundred colours, many of them indistinguishable. I started from the brand, but the original brand purples were far too dark for interface use, so with marketing's blessing I went looking for a digital version of the brand colour. I built shade ramps with ColorBox for the two brand hues, plus a dark grey carrying a hint of blue for neutrals, because pure greys made everything look like a wireframe.

Building the shade ramps. The original brand purples were far too dark to use in an interface, so the first job was finding a digital version of the brand colour.
Building the shade ramps. The original brand purples were far too dark to use in an interface, so the first job was finding a digital version of the brand colour.

Then I checked the ramps for WCAG 2.0 compliance, agreed with marketing on which shade would act as the digital brand colour, and settled on #473493. For the neutrals I used Eight Shapes' Contrast Grid to test every foreground and background combination against minimum contrast, and picked the values for text, borders and disabled states from what passed. Same method again for reds, oranges, greens and blues covering errors, warnings, success, notifications and links.

Every candidate checked against WCAG 2.0 contrast minimums before it earned a place. Left: the purples, and the search for a digital brand colour. Right: the neutrals, tested as fo Every candidate checked against WCAG 2.0 contrast minimums before it earned a place. Left: the purples, and the search for a digital brand colour. Right: the neutrals, tested as fo
Every candidate checked against WCAG 2.0 contrast minimums before it earned a place. Left: the purples, and the search for a digital brand colour. Right: the neutrals, tested as foreground and background pairs.
Agreeing the digital brand colour with marketing. #473493 is the shade that survived both the brand conversation and the contrast testing.
Agreeing the digital brand colour with marketing. #473493 is the shade that survived both the brand conversation and the contrast testing.

Naming, and a lesson learned. My first idea was abstract colour names, "Madrid" rather than "Darkest_Blue", on the theory that abstraction stays flexible. In practice it disconnected the palette from the way I think about colour, which is by hue, and choosing a shade became guesswork.

We switched to two connected palettes instead. A base palette naming colours by hue and shade, blue_700 and so on, where a higher number is darker. And a semantic palette naming them by function, border_default or text_secondary, referencing the base. It matched how designers actually reach for colour and stayed flexible for whatever came next.

The naming logic: a base palette of hues and shades, and a semantic palette that points at it by function.
The naming logic: a base palette of hues and shades, and a semantic palette that points at it by function.
Figma file showing a base colour palette named by hue and shade, and a semantic palette grouped into interaction colours, borders, backgrounds, text and icons.
The two connected palettes. Base colours named by hue and shade on the left, semantic colours named by function on the right, referencing the base.

Typography, elevation and icons. There was no type scale and no elevation system, just a handful of sizes people applied from memory. I built the minimum I knew I would use every day, with naming that left room to grow, and lifted the icons out of the legacy file into their own library.

The foundational libraries: type scale, elevations and icons, each built to the minimum I knew would be used daily, with naming that left room to grow.
The foundational libraries: type scale, elevations and icons, each built to the minimum I knew would be used daily, with naming that left room to grow.

Structuring the component library. Atomic or not? The atomic structure in the legacy library made things genuinely hard to find, because deciding whether something is a molecule or an atom is a debate, not a lookup. I interviewed my teammates and we chose unanimously what most public design systems do: a flat list with one page per interface element. Calendar, filtering panel, modal.

Choosing the library structure with the team rather than for them.
Choosing the library structure with the team rather than for them.

Building it, and redesigning the admin interface. With the foundations in place I screenshotted every admin page and built exactly the components those screens needed. The scope did not allow changing flows, only the visual layer, but even inside that constraint the interface got noticeably cleaner and lighter, and layout problems like sprawling multi-column forms went away.

The admin interface rebuilt on the new foundations, within a scope that allowed changing the visual layer but not the flows.
The admin interface rebuilt on the new foundations, within a scope that allowed changing the visual layer but not the flows.
One screen, before and after. Same flow, same fields, and a great deal easier to read. One screen, before and after. Same flow, same fields, and a great deal easier to read.
One screen, before and after. Same flow, same fields, and a great deal easier to read.

The front-end developer started implementing as soon as the first section was done. We aligned every morning at standup, which is how the trust goal got met without anyone working on it directly.

Results

The reception after the presentation, from the VP of Product Management, the Head of Product Engineering and the CPO.
The reception after the presentation, from the VP of Product Management, the Head of Product Engineering and the CPO.