Tag Archives: UI

Trainline – Depot Design System v0.1.0

About the project

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
  • Defining processes
  • 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.

Objectives

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.

Value proposition

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.

Component audit

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.

New foundations

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.

Colours

I also worked with the Brand team to bring in our new colours into a Product palette with a focus on accessibility and flexibility.

Dogfooding

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.

The repo

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.

Design support

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.

Next steps

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.

Adstream – UI Pattern Library

About the project

This was an effort to lay a foundation for all of Adstream’s future products, facilitate the work of both design and development teams, reducing the time it takes to create and deploy new features or modify existing ones by creating a UI pattern library that is part of a solid design system that unifies all of Adstream's products under the same visual identity.

What I did

I worked closely with the senior interaction designer and a team of developers to create a comprehensive design system from the ground up that worked across all devices and platforms. Doing research, creating the structure of our design system, visual designs, running tests, creating interaction prototypes, all sorts of UI/UX explorations, specifications, documentation and overseeing the final implementation. As the design system is an ongoing effort, I am also responsible for considering potential updates to it, new additions in terms of components, and making sure we are using our components correctly and consistently as our platform evolves.

Key accomplishment 🏅

The implementation of a well-structured design system has freed up an estimated 220 hours man hours per employee per month across both design and development teams which can now be allocated to other tasks.
An overview of how I documented our components. You can view the complete specs here in Zeplin.

Objective

The current version of the Adstream suite of products (v5) was built circa 2011-2013 and its parts were designed and developed by many different teams — some internal, some outsourced. As a result of that, both the user interface and common interaction patterns differed greatly across Adstream’s range of digital products. When we first started discussing v6 of the platform, we knew that was the perfect time to devise a solution that made it possible for anyone, anywhere to create experiences that felt part of the same ecosystem, while making it easier for whoever is creating it to do the right thing, regardless of them being a designer or a developer.
Design for spread and scale.
Denise Gershbein, Creative Director at frog
It was clear that we needed to put a stronger focus on our UI Pattern Library and this should be more than just a cosmetic endeavour. It should be a comprehensive design system and flexible enough to adapt to the ever-changing needs of this industry and our business.

Research

Components

I started out by looking at each of Adstream’s products and discerning common patterns and components. From the most basic such as labels, icons, buttons, checkboxes, radio buttons, dropdowns, accordions; to more complex combinations such as panels, user tables, different types of modals, and so on.
Some of my early sketches.
Having this granular approach allowed me to see the pattern library as a modular set of blocks we could put together to form larger and more complex structures. I didn’t go full on Atomic Design on this project but I did keep some of these principles in mind when categorising elements which definitely helped speed up the process and tie everything together nicely.

Deciding on a framework

The next step was to work with the development team and see what was readily available on the framework they were using to build the new version of the platform. Luckily they were using Angular Material which comes pre-packed with lots of useful components we could work with without much hassle. Some components would require a small amount of customisation, but for the most part, Angular Material provided a very solid starting point for what we wanted to achieve.

Grid

We chose to use a 1280px max-width grid system with 12 columns and 32px gutters as that provided greater flexibility for the most common scenarios in our platform. It’s important to keep in mind that this should never hinder us from pursuing other layouts if we believe those would be more usable. Having a grid system shouldn’t be a constraint. It should serve as a foundation on top of which you can build your product, but concessions must be made here and there.
To say a grid is limiting is to say that language is limiting, or typography is limiting.
Ellen Lupton, Curator of contemporary design at Cooper-Hewitt National Design Museum • NYC
As an example, on the Adstream Library, we have a fixed side panel of 320px on the left and that’s always there regardless of what device you are on. However, the main view to the right of this panel contains thumbnails of your assets, within that view we apply our 1280px grid, but in this particular case, the 320px panel is excluded from the grid. This allows our users to use their full screen real estate to preview their assets in the Library, which we validated as a better solution than constraining them to 1280px at all times for this particular case.
Screengrab shamelessly taken directly from Zeplin.

Typography

Typography and semantics are very important aspects of what makes a web application accessible to users who rely on-screen readers. For this reason, our approach to typography was to not use elements such as h1, h2, h3 to determine style. These elements are used for content hierarchy, making it easier for screen readers to consume the content and their style is limited to a specific font-size set in rem for which the base size is 16px. Styles such as font-weight, color, are all applied as modifier classes such as .font-weight-light, .font-weight-medium, .font-weight-bold, etc.
Effra is the typeface we used.

Iconography

We used an icon set that is based on a 32px grid size and 2px lines. The idea is to refine and redesign them as our product and brand evolves.

Colours

Colour is a key aspect of any interface and our approach to colour is to use it just enough to hint the user in terms of statuses, intents and visual cues that will make for an easier journey through their daily workflows. We do have a large set of colours to pick from, but the aim is to stick to as few as possible while thinking of the journey as steps. Never having more than one accent colour per step.

Primary

These are used for important actions and are bright and bold.

Secondary

These are used to support primary colours when necessary. They are slightly less saturated and lighter versions of our Primary palette.

Shades of grey

We would in some parts of the platform, have a need for a dark version of our UI. I kept this in mind when defining this palette. This is why we’ve got plenty of shades of grey to pick from, but essentially every colour on the shades of grey palette has an equivalent counterpart that provides enough contrast against a dark background and this principle applies to every component.
You can literally drop a .dark-ui modifier class to an entire section and have all its children adjust accordingly.
Hang on, here comes the best part… there you go!

Visual design

After deciding on solid grid and type systems and defining the colour palette, I then started designing each component with their different states in a manner that brought the entire library together and gave a sense of unity to the user.
Instead of prescribing the appearance of individual items, we build systems to anticipate them.
Heydon Pickering, Author of ‘Apps For All: Coding Accessible Web Applications’
At this stage, I ran lots of tests in HTML, CSS to see what was reasonable and these tests combined eventually went on to become a framework of its own that I ended up using to develop future high-fidelity prototypes for other areas of the platform when required. During the development of these tests, I used a BEM approach in terms of naming conventions for states and modified versions of components. Having a background in front end development gave me great insight into how I could make it easier for developers to implement this pattern library as well as how we could make it extremely flexible, scalable and somewhat future-proof – at least for a while. 😉 Semantics have always been very important in the realm of web development, especially when dealing with large enterprise level software. I’ve kept this in mind when developing these components, what this means is that wherever possible, elements use their correct HTML tags when available. This applies to button, input, nav, detail, ul, ol, li, table, and so on.
Adstream Wayfinder Pattern Library – Framework Prototype Preview it here. Made with: HTML, CSS, JS & jQuery

Interactions & micro-interactions

Below are some examples of the way we envisioned the micro-interactions on some of our components.

Internal resources

Sketch symbols library

Considering we in the design team at Adstream spend a lot of our time in Sketch, I’ve created a symbol library with all of our components that has really helped speed up our process when creating comps or even final designs. I’ve also revised it since the introduction of responsive symbols in Sketch 4.0 and have now made most of these components easy to adjust to whatever screen size we are designing for. The file also contains all of our text styles and color pallettes so that our designs are always consistent and we don’t need to ‘reinvent the wheel’ at each new project.
My Sketch symbols library with all of the Adstream UI components.

The framework

I also like to exemplify things with code when necessary. This really helps ground my work and convey my ideas in a more direct kind of way to our devs since HTML and CSS is ultimately the media these components will be based on. While some great looking things can be accomplished in the prototyping tools available these days, some ideas simply don’t translate well to real life scenarios. Here are some of the components I exemplified with code: Adstream UI Library – Tabs Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Tooltips Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Toasts Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Radio buttons Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Comments Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Menus Preview it here. Made with: Angular Material framework — HTML, CSS & JS Adstream UI Library – Modals Preview it here. Made with: HTML, CSS & JS Using HTML, CSS and JS allows me to run quick experiments and tweak the details that will bring delight to our users like transitions, animations, easing curves and how responsive each component feels. It started as a set of quick experiments but after a while I had gathered enough to compile our own framework of components. We currently use this framework in specific cases where we need high-fidelity prototypes.

Specs & production

A design system is only as good as its documentation, so we have been documenting all the components with Zeplin and working closely with the developers in bringing them to life one by one. The new modules of the Adstream Platform (Library, Costs, and soon Delivery and Tasks) have already been designed with those new components and we are now in the process of rolling them out to our first users.

Conclusion

Having a pattern library in place has drastically improved our productivity. We are now able to spend more time prototyping, implementing, testing and iterating on ideas, instead of thinking about mundane things like how buttons or inputs should look or work. It lets us think of the bigger picture and be more… agile — there, I said it. 😬 It’s also great in the sense that we no longer get attached to our design decisions since they’ve essentially already been made for us, this allows us to ruthlessly scrap ideas that aren’t working and come up with new ones.
We need to stop worrying about proving the value of design and just focus on outcomes that provide value.
Denis Weil, Innovation Executive • formerly at McDonald’s
That said, a pattern library is an ongoing process. It should never really be finished. Components can now safely be improved upon and tweaked since they are their own modular entities and this allows us to revisit them often and make adjustments that won’t require an entire restructure of our platform or a massive version release.

References

When developing the Wayfinder pattern library I’ve used several online resources with the best ideas I could find to make the best possible solution. I’ll link to them below and hope you may find them useful:

Resources

Inspiration from other pattern libraries