Toggl Design System

Creating and documenting product design system

Introduction

In this case study I would like to tell the story of how Toggl's design system was created.  Based on my experience of leading this initiative, I will share insights about the process, the tools we use and also how we document and share the system within our team.

Toggl is a global remote SaaS company that provides time tracking services for teams and freelancers to help them boost their productivity. Our product is available on web, mobile, desktop and Apple Watch. Because of the variety of platforms and fast-growing team, the need of the properly set design system seems to be obvious. Main goal is to provide a cohesive experience for our users and facilitate our Team's workflow so that we can make things happen faster.

The starting point

I joined Toggl in 2019. At this time, we had design pattern library for web app in place. Other platforms had their own libraries at various stages of maturity. Basics of all those were created by the design agency that was taking care of the web platform re-design in the previous years. Later on, libraries were developed and updated by Toggl design team.

Because of the lack of time and resources libraries were outdated in many areas. Inconsistencies between platform and design files were another big issue that was slowing design work and, in consequence, delivery.

Screenshot of the initial Sketch file featuring styles and design elements

Design debt

Because of experiment-driven approach to building products and many people contributing to the patterns library over time, design debt became a problem. To work anything new, designers needed to check and update all the resources. It was taking a lot of time and energy that could be used better in actual design work.

One of the important reasons to transform our design libraries to one, updates and consistent design system was to get rid of the design debt and, later on, prevent it.

How to get rid of the design debt?

While working on the design system updates, the best approach is to implement the following sequence of actions:
Inventory -> Audit -> Refactoring
 

The ultimate goal is to have all the style, patterns and components in sync with implementation and ready to be re-used in the design files. It needs to happen in smaller badges to not overwhelm either design or engineering.

How to prevent the design debt in the future?

Inspired with Austin Knight's article, I've decided to propose set these rules:
 

  • The Boy Scout Rule

In Boy Scouts, they have a rule that says “always leave the campground cleaner than you found it.” It should be applied both to design solutions and design files to prevent creating inconsistencies and save time in the future.

  • Clear design vision

When Design Team sees the 'North Star', it is easier to keep high standards, keeping the hight level of autonomy at the same time. Set of rules and best practices for maintaining the design system, together with clear review and submission process, should keep the design debt under control.

Why do we need a design system?

To start moving faster

  • Designing and building modules - reusing is quicker than building from scratch

  • Making app-wide changes - reused patterns will be updated automatically

  • Faster design and, in effect, product launch

The ultimate goal is to minimise the amount of screens created - with good design system in place, there will be no need for showing all the possible states every time, they will be pre-defined for the element​

For consistency at scale

It will be easier to keep an eye on solutions used across all the platforms and provide brand unity.

For better collaboration

Common understanding and good processes in place, will enable easier design and cross-team collaboration.

What needs to be done?

Plan and goals

We've decided to start with the web app, then move on to mobile and desktop.

O: Set up a design system for all the Toggl platforms

  • KR1: Prepare a plan of work by the end of February 

  • KR2: Research available tools and choose the best option by the end of February - compare different solutions, try out chosen tool in one real-life project, prepare the transition and internal communication

  • KR3: Finish V1 of the web app design system by the end of March - colours, typography, icons, buttons, form fields, selection control and popups by the end of March, remaining elements and rules by the end of April

  • KR4: Finish mobile and desktop design systems by the end of May. 

Phases of work

Basics

Knowledge and resources

From many resources out there, I've chosen three that are the most accurate and apply best to our situation and end goal for the design system:

Examples of design systems

Companies like Google, Shopify and Atlassian have very well-documented design systems that I used as both inspiration and guide.

Choosing the right tools

After exploring all the resources and our goals, it became obvious that we need more powerful tools moving forward. At that time, we were using Sketch for design, Abstract for versioning, InVision for basic prototyping and Zeplin for developer handoff. All the styles and components were accessible from Zeplin.

After exploring different possibilities like switching to Figma or using newly released Zeplin  Styleguide, we've decided to move forward with InVision App and DSM (Design System Manager). We've been testing it for a month using enterprise trial accounts to get to know all the strengths and weaknesses of the system. I'm going to list the most important ones.

InVision app:

  • one tool for many activities - collaboration, prototyping, sharing etc.

  • commenting flow is better than Zeplin's, especially notifications and structure

  • InVision Studio for advanced prototyping

  • Better permissions management for all the projects


DSM:

  • easy to use Craft plug-in

  • design system website built automatically and available for the whole team

  • easy to set up advanced structure of the design system

  • versioning of the design system and Storybook integration for Enterprise

Final set of tools:
Sketch + Abstract + InVision App + InVision DSM

Inventory

In order to properly plan the design system structure, I needed to inventory every UI element in our application, compare it with the design files, identify inconsistencies and, at the end, define the most useful structure to implement.

Examples of UI elements inventory pages

Some of the design patterns in Sketch library

Removing inconsistencies

While performing the inventory, I've discovered many inconsistencies and necessary improvements in the app. I've been systematically documenting them and, with the great help of our FE team, we've been removing them step-by-step.

Board with inconsistencies and improvements - work in progress

Audit and structure

Once I've gathered all the elements, I needed to define the structure that would remove some complexity and enable easy navigation. I've came up with the following:

  • Foundation - language, accessibility, voice etc.

  • Design - typography, colors, icons, spacing, illustrations etc.

  • Components with functional structure - for ex. actions, navigation, interface feedback, forms, lists etc.

  • Patterns - inline editing, bulk editing etc.

Define

Styles, components, patterns

For the design system to be useful to both designers and developers, I needed to document and share all the styles, patterns and components. They are accessible from Sketch file and website. For gathering feedback, I used InVision.

Summary

What's next?

Next important steps in setting up Toggl design system is defining the principles, submission criteria for new elements and keeping components up-to-date both on design and development side.

Challenges so far

Two most challenging and time-consuming parts so far were conducting an inventory for all existing components and choosing the right tools.

Inventory - for the design system to be useful, it needs 1-to-1 match between the library and what is actually implemented. Gathering all components and removing inconsistencies required a lot of effort but gave great base for the future work. 

Choosing the tools - this was a big decision as it required a lot of research and forward thinking. Tools needed to correspond with our current needs but also be flexible enough to fir our future plans as design system scales.

Results

Cleaning up and applying new structure to our design system provided a single source of truth for all design components for both design and development. We've managed to reduce inconsistencies and speed up our communication. Over next couple months, we are looking forward to see increased speed of design and development.

alicjasuska.gopher@gmail.com​  |  Tel: +48 502 153 663