UX Strategy | Sky Sports

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.

When I was asked to build their design system, I was excited to take on the challenge. The team had already made an attempt, and developers were trying to adopt it, but they lacked the resources to keep it going.

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. 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 colors, 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 several key problems:

• The colour palette wasn't scalable - shades jumped inconsistently, leaving gaps for certain use cases.
• Components lacked structure, missing states, and anatomy.
• 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 - same for typography, which had separate versions.
• Dark and light mode weren't aligned, creating complexity in colours and tokens.
• Naming conventions were unclear, making it difficult for designers and developers to find and use the right tokens.
• Design tokens and variables were not fully implemented, leading to inconsistencies and manual workarounds.

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 i 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

With a clear understanding of the challenges after researching and auditing, I defined key actions and where to start. The plan included:

• Implement variables and tokens to ensure consistency and flexibility.
• Create a scalable colour palette to cover all use cases and reduce inconsistencies.
• Reduce typography stack to make it more structured and efficient.
• Develop a more intuitive naming system for colours and typography.
• Recreate components for better alignment between design and development.

This phase was all about turning insights into action—building a scalable, maintainable, and developer-friendly design system that supports the entire team.
Colour and typography were major problem areas identified during the discovery phase, which I addressed in two dedicated case studies.
However, challenges uncovered in the workshop also needed solutions, and I’ll dive into those next.

ADDRESSING THE WORKSHOP CHALLENGES

What about the other problems uncovered during the workshop? Beyond colors and typography, issues like communication gaps, lack of transparency, and unclear processes needed immediate attention. Some solutions were quick wins, while others required ongoing collaboration.

1 - Improving Communication & Collaboration
‍
❖ 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 we used for Design System discussions
• Created 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 SyncsWe established bi-weekly meetings where UX designers, UI designers, PMs, developers, leads, and heads of products (both DS and Sports) could come together. This became a safe space for discussions, sharing updates, and problem-solving.Some key discussions included:

• How to provide clear specs and anatomy now that devs had lost access to Figma's Dev Mode.
• Establishing handover process between designers and developers.
• How teams should request updates from the design system efficiently.

❖ Sprint-Based UpdatesA major frustration was the lack of transparency—teams didn’t know what the DS team was working on, what was coming next, or how to request prioritisation. To fix this:

• At the end of every sprint, I shared what had been completed, what was in progress, and what was coming next.
• This allowed 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.

2 - New Ways of Working

Before, we had three separate Figma files for different stages of handover:

• Component Proposal - where UI designers requested new components.
• Shaping - a collaboration file between UI designers and developers.
• Documentation - a Figma file where UI designers documented product flows, but not components.

❖ The Solution: A Single Source of TruthTo streamline this, we published a Master Components file and a Foundations file—these became the source of truth for components and styles.
When developers needed handover details, they could check the Master Components file directly.
If something was missing or incorrect, they could flag it immediately, and we would address it on the spot.

By establishing clearer communication, improving transparency, and redefining our workflows, we created a more efficient, collaborative, and developer-friendly design system—one that truly supported the entire team.

REAL OUTCOMES

❖ Greater collaboration between teams
With increased transparency, the entire team became more engaged with the design system.

• Designers and developers became significantly more active in DS discussions, leading to more engagement.
• Increased feedback loops allowed for faster iterations and continuous improvements to the system.

❖ Developers started using Slack to share needs and report discrepancies
By having a direct channel, devs no longer had to guess or search endlessly for answers.

• The number of unresolved developer questions dropped noticeably, improving efficiency.
• Bug resolution became significantly faster, with most issues addressed within hours instead of days.

❖ Higher adoption from designers
With clearer processes, designers started handing over their work properly, using correct tokens and following guidelines.

• A noticeable increase in designers following DS standards during handovers.
• Fewer inconsistencies in design files, reducing rework and QA time considerably.

❖ Long-Term Impact

• Faster handover process, cutting down unnecessary meetings
• Fewer design inconsistencies, leading to more polished product
• Increased trust in the Design System, making it a true source of truth for both designers and developers

These improvements not only increased efficiency but also created a culture where teams felt empowered to contribute—turning the design system into a collaborative success.