As the main Design System Designer in the Sky Sports team, I collaborated closely with design leads, a UI designer, and iOS and Android developers to simplify and scale the system delivering a consistent and scalable experience across platforms. Here are some of the deliverables from this work:
Reduced number of components
Reduced on
typography stack
Reduced on
colour stack
Themes - light,
dark, UX mode
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.
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.
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.
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:
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:
.gif)
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.
@Composable
fun SkyButtonPrimary(
text: String,
onClick: () -> Unit,
modifier: Modifier = Modifier
) {
val background = SkyTheme.skyColors.gradientPrimary
Box(
modifier = modifier.clip(RoundedCornerShape(4.dp)),
contentAlignment = Alignment.Center
) {
Button(
onClick = { onClick() },
shape = RoundedCornerShape(4.dp),
colors = ButtonDefaults.buttonColors(containerColor = Color.Transparent),
modifier = Modifier.drawBehind {
drawRect(Brush.linearGradient(background))
}
) {
Text(
text = text,
color = SkyTheme.skyColors.textWhite,
style = SkyTheme.skyTypography.buttonMediumStrong
)
}
ButtonGlassEffect(modifier = Modifier.matchParentSize())
}
}
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:
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.
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:
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.
With increased transparency, the entire team became more engaged with the design system.
By having a direct channel, devs no longer had to guess or search endlessly for answers.
With clearer processes, designers started handing over their work properly, using correct tokens and following guidelines.
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.
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.
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.
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:
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:
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.
@Composable
fun SkyButtonPrimary(
text: String,
onClick: () -> Unit,
modifier: Modifier = Modifier
) {
val background = SkyTheme.skyColors.gradientPrimary
Box(
modifier = modifier.clip(RoundedCornerShape(4.dp)),
contentAlignment = Alignment.Center
) {
Button(
onClick = { onClick() },
shape = RoundedCornerShape(4.dp),
colors = ButtonDefaults.buttonColors(containerColor = Color.Transparent),
modifier = Modifier.drawBehind {
drawRect(Brush.linearGradient(background))
}
) {
Text(
text = text,
color = SkyTheme.skyColors.textWhite,
style = SkyTheme.skyTypography.buttonMediumStrong
)
}
ButtonGlassEffect(modifier = Modifier.matchParentSize())
}
}
With increased transparency, the entire team became more engaged with the design system.
By having a direct channel, devs no longer had to guess or search endlessly for answers.
With clearer processes, designers started handing over their work properly, using correct tokens and following guidelines.