Kellie Matheson – Product (UX/UI) Designer
Richard Hallows and I were invited to talk about our work building
the Barnardo's Design System at Design Systems London.
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
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
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
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: