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.
MEET THE TEAM
As the main Design System Designer in the Sky Sports team, I collaborated closely with designers, stakeholders, devs. Here's an overview of the team I collaborated with:
2 UI Designers
Stakeholders: UI lead, engineering manager, PMs.
15 iOS and Android developers
DISCOVERY
I started the discovery phase by exploring existing design files and auditing the app’s user flow. My goal was to understand how colours, typography, and UI components were being applied across different screens and journeys. In parallel, I spoke with designers, developers, and product managers to uncover pain points, gather insights about current challenges, and better understand where the system was falling short.
To validate and expand on these findings, I facilitated a workshop with developers, UI and UX designers, and team leads from both sides. Using an affinity diagram, I identified the most common pain points. I mapped out user journeys, highlighted inconsistencies, and prioritised problem areas based on their impact and feasibility.
This research and collaboration helped set a clear direction for the project, allowing me to identify key areas to focus on and target the most critical challenges first.
This phase was all about understanding the problem, gathering insights, and defining opportunities, the foundation for a scalable and efficient design system.
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."
Identified Problems
While some foundational problems were clear from auditing files and talking to UI designers, other issues were uncovered during the workshop. Here are the problems we found through the research:
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.
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.
SOLUTION
This phase focused on turning insights into action, building a scalable, maintainable, and developer-friendly design system that supports the entire team. Based on research and audit I implemented key actions to establish a strong FOUNDATION. The first actions were:
Scalable colour palette
Worked with the UI team to define a scalable colour palette for light and dark mode that covers all use cases.
Reduced opacity that was overused specially on dark mode as the new colour palette was covering all use cases.
With the new colour palette, we eliminated rogue styles, including opacity variations, reducing the color stack by approximately 69%.
Themes & Tokens
Implemented variables and tokens to enable light and dark mode. Additionally, we developed a UX theme, consisting of wireframes that outline the flow, helping UX designers save time and work within a predefined structure.
With variables and tokens in place, designers can easly switch between light and dark mode, making the process more dynamic while saving time and reducing bugs.
Typography
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.
Refactored components
Consolidated light and dark mode components and styles into a unified themed system.
Rebuilt components to be more lean, responsive and easy to use.
By consolidating themes and making more leans and flexible compoonents, I reduced the total number of components from 1000 to 160.
Code
The source of truth for foundations and components is maintained in Figma, while developers have also built a reusable UI toolkit in code. Below is a snippet of Jetpack Compose UI component using design tokens for consistent colour and typography. Supports gradient backgrounds, light/dark themes, and a glass effect.
DELIVERABLES
Here are some of the deliverables achieved by improving our foundations:
1000 > 161
Reduced number of components
≈ 37%
Reduced on typography stack
≈ 69 %
Reduced on
colour stack
3 +
Themes - light, dark and UX mode
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, 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.
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.
OUTCOMES
Greater collaboration between teams
Designers and devs became significantly more active in DS discussions.
Increased feedback loops allowed for faster iterations and continuous improvements to the system.
Developers on Slack
The number of unresolved developer questions dropped noticeably, improving efficiency.
Bug resolution became significantly faster, with most issues addressed within hours instead of days.
Long term impact
Faster handover process, cutting down unnecessary meetings.
Increased trust in the Design System, making it a true source of truth for both designers and developers.
Higher adoption
A noticeable increase in designers following DS standards during handovers.
Android and iOS teams built a UI Tool Kit based on the system.
Fewer inconsistencies - design files.
On this page