When I joined Trainline in early 2017, I was on the Web Booking Flow team. We were in the middle of a replatform from a legacy codebase to a more modern React stack that would allow us to more easily run AB tests, implement wins, add key features, and enable some of the work that was planned for the end of the year. There was no scope for improvements or innovation, the goal was to have a 1:1 port of the existing experience whilst sustaining conversion rates.
At the end of 2017, we started working on the next big thing. We were going to add more than 30 European carriers to our UK product, therefore expanding Trainline's offering to cover all of the UK and EU markets under the same experience. This work required close collaboration between native apps and web, and it lasted until the end of 2018. Again, any visual or UX improvements had to take a back seat for now until we delivered this.
By the end of 2018, we knew we had accumulated significant tech debt in the form of inconsistencies in how we constructed certain flows, how components were created by different teams. Mostly due to the fact that each team had its own library of components in the codebase and did things their own way without necessarily following converging standards.
We wanted to solve that somehow and be more consistent in terms of visual and interaction design; as well as be able to share components across teams without building the same thing multiple times – a big source of frustration for devs up until that point.
At the end of 2018 we were also going through a rebrand, where a new colour palette and refreshed logo were being introduced by the Brand and Comms team and we wanted to make sure the Product side of things reflected the new design language.
Also at this time, now that the long replatform and new integrations were done, we could finally focus on innovation again. We started moving away from teams owning specific channels (web, iOS, Android) and moved to a Mission structure similar to the Spotify model, where each Mission team is responsible for delivering a specific feature.
In this new structure, we'd have different teams working on the same surface areas, across different platforms, devices, using different tech stacks. This could potentially introduce even more inconsistencies in terms of visual design and interactions, which we obviously wanted to avoid.
We knew then that having a design system in place could save a lot of the time devs were spending on recreating the same things over and over, and ensuring a higher level of consistency across our products in this new Mission structure. It could also serve as a vehicle to deliver the rebrand, and set us up for any future rebrands that may come in the future.
Having worked on design systems before at a previous role I knew I wanted to get involved in delivering Trainline's own design system as it posed an exciting challenge for being cross-platform and very wide in scope so I volunteered to run it.
What I did
From its very inception in early 2019, I've been leading the Design Systems workstream at Trainline. I have been the go-to person for design system and tooling related topics ever since. I've been involved at every step of the way, including:
Early decisions on goals, governance and team structure
Setting up a Guild to run it independently
Getting buy in from design, dev, product and execs
Setting up component libraries
Writing usage guides and documentation
Creating specs for build
Raising awareness across the business
Tracking the work and making it visible to the teams
Liaise with Architecture in order to define a build pipeline that would output tokens for multiple platforms (web, iOS, Android)
Providing support, critiques, opportunities for reviews for designers
Key accomplishments 🏅
At the end of this release we had a central repository with platform-agnostic definitions of our most basic primitives like colors, type, spacing, border-radii and shadows. The only limitation was that those definitions could not yet be consumed as a package, but they could be copied into each team's own codebase as an interim solution.
Lots of our products were shipped using those primitives in this distribution model.
This was a successful POC that gave us some small efficiency and consistency gains, not to mention it got people excited enough for us to start having conversations with dev managers and execs to turn this into a full fledged team – more on that on my next post.
I had to overcome a lot of challenges to get to this point. Lack of a dedicated team and resources, my being the only designer, proving value to the business and convincing higher ups, prioritising and tracking the work, amongst other things.
From the outset I defined the goals of the project. We wanted to:
Improve consistency and efficiency
Become the standard for components across all Trainline teams
Be a joy to use for production teams (devs, designers), and users
Be inclusive and accessible
Be able to measure our success
What is a Design System?
There are lots of definitions across the web on what a Design System is, but in my searching I never came across one that I considered the ultimate definition.
I feel like we need to make crystal clear that a design system isn't just components, but an entire ecosystem around it in the form of tooling and documentation as well.
Components should be available as code. If all you have are your components in Figma, that's just a library, not a design system.
So I cherry picked the best ideas, added my own and created this definition as a starting point to get people on the same page as me – and hopefully convince my stakeholders that it was a worthwhile endeavour:
A collection of reusable UI patterns and components – documented and released as code and design tools.
What are we going to call it?
We wanted a name that could act as a nod to the rail industry. After considering other options we decided on Depot.
Depot is just another term for a railway station. It's also a place where trains are housed and maintained and from which they are dispatched for service.
For this reason we thought Depot was a fitting name for the place where all our components would be built, stored, maintained and from which they would be dispatched for service. 😄
How Depot should be structured
As my definition above emphasises, a Design System isn't just components, there should be an entire ecosystem around them to guide and support them, and it doesn't only manifest itself as code components on a web page either. It should also be available in design tooling so that designers and dev are singing from the same hymn sheet.
With that in mind, I created this diagram to illustrate how I thought we should be approaching Design Systems at Trainline to help get everyone in the same frame of mind:
In short, a design system receives input from our design principles, content guidelines and accessibility best practices to create canonical definitions of our basic UI foundations and components.
Those definitions are then documented, used to create design tooling and are then implemented as code that is in turn consumed by our front ends to render our applications.
Obviously it seems simple on the surface, but keep in mind that each one of these parts are nuanced and super difficult to get right, as there are tons of small decisions to be made and pros and cons to every approach.
I also created a simple value proposition statement that we could use to remind ourselves of what we were aiming for throughout the process:
Vastly improve the effectiveness of designers and developers by providing them with a design system that allows them to focus more on discovery and less on delivery.
Inspiration & leveraging the design community
I've always been inspired by the design systems from larger companies like AirBnb, Spotify, Salesforce, Shopify, the list goes on... so I obviously took some inspiration from those to help guide my work with Depot.
In addition to that, I leveraged some contacts at [Hotels.com](http://hotels.com) to give me a run down of how they were tackling the development of their own design system – much more mature than Depot at the time.
My then Head of Design also helped us arrange similar sessions with [Bulb](https://design.bulb.co.uk/#/patterns/styles/colors/README.md) and [Deliveroo](https://www.deliveroo.design/) and overall it was great to get insights and learn about some of the potential pitfalls early on, before I even started doing any hands-on work. This is something I really recommend doing when starting a similar project.
One of the first things I did was to run an audit of the current state of the components we were using across our web and native products, to get a sense of how inconsistent they were and also gauge what types and how many components we'd initially need in order to "rebuild" things with a common approach.
I asked designers across our various teams to help out by screenshotting each of their component into a common shared file.
Below is a screenshot of the `Buttons` audit as a taste of the results. `Buttons` seem simple on the surface, but they can have a big impact on efficiency due to how often they are used and the amount of variants they tend to have. As you can see we were quite inconsistent in their usage.
I ran audits for all kinds of components and primitives like type, spacing, colours as well.
The audit helped inform a standardised approach that could potentially work for all platforms, so I began exploring what the ideal type scale, spacing scale, colour palettes would look like. Assuming those would be suitable to be applied to our existing products as well as create future ones.
I also worked with the Brand team to bring in our new colours into a Product palette with a focus on accessibility and flexibility.
As an exercise to test out my own new set of foundations I explored what the vision of a unified experience could look like. This was very high level thinking and not too bogged down by the details. At this stage I just wanted to get a sense of what the future of our interfaces could look like even though I knew the first few steps would be to implement those new foundations into our existing front ends without too many major UX changes.
Forming a team
I'll be candid and say that up until this point I was the only person working on this project and trying to get it off the ground. As such, there was *zero* support from other areas or engineering resource to help develop it.
I was however dedicated to it with 100% of my time and proposed we try to run it as a Guild.
The concept of Guilds was made popular by Spotify and you can read more about it [here](https://medium.com/webcom-engineering-and-product/agile-guilds-the-yodle-way-47dc00f6cd3a), but as a quick summary a Guild is comprised of members of different teams that come together under a common interest.
At Trainline, we had Performance and Quality Guilds, and it made sense to try and find developers with an interest and perhaps experience in building design system to form a Design System Guild cutting across various Missions and Channel teams.
I asked around, posted messages on engineering Slack channels and soon enough had a large list of interested devs. I put together a deck and booked our first session to present my ideas and start discussing it.
Skipping forward a bit, once we had an idea of what a build pipeline would be for a cross platform design system – Architects helped out massively in defining this – I then worked with the Guild to create our first repo to hold all of our primitives, and began adding them.
The early version of our theming system started taking shape on there as well.
This repo was then made available to all teams and it functioned as a great way to see the progress being made in the form of releases.
All primitive declarations in this repo were platform-agnostic – most were just JSON structures – so that platforms could grab those values and use them to calculate the equivalent in their preferred units.
Sketch library & documentation
I published the components as Sketch libraries available to the Product Design team – we were still using Sketch at the time. This ensured a nice closed cycle where devs and designers had the same set of elements to work with.
The only missing piece was documentation. For this, I created a Zeplin project for Depot where I wrote simple documentation pages describing usage, states and other relevant information for each component so that people could make quick decisions when working with the system. I also made use of Zeplin's shared library feature to ensure that different platforms using the same component would link to the same source of truth.
I set up open hours that designers could book to talk though early designs and get my steer on using the system. This was also an opportunity to identify and fill in any gaps in terms of missing components, missing states and such.
We also used our weekly design sessions to review and critique work. At this point I'd act as the "Depot police" and ensure we were using the system as intended. I'd also use those to announce new things we had shipped under Depot.
Depot in action
I'm skipping ahead a little bit here for the sake of storytelling, but after a few months and a sprints we started seeing Depot coming through to our front ends and in the hands of users.
The entire premise during this initial phase was to try and get Product Designers in Missions to adopt Depot components in new features they were shipping, bundling the work required to implement them as part of their stories.
This wasn't perfect obviously, but we ended up including bits of Depot here and there in various projects and soon enough people were seeing the value in a centrally distributed design system via time savings and better overall consistency across platforms.
We were nowhere near the end goal. But we could now try and push for a more structured approach in running this team since people started seeing the value in it, and we had something tangible to measure against.
We also noticed we were pushing the limits of our design tooling at the time. We wanted to implement a theming system and have proper token support which Sketch didn't provide back then. Distributing the library via Sketch was clunky and Sketch's override system were grinding our gears a bit as being a bit too inflexible.
The overhead of maintaining Zeplin specs were also becoming a bottleneck we wanted to address. And doing documentation on there was always a stop gap solution, we needed a better platform.
Another issue is that I was *myself* becoming a bottleneck. Being the "living knowledge base" for Depot just wasn't scalable. People had to come to me with questions because our documentation wasn't comprehensive enough and the open hours I set up started having low attendance. So I needed a better plan moving forward.
I'll talk about how I addressed all of the points above on my next project [Depot 1.0](https://www.notion.so/7e64c19fa03a419a95e01304c0ec2728) which coincided with the COVID-19 pandemic and the entire team going remote for over a year.