Kellie Matheson – Product (UX/UI) Designer

Minimising complexity

Design Systems London conference



Richard Hallows and I were invited to talk about our work building the Barnardo's Design System at Design Systems London.


Slides

Hi everyone, my name is Kellie and I'm a UX Designer, this is Richard and he's a Front End Developer, and today we're going to talk about Minimising Complexity when building Design Systems.

We’re building a Design System for Barnardo’s, the largest children’s charity in the UK. They provide a wide range of children’s services, including digital services, and they’re in the process of building more.

What’s unique is that children and young people are the users, and they’re involved in the process. We’re also really lucky to have amazing support from the business, and have been able to start from scratch building it from the ground up.

When we first started we attended meet ups and heard this phrase a lot, so we asked ourselves the question how can we bridge the gap between design and development.

Designers and developers often work in siloed teams, and Designers create artefacts for developers to translate. This is an inefficient process which creates false concepts (mobile/tablet/desktop). We decided we weren’t going to use design tools or create design artefacts, and instead we paired and designed in the browser.

We found that a relative language was best when pairing. We then created three rules which use a relative language to design in the browser.

The colour rule is an easy way to extend the colour palette while keeping the code simple.

These rules were created to allow a lot of fleixiblity with in them, so as not to restrict creativity. It's also very simple to represent in code, and allows us to easily have a conversation about colour.

The layout rule uses the proportional unit rem to embrace the web medium.

This rule allows us to easily have a conversation about spacing, without the need to memorise naming conventions.

1rem (roughly 16px) worked as a base for paragraph text, and the rule allowed the creation of an infinite scale.

By converting the formula into rems and creating these 'type slots' we could easily have a conversation about type size, without needing to memorise naming conventions or deal with a finite list breaking.

Using these rules and a shared language allowed us to quickly design in the browser while keeping the code simple.

Even with the rules it's still possible for developers to make mistakes and create inconsistencies, but this can be handled with tooling.

We wrote styleint plugins to enforce the rules.

We also used stylelint to enforce our principles. Our initial configuration allowed nothing, we then added for example 'min-width' enforcing our principle of starting small.

This way of using a linter forced us to reason about every bit of complexity we add, and ask ourselves what is the benefit to the user and is it worth the added complexity.

In order for this to work, designer's need to: