How design systems help designers and developers work together

At Code, we're at our best when we're able to build things quickly and learn things early. Achieving these things wouldn't be possible if we didn't collaborate well together.

Working in product teams (as opposed to discipline-led teams) certainly helps, but there's more to it than just combining our skills and experience.

To work well together, you ideally need a shared system ‚one that puts a stop to any back-and-forth working methods and answers key questions in one place.  

‍

Let's imagine a tennis match...

There's a point to this, we promise. The designer starts with the serve. They hit the ball (their work) to the developer. The developer swings the ball back to the designer with a question. The designer returns the ball back with the amends. Question. Amends. Question. Amends.  

This match continues, until each player becomes increasingly tired (and sweaty) and eventually someone misses the ball. Cue a coffee break. Tennis is fun on a warm summer's day away from the office. In the product world, not so much.  

The Transformers product team at Code recognised how much of a hindrance this way of working was They wanted to develop a more consistent design system to allow them to build more quickly, whilst also revisiting some of their processes.

What is a design system?

A design system can be a combination of different things: traditional brand guidelines, list of components and atoms, accessibility and content guidance and example markup (React, HTML, CSS), to name but a few.  Essentially, it allows you to document how to implement design effectively for your product.  

An effective design system should:

• Provide consistency, with clearly-defined principles and naming conventions
• Take away the guess-work and answer any key questions
• Be fluid and iterated upon continuously
• Not be the only solution‚ what other processes can be improved?
• Be built to benefit not just the team, but the partner

The Transformers product team at Code developed their design system at a time when two large greenfield products were on their agenda: an online gifting experience with a unique proposition and a brand new website and platform for an established car finance dealer. By developing a new design system, they now had their own shared language, consistent codebase and reusable components to be a few steps ahead with any product.

The need for consistency

Consistency is key when it comes to having multiple designers and developers working on a product. If a designer refers to an element as 'Large' but a developer refers to it as 'Categorically Enormous', then this is when things can start to get messy.  

Previously, Transformers were using basic HTML web pages to develop consistencies for their products. Instead of this, they wanted to own and develop their own design system from scratch, meaning that they could iterate upon the system at any time‚without the use of a third party. As part of this system, Transformers developed a set of sensible constraints, in other words, a shared design language‚ to streamline the working processes between developers and designers and ensure consistency in their approach to building.  

For example, they established colour palettes in their design system to avoid the hindrance of pulling hex colours from designs. This also meant that if a colour was found to be inaccessible, then Transformers would only need to change the colour in one place. No regression checking = plenty of saved time.  An approach like this takes away the guesswork‚ for example, if a designer uses a pre-set grid as a framework in a design system, then the developer can build in alignment with this grid.

There's no need to ask questions, as everything's already configured in the design system.