Building a Design System for Liverpool FC


4 Months


Liverpool FC (through IBM iX)


End to end ownership. Helping build and define the components alongside the visual designer, through to implementation into the final React code, working with local and offshore developers. I worked with various teams and stakeholders internally, and had regular playback sessions to present and advocate for design decisions to our clients.


IBM iX had been working with this client already to reinvent their digital presence, producing responsive interfaces for the website as well as a new mobile app. The project was scaling up, making it difficult to manage versions, keep interface elements consistent, and maintain and adjust existing designs with new requirements.

Font Variations


Screen Designs

How Can I Help?

Some work was already being done to try and rectify some of the issues by creating symbolised Sketch libraries. This was not a perfect solution however, so I was asked to come up with a more bespoke, holistic solution that looked at the end-to-end context of the system to design something that worked perfectly for everyone.

Problem Identified: Poor File Management

Several designers and developers across multiple teams all need access to the design files, and without a centralised location, retrieval was arduous. This led to devs storing poorly named, outdated local exports of files for as long as possible, which led to inconsistent design implementation.

The design team were transitioning into more heavily using Plant as a version control system for their design files, and this did have potential. However, this wasn't a perfect solution either due to reliability issues and constant updates, which often led to issues caused by different people having different versions of Sketch, sometimes disallowing file access until version compatibility was found.

Problem Identified: Lack of Component Consistency

This problem came more into light as the team grew. The designs were initially all being made by a single visual designer, and when more designers were added, new components and style variations were being designed that had already been designed a different way, resulting in multiple inconsistently styled components that were functionally identical.

Problem Identified: Difficult Dev Handoff

The current workflow also made handing designs off to developers a lot harder. I found that this was caused by three main things., and also the lack of easy naviga

  • Lack of good documentation led to confusion about implementation, especially with responsive designs. To get correct implementation, a designer had to meet with a developer for each piece of design work and explain the intended behaviour for each one
  • Lack of a maintained repository of design work massively increased the number of emails and slack messages containing file requests.
  • Lack of efficiency in general. There was a lot of small opportunities to improve general workflow or efficiency that are too small to individually list but overall make a bit impact.

A User Centred Design System

I started by identifying the main future users of the design system and synthesising stories and user needs based on observations and conversations with the team. This helped us envision what an ideal design system for this project might have.

User Needs: The Design Team

User Needs: The Developer Team

User Needs: The Business Team

A Smooth New Workflow

Through several conversations with stakeholders across design, development, and business, I synthesised and proposed a workflow through which design work travels from initial requirement to final development.

We considered integrating the design system earlier in the cycle and housing UX wireframes into it to establish decisions even before the visual stage, but when this was tested, we found that the designs felt too "finalised" when housed in the system, which led to confusion in the client team. It also would have removed some of the agility that was in the current UX ideation workflow, making experimentation harder.

Making it Atomic

The structure for the design system was required to be modular and scalable, so Brad Frost's Atomic Design principles were chosen as a base, with tweaking it to suit the project context.

Atoms Elements

The primary building blocks of the system, and closest to "Atoms" in Atomic Design. Elements are the smallest possible implementations of visual design, and include things like buttons, text, borders, icons, etc. These have nothing nested within them but can have variations and states, and are combined together to form more complex building blocks.

Molecules Components

Components are the next step up from elements, and are closest to "Molecules" from Atomic Design. They are made up of elements and represent isolated containers of functionality. This could include simple and more complex functions as long as the function is generic enough to be used multiple times in the design in different contexts. Examples include date pickers, product cards, and sub navigation menus.

Organisms Modules

Modules are top level building blocks, and are closest to "Organisms" in Atomic Design. These combine elements and components to provide bespoke functionality for a specific purpose. They are not to be nested within any other container. These include things like the navigation bar, a carousel, or a notification marquee.

The Prototype

The first iteration was designed in sketch and used Invision as a platform to host, as this was what was expected by LFC. This was primarily a prototype iteration, and was the first "complete" project deliverable I presented to the client.

Inefficient Invision Interactions

I built interactivity by using Invision and linking together the pages. This was HIGHLY inefficient due to the abundance of text style variations meaning I had to create and link pages for fonts, with links to any combination of base font + bold/regular + 4 colour options + 4 Size options for a total of over 1000 variations over 32 pages each linking out to 9 unique pages. (Demo available on request)

Invision was deemed unviable for the final release.

Information Architecture

The structure of the first iteration of the system was as follows, and was designed with some initial inspiration from existing systems such as IBM's carbon and Google's Material Design. This was to maintain familiarity in structure and therefore work with the user's existing mental models.

Production Platform Requirements

In addition to the user requirements mentioned above, I also took into account other factors when exploring and evaluating possible platforms. For example:

Picking a Platform

All of the solutions I pieced together had trade-offs, and these were explored and evaluated. Some of these were cut for not meeting user requirements, some for implementation time or handoff time, and some were cut due to risk of lack of support. Here are a few of them:

Proposed Solution

After several iterations, the chosen solution involved connecting together Sketch, Invision DSM, Plant, and Zeplin, and using each for its unique advantages.




Solution Highlights

Here are some things I liked about the solution we ended up implementing:

Responsive Components using Anima

To make life easier for designing for multiple viewports, I rebuilt a lot of the components using a css box model structure and with responsiveness using Anima.

Storybook Integration

The Storybook implementation was incredibly helpful for both the designers and the developers, as it allowed the devs to use the tool to maintain their modular codebase, and the designers could look at a live version to evaluate and request changes/updates to.

Personal Highlights

In addition to the solution highlights above, there were a few specific personal highlights that I felt were examples of creative problem solving or general skill-set that felt personally satisfying.

Developing a Zeplin Extension

One of the fonts used was a modified font made in Sketch (a stroke was added and fill removed to make an outline variant of the base font), rather than an actual typeface. This caused issues in Zeplin that would only extract the css as far as the name of the typeface and the fill. This led to invisible fonts being exported and used by developers, causing confusion.

When I noticed this, I proposed that I build a custom outline version of the font. This was considered but deemed overkill for the situation. Instead, I discovered that Zeplin has an extensions feature, so I built an extension that extracted further css from the sketch file, allowing the developers to continue simply using the code that Zeplin provides.

Leadership and Project Ownership

Having large responsibility on a major client project proved to be a fantastic way to make myself more comfortable working with fewer safety nets. Extra responsibility also came when I later had to manage and direct a couple of other interns that were brought on to help me with the system as it scaled further.


I believe the project went very well, and I was able to achieve most of what I set out to do. However, there were a few inefficiencies that I learned from.

Time Sinks

There were a few times where I was doing tasks that turned out to be disproportionately effortful for the value they added, such as using Sketch and Invision for the first iteration of the system. This taught me to better evaluate the tools and platforms I use for the context before defaulting to what I'm used to doing.

Growth / Learning Moments

Improved Communication Skills

The daily client meetings, and playback sessions improved my ability to communicate not only my own but also other people's design work, and the responsibilities of later directing other people to some extent was a rush and a challenge that helped me improve the way I articulate thoughts.

Deep Diving into Design Systems

I had the opportunity to really dive deep into learning all about design systems. This sparked an interest that I didn't know I had, and is something that I'd be really interested in tackling in a novel way.