Creating an accessible design system

Introduction

My role during this project was IC Product Designer working with Engineering to establish our design system at Sidekicker.

When I joined Sidekicker, I inherited a product that was a mess of inaccessible and inconsistent styles, components and patterns. Not through anyone’s fault. It was just the nature of a product that had only recently found its market fit. I saw a clear opportunity for developing a design system, the business just needed convincing.

Problem

At the start of COVID, Sidekicker signed an agreement with the Victorian Government to deliver the Jobs Victoria marketplace, a place for people who had lost their jobs to find employment. At its peak we had 20,000+ Victorian’s signed up searching for jobs.

A key requirement from the Victorian Government was that the marketplace follow WCAG AA guidelines. Given our existing platform was completely inaccessible, the opportunity to develop our design system had arrived!

‍

The original Sketch library that I inherited when I joined Sidekicker.

‍

Success metrics

Our design system would need to satisfy the following criteria:

• AA accessible (must have)
• Simple and functional (we didn’t have room for anything more, given the shear volume of what was needed)
• Responsive
• Highly reusable
• Designer and developer friendly

I also saw it as a means to resolve some of the existing design debt, like our lack of an 8pt grid, our weird and wonderful colour palette and typography, and of course a platform filled with one-off, inconsistent and disconnected components.

Process

Discovery

Given the magnitude of what we were undertaking and our limited resources we didn't undertake any generative research or user testing. I’d never created a design system from the ground up, but the great thing about design systems is that there are hundreds of examples to browse!

‍

Some of the designs systems I used for inspiration.

‍

Design & delivery

I worked closely with engineering to understand not only the best form for different components to take, but also how best to implement them in a lean and reusable way. It helped considerably that I had experience building my own React apps, so I had a solid understanding of how the components would be put together. We took a progressive approach, building out components as needed. We included only the essential functionality to fit the use case, plus future use cases we had a high level of confidence would be needed in the not too distant future.

One of the biggest areas of learning came from ensuring the design system met the WCAG AA requirements. I again worked closely with engineering to understand these requirements, implement solutions and then QA what was built. I learned a lot about designing an experience that could be used by all users.

A few of the things I learned:

1. Simple visual accessibility guidelines like contrast, font size, being careful when using colour to communicate meaning, etc. are simple things that all designers should follow - no excuses!
2. Keyboard navigation quickly gets complicated when you come across components with multiple states like a Select or Modal. You need to ensure navigation between the different states aligns with what is expected by a keyboard user.
3. Screen readers will quickly tell you when something doesn't make sense (e.g. incorrect heading usage, missing content or alt tags, confusing tab order)
4. Plus much, much more...

‍

Keyboard navigation of the select component was an example of some of the complexity we had to navigate.

‍

Documentation of the design system was done in Figma and used as both guidelines for usage as well as to document the production designs.

And finally, there was the important task of naming our design system. I dug into the database and found the first job that was ever completed by a worker, who went by the name “Mari”.

Result

Check out our production version of Mari on Storybook: https://mari.sidekicker.design/

‍

In terms of the original goals we set out with, the results have been clear:

1. The primary requirement of AA-accessibility was satisfied.
2. Our product and engineering teams well and truly adopted Mari as the new standard. For instance, there are guaranteed questions from engineering if a designer proposes anything that falls outside of Mari.
3. Design and Engineering efficiency has increased considerably due to a reduced need to make low-level decisions, a significant reduction in custom components, and a reduction in QA time.
4. The quality of the product has similarly increased for many of the same reasons.

Following on from this project, I established a distributed design system team to provide ongoing governance and continue to improve it. We haven’t reach the scale we need as a business to warrant major ongoing investment in it or a dedicated design systems team, but we still take any opportunity we get to continue to improve it.

Lesson

A design system can be what you make it. Even the smallest start-up will benefit from thinking in design system terms. You don’t need a major upfront investment, or a centralised design systems team - you can just start with a button. We took a lean, progressive approach and managed to build out a strong foundational design system in a relatively short amount of time.

‍

_{Hero image by Mourizal Zativa on Unsplash}