How an audio player component tells the story of NewsKit Design System’s changing strategy
Introduction
Contrary to The Buggles’ declaration that Video Killed the Radio Star (the first song ever played on MTV back in 1981), radio is still going strong and is, in fact, having a resurgence. In 2020, 89% of UK adults listened weekly to the radio. This was the same year The Times and Sunday Times launched Times Radio — a move into digital radio after 200+ years of producing daily newspapers.
So it fell on us, the NewsKit design system team, to deliver a radio player — a component that would be reusable across talkSPORT, Virgin Radio and others. This opportunity would allow us to test our early thinking on a real-world product while fulfilling the ambitions of the radio broadcasting teams to reduce reliance on third parties.
“It can’t be that hard,” we said, continuing with the naivety that was a feature of the early days of NewKit’s development. Needless to say, it was. Not least because it was one of the first components we’d built, and we didn’t have many of the constituent parts. A ‘live’ radio player, streaming audio content, requires a play/ pause button and not much else. But we also needed to provide a player for recorded content, which is more complex; You need to skip forward and back within a track and to the next or previous track. You need to be able to find a particular point in time with a seek bar. There was a lot of logic to be ironed out (such as how to handle the complexities around poor connections) and a lot of discussion about the level of flexibility we should provide.
Version one of the radio player took three months to build, delaying the Times Radio team. Once their engineers tried to integrate the component, it was clear we hadn’t provided enough flexibility. They found it hard to use, and minor customisation was complex. They ended up abandoning half of the radio player component, only integrating the audio player part.
It culminated in some intense soul-searching and a loss of morale across the design system team.
Flexibility first
But don’t worry, it didn’t last. Hours later, we regrouped and set out on a total refactor of everything we’d built, providing a much more flexible and robust theming system that you can read about in detail here.
We also reconsidered where we draw the line on what the core system provides. In retrospect, there was little value in us building a radio player. A consumer could more easily cater for their requirements by using our audio player component and combining it with a card. This way, they had much more flexibility over layout options. We agreed that complex compositions of low-level components (what Brad Frost would refer to as ‘organisms’) no longer had a place in the core system. Requirements from brands were too varied, and we couldn’t account for every eventuality. Our guidance should be restricted to clear best practices — not layout choices.
Composable subcomponents
This approach seemed to be doing the trick for a while, and our audio player was adopted across multiple brands. We had some feedback, fixed a few bugs and improved the accessibility of the component.
But there were still some layout problems. For example, Virgin Radio needed some additional space applied when using the audio player on small mobile screens. We hadn’t included a prop to allow this and fixed it as a bug. But this was symptomatic of a broader issue that also needed addressing (more on this shortly).
Our audio player component was built to cater for live radio and recorded content (e.g. podcasts), but as we increased adoption across brands with different needs, we started to receive more unanticipated requests: An inline audio player within a news article. A text-to-speech player in a navigation bar. A persistent player anchored to the bottom of a screen.
The audio player, while managing to fulfil the initial requirements, was still opinionated. A consumer could customise the component extensively (sizes of individual elements, spacing, themes etc.), but the individual elements could not be entirely repurposed for a new use case. We realised our prescriptive layout was never going to serve the needs of all our consumers. This was a harsh realisation after the team had put in so much time and effort to get to this point.
Taking on board feedback from our users and after some more reflection, we decided to break each element into a separate, exported component. This would free our consumers to compose audio players to meet all manner of edge cases and not be tied to a specific layout.
Instead of exporting compositions, we started to outline best practices in our documentation and provide scenarios in our Storybook for all common use cases. This allows product teams to access considered best practice solutions out of the box and have ultimate flexibility when needed. It’s the best of both worlds.
Space-saving
The multitude of minor tweaks to layouts that were required on the original audio player caused us to reconsider how we manage space. In the system’s early days, we took inspiration from Nathan Curtis’s excellent post ‘Space in Design Systems’. We introduced stack, inline and insets space tokens and applied them to components with overrides for users to configure their required space values.
It works, and had we only had to concern ourselves with the requirements of a single brand, would have continued to be a robust solution. But again, we couldn’t account for the unexpected requirements consumers would have around the layout of components. They wanted to be able to apply space at will.
So we recently introduced ‘logical props’ to the components, enabling a more fluid approach to space. The addition of these new spacing properties allows users to achieve custom layouts without having to reach for additional layout components — improving ease of use and web performance on the front-end.
Embracing evolution
Like all design systems, NewsKit caters to specific requirements — this is a system optimised for media. As a multi-brand system, we’ve identified plenty that can be shared across media brands. But there is still a lot that’s distinct. The differences are the brands’ identities — what makes them unique, and our aim for the system is to standardise where practical but never erode the uniqueness of the brands we support.
Through trial, error and consumer feedback, we’ve gradually increased the system’s flexibility so consumers can more easily achieve their goals. But the edge cases and nuances we’ve come across also have a place in the system. We embrace the unexpected use cases as these can guide and inspire other system consumers, helping to open unexplored avenues and provide richer solutions. The benefits are great — the collaborative exploration and pushing of boundaries offer innovative solutions that can be shared, driving the system forward and allowing us to iterate and innovate with purpose.
Update: I’ve been made aware of another excellent blog post by Nathan Curtis on the same topic. It’s like it was meant to be. If that’s not validation, I don’t know what is.
