Design at Zego: Planning for scale

Written by Matthew O'Connor

Published on

I've been an avid Sketch user for the past 5 years. It's been my go to tool because of its speed and simplicity, so I was very happy to find out it was the primary design tool at Zego when I joined just over a year ago.

Along with Sketch, we were also using Abstract - a "Git for design" tool - for file versioning, together with InVision for prototyping and getting feedback from stakeholders. This industry standard setup worked as intended, but these separate tools lacked the robustness an end-to-end solution could offer.

As the company entered its 3rd year, we had quite a bit of design debt; messy Sketch files with duplicated, inconsistent, and even unused components. This took a while to get my head around, eventually leading to discussions within the design team about the right tools and processes for a scaling business.

Design as a system

At first, we decided to tackle the design debt in Sketch. We started by auditing all of our current designs to see how we used colour, typography, and other UI elements. This brought to light all of the anti-patterns and inconsistencies which had developed over the years.

With the audit wrapped up, we were left with a collection of artefacts that we used for the foundation of what our UI should look like. From there, we started building out our UI as a Design System.

Put simply, a design system is a set of styles and rules for how to apply brand and UI in digital products. Ours currently consists of reusable styles (e.g. colours, typography), assets (e.g. logos, icons, illustrations) and UI elements (e.g. buttons, text inputs).

The generally-accepted definition of a design system is that it’s the outer circle—it encompasses pattern libraries, style guides, and any other artefacts. But there’s something more. Just because you have a collection of design patterns doesn’t mean you have a design system. A system is a framework. It’s a rulebook. It’s what tells you how those patterns work together. - Jeremy Keith

Utilising a modular approach, tailoring Brad Frost’s atomic design structure to our needs, we got our styles, assets, and components to a place where we were comfortable using them in production.

A workflow for the future

With the first iteration of our Design System making its way into our designs, we decided to look into our workflow and tooling. We already wanted to tackle this task, but the issue became exacerbated with our shiny new design system in place.

Sketch makes use of reusable components, but building and maintaining a large bunch of customisable components was time consuming. They work great for small scale projects, but larger systems become unwieldy quickly. Compounding the problem, we had an issue with Abstract where it sometimes reverted all our component instances to their default state, or unlinked them from their parent component entirely. All of this meant we were spending too much of our time rebuilding our UIs, or rolling back to a previous build.

What scale means to us

As these new issues came to light, we started to discuss what designing at scale meant to us:

  1. Consistency: Using a pragmatic approach to design helps keep our UI consistent as our team scales, while reducing development costs.
  2. Maintainability: Our tools should be built in a maintainable way; things can (and generally will) get out of hand, but keeping maintainability in mind guides decisions when building components.
  3. Communication: Having a shared language for our UI removes ambiguity in our discussions as a design team, and with the wider business. How we communicate design is as influential a tool as the design software itself.

After researching how other people dealt with design systems at scale, looking at the various SaaS tools which promised to solve all of our problems, we found what we were looking for.

One tool to rule them all

We jumped into the free version of Figma and put it to the test, rebuilding a few parts of our design system to see how it worked.

Figma is an online design tool designed for collaboration. Being always online means files are always up to date; multiple designers can work on the same files concurrently and sharing work is as simple as sharing a URL.

In short, our trial went well; their approach to customisable components made for a smaller list of elements to manage and maintain. Since it is a cloud based tool, keeping everything in sync is a breeze, making dev hand-off quicker.

We’ve been using Figma as our main tool for 4 months. All the elements of our design system that we built in Sketch have been ported over and things are progressing well, with our developers starting to implement these new elements in live projects.

The future of design at Zego is far brighter now, bringing order to the chaos of our beginnings. We have our designs, prototypes, reviews, and copy requests all happening in a single - always up to date - design tool. We have a smaller library of reusable components to maintain, and they are always the latest version.

That's how we have planned for scale as designers at Zego.

Drivers & Riders

Private Hire InsuranceScooter InsuranceCar InsuranceVan InsuranceKick Scooter Insurance

Drivers & Riders

United Kingdom
FacebookTwitterInstagram
© Zego 2020
Zego is a trading name of Extracover Limited, which is authorised and regulated by the Financial Conduct Authority.(FRN: 757871).
ExtraCover Limited is registered in England and Wales, No 10128841. Registered address: Unit 3.09, Tea Building, 56 Shoreditch High Street, London, England, E1 6JJ.