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.

transformers-4-minv2

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.

transformers-2-min

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.

transformers-3-minv2

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.

“When working with multiple partners and products in a studio environment, there’s always going to be plenty of context switching. With our new design system, this is now much easier; we share a defined set of principals and a unified approach.” — Salma Alam-Naylor, Software Development Lead on Transformers

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.

Having naming conventions and a grid to work to means that it’s easier to build and iterate.
Tweet this

Transformers’ enhanced way of working isn’t just restricted to their design system. They also looked at the whole product process and started inviting front-end developers to things like design sprints and Day Zero workshops.

transformers-5-minv2

The more understanding that different disciplines have of each other and their partners, the better.

The next steps

Transformers’ design system is currently in the alpha-beta stage, but there are plans to pre-package and open-source it for other agencies and product studios to use.

For now, other product teams at Code are adopting the design system and providing feedback in things like discipline meetings.

The most important thing about this design system is that it will never stop growing and being iterated upon. As it’s now gradually becoming an integral part of how we build products — and as the product world is always changing — it will never stay stagnant upon release.

We’ve spoken a lot about how design systems can benefit developers and designers within product teams, but ultimately, it should always be for the partners that you work with. From a partner’s perspective, it makes the process of designing and building products more efficient and minimises changes down the line, which ultimately saves them time and money.

transformers-6-minv2

“It’s not just about how we deliver value for others, but how we deliver value for ourselves.” — Salma Alam-Naylor, Software Development Lead on Transformers


How I influenced positive change in my first six months at Code