Magic happens when designers and developers work closely together

Kellie Green (née Matheson)
Barnardo's Innovation Lab
3 min readMay 14, 2019

--

Pic: Me and Richard presenting at Design Systems London

Richard and I were invited to talk at Design Systems London, an annual conference that brings together over 200 designers and engineers to share experiences, ideas, and approaches on how to design, build and maintain design systems, organised by YLD.

We were humbled to be amongst speakers from large organisations such as Deliveroo, Microsoft and Gov, and talked about the importance of minimising code complexity when building design systems.

Typically, designers create mockups using fixed sizes which developers translate into code using fluid sizes that change dimensions depending on the size of the browser window. Additionally, as designers and developers often work in separate teams and speak different languages, developers sometimes end up having to write unnecessary code to satisfy a designer’s vision.

If digital products such as design systems have complex code it becomes more unwieldy for existing and new developers to maintain and add to in the future. This can mean either a lot of time spent on changes, or the product being abandoned and rebuilt from scratch. Both of these problems are expensive, inefficient, and avoidable.

When Richard and I started working on the Barnardo’s Design System, we decided to remove this cumbersome translation process by developing a shared relative language that allowed us to design directly in the browser.

We used this shared language to create rules for colour, typography and layout. Having these rules in place meant instead of talking in terms of fixed colour values, fonts sizes or pixel sizes, we could simply say: ‘Let’s make that colour lighter’ or ‘Let’s make that text smaller’. Using these rules and a shared language allowed us to develop the design system quickly while keeping the code simple.

Video: Me and Richard giving a talk on Minimising Complexity. The transcript is available on my website.

Previous projects I’ve worked on have involved regular long team meetings and a lot of time wasted to ensure everyone is kept up to date. The sluggish pace can make it difficult to maintain enthusiasm about what you’re creating and it can drain resources. So, as well as rules for colour, typography, and layout, we also developed some strategies to avoid inertia, ensure efficiency and keep up the momentum. Here are some of these strategies:

  • Working closely on a daily basis for the length of the project.
    This helped me understand the amount of complexity involved in some of my design decisions and allowed us to have regular conversations to agree on what was best for the user and for the code.
  • Having the right attitude.
    Working closely and seeing the code allowed me to realise how important minimising code complexity is to a project’s success and longevity.
  • Writing future-proof code.
    Our code is written in (modern) standard CSS and JavaScript, and we use tools to convert the code into backwards compatible versions. This means we can achieve a lot in just a single line of code that in the past would have been several lines.
  • Not rushing into it.
    We spent the first two weeks cultivating our shared language and deciding on the rules. Taking the time to get this right before building components meant we didn’t have to waste any time rebuilding components later.

Largely because of the way we worked, creating the Barnardo’s Design System has been the most enjoyable project I’ve ever worked on. I’ve personally found it to be frictionless, and incredibly efficient.

Once problems are solved in the Design System, they don’t need to be solved again.

It’s been good for our Barnardo’s colleagues, too. Once problems are solved in the Design System, they don’t need to be solved again. If five of our teams are building products which contain a pattern that is provided in the Design System, that saves a lot of time. By avoiding inefficient processes, our colleagues can focus their resources on public-facing services and on delivering better outcomes for more children.

Kellie is a UX Designer and Richard was a UX Developer in the Barnardo’s digital team. To find out more about the work Barnardo’s are doing, subscribe to blog.barnar.do on Medium, and follow #FutureBarnardos on Twitter.

We’re hiring! Read more about the team we’re building and our current roles available.

--

--