How Did I Simplify and Scale the Sky Sports Design System?

OVERVIEW

Sky Sports is one of the biggest sports platforms in the UK, with millions of users. Their app covers major sports with live scores, news, and highlights and is available in multiple countries and languages.

I was the lead designer on the design system side for Sky Sports. The platforms in this case study were iOS and Android, with web planned for the future as part of a redesign. The team had already made an attempt, and developers were trying to adopt it, but they lacked the resources to keep it going. My goal was to create a smooth experience for everyone—designers, developers, stakeholders, and UX teams—so they could work more efficiently and collaborate better.

EXPLORATION PHASE

Designing for a large team with different needs is a challenge, but having teammates eager to collaborate made the journey easier. I started by exploring existing files, auditing the app’s flow to understand how colours, typography, and UI components were being used, and speaking with the team to uncover pain points. This research helped me set the direction for the project, identifying key areas to dive deeper into and solve the biggest challenges.

Through this, I uncovered some key problems on the foundation:

• The colour palette wasn't scalable - shades jumped inconsistently, a massive list of colours was in use.
• Old libraries remained published, adding inconsistency in colours and typography.
• Rigid components were designed separately for mobile and tablet instead of being responsive.
• Naming conventions were unclear, making it difficult for designers and developers to find and use the right tokens.

This phase was all about understanding the problem, gathering insights, and defining opportunities—the foundation for a scalable and efficient design system.

Workshop & Affinity Diagramming

While some needs were clear from the start, this session helped surface additional pain points and priorities, such as:

• Information was all over the place, forcing developers to hover around files to found what they needed.
• Documentation was created by the features team on Figma, but they didn't have capacity to keep it up to date. It also focused on features rather than components.
• Code and design misaligned.
• Communication between developers and designers was a pain point.
• Developers felt the design system was built mainly for designers, with little attention to their needs.
• A lack of transparency in the design system process left teams unsure of updates and decisions.

Some key quotes from the workshop:

Developers struggle to see dark mode themes.

Lots of guesswork in the builds rather than using the DS.

It can be hard to know when designs are updated and how when looking at Figma.

Introducing a new design system just means we have two design systems. We need a plan on how to move code over.

And the list goes on...

This session validated existing problems and revealed new ones, helping us define a clear roadmap for making the design system truly valuable for everyone.

‍

SOLUTION PHASE

After researching and auditing the challenges, I implemented key actions to establish a strong foundation. The first actions were:

• Consolidated light and dark mode components and styles into a unified themed system, reducing the total components from 1,000 to 161.
• Rebuilt components to be more lean and easy to use.
• Created a scalable colour palette that covers all use cases, it also helped us to reduce opacity that was overused on dark mode.
• Streamlined the typography stack, reducing from 27 to 13 typography ramp, making the system easier to use.
• Developed a name convention for typography base on t-shirt sizes to make it simple to scale. This approach would be adopted by the Global Design team later on.

This phase focused on turning insights into action—building a scalable, maintainable, and developer-friendly design system that supports the entire team. Since colour and typography emerged as major problem areas during the discovery phase, I tackled them in two dedicated case studies. Additionally, I addressed the challenges uncovered in the workshop, which I’ll explore next.
‍

ADDRESSING THE WORKSHOP CHALLENGES

Beyond the foundation, we identified deeper issues like communication gaps, lack of transparency, and unclear processes. Some were quick wins, while others required long-term collaboration. Here's how we approached them:
‍

How might we make it easier for developers and designers to engage with the design system?

Bringing Developers into the Conversation
‍One of the biggest complaints was the lack of a design system for developers—they didn’t know who to reach out to, whether UI designers or the DS team. To fix this, we added developers to the Slack channel creating a space where they could ask questions without needing to know exactly who to contact - anyone involved in the product could step in to help.

Bi-Weekly Syncs
UX designers, UI designers, PMs, developers, leads, and heads of products (both DS and Sports) could come together. This was a space to share ongoing projects, ask for feedback, or solve any doubts. I personally used this space a lot to get feedback on my work in Zero Height, learning from them on the early stage of the project was really helpful.
‍

How might we improve transparency and keep teams in the loop?

Sprint-Based Updates
Lack of transparency was an issue that came up with the workshop. So at the end of every sprint, I shared what had been completed, what was in progress, and what was coming next allowing teams to flag urgent needs, ensuring the DS was helping them move faster, not slowing them down.

Detailed Library Updates
Whenever a component update was made, I shared detailed breakdowns of what changed, which other components might be affected, and what developers should expect. This ensured alignment between design and development, reducing confusion.

New Ways of Working

Handover, who owns what, what stage to reach out to design system were some things we needed to work on and have a more clear process. Some files we used to have:

• Component Proposal - where UI designers requested new components, component updates or icons.
• Shaping - a collaboration file between UI designers and developers.
• Documentation - a Figma file where UI designers documented product flows, but not components.
• Full Product Flow (light and Dark mode) - a file where the whole flow was living, being updated by the design system team.
• Documentation - a Figma file where UI designers documented product flows, but not components.
• Full Product Flow (light and Dark mode) - a file where the whole flow was living, being updated by the design system team.
• Components and Templates - a sticker sheet — a home for instances of components and templates as we weren't publishing the master file.
• Components and Templates - a sticker sheet — a home for instances of components and templates as we weren't publishing the master file.

‍

• Documentation - a Figma file where UI designers documented product flows, but not components.

• Full Product Flow (light and Dark mode) - a file where the whole flow was living, being updated by the design system team.

• Components and Templates - a sticker sheet — a home for instances of components and templates as we weren't publishing the master file.

• Components and Templates - a sticker sheet — a home for instances of components and templates as we weren't publishing the master file.

We had a catch up with the design team to review all files we were sharing, define who owns what, and how to use each file. Some actions we took after this conversation:

Shaping file
This was a space for UI designers and devs align their work, this should be living in our shared space as it was too soon for the Design System to get involved. We agreed that designers would reach out when the component were in a good place to discuss with DS before implementing it. So we moved the shaping file to their world.

Full Product Flow
We we created the themes dark mode version of this file was archived. Now we needed to know who would have it. As we discussed, the design system owning this file was making things to complex because every time they needed to update something on the flow, they had to request to us. We were getting overloaded, and slowing them down. We handed over this file to them, from this point we would be responsible for components and patterns, flows would be on their responsibility.

Documentation
With the acquisition of Zero Height, all documentation would be moved there.

Components & Templates
For more transparency we decided to publish the kit and allow devs and designers to be able to view the master components file. Also, until we had the Zero Height up and running the Master Components file would be the source of truth for components.

Component Proposal
This would be used only for components requests.

By the end of these changes we went from 6 files being misused to 3 files with a clear purpose, and having its owners well defined.