Creating the TicketSwap Design System

When I started at TicketSwap one of the first things I championed for the design team was the creation of a design system. The product had grown quickly and organically so lots of small inconsistencies had built up over time.

Sketch was just introducing symbols and libraries at the time, and I was the second designer on the team. So this was an ideal moment to get started. We decided to take an approach loosely based on Atomic design. Koen and me started at the bottom, with the atoms and slowly worked our way up.

Colors

TicketSwap had a few different blue's when we started. We decided to start out with the smallest set possible and try to only add colors as needed. We worked with development to get a list of all colors currently defined in css, and consolidated them into this smaller set.

Then we did the same with typography. This is also the first response part of the system. We defined the weights and sizes for phone, tablet and desktop together.

Next we collected all the different buttons and other controls and mapped them in a grid showing every possible state to make sure we wouldn't miss anything. Our goal here was to use the same sizing on all our target devices to maximize consistency and to ensure that title's would work on different screen sizes and languages.

Components

With the basic building blocks done, I designed a responsive grid and a set of headers and carousels. This way it's easy to build a custom page while making sure things fit and work correctly on different devices.

Putting the system to use

We redesigned the home page to use our shiny new design system.

And here is an example of a city page.

Lessons learned

  1. Great for increasing consistency and usability, especially across platforms
  2. Gradual introduction is nice, but need to press through at some point
  3. Don't let it stilfle innovation

We had a great time working with the development team on gradually introducing this. We agreed to design all new features using the design system, while being flexible on the implementation in the mean time.

We created a tag in our issue tracker for small design related tweaks, our front-end devs really loved having a list of small quick wins to either start or end the day.

We agreed with product management we would spent a fixed amount of time (between 10% and 20% if necessary) on purely design related tasks ensuring we could over time solve all the design debt we accumulated over time.