Architecting a design system to scale to 100+ apps across web, mobile, and TV


In its first few years, SimpleStream expanded quickly — building advanced, white-label video streaming applications natively for eight different platforms (across mobile, web and TV), and serving over 16 international broadcasters and 200.000+ users.

By the time I joined in early 2019, this quick growth had lead to a widening gap between design and code and big inefficiencies in the code. These translated into missed deadlines and wasted resources.

Our design system is helping us close that gap by making the product development process faster, more reliable, and increasing the quality of the final outcome.



Core team

2 designers + 6 developers +
Head of development


12 months
(part time)

My role

I led both the strategy & execution on the design system, worked with developers to align and update our workflows, and wrote the design documentation.


Sketch, Figma,
Jira, Storybook.

In numbers


interconnected components
bring design and code closer than ever


token variables
enable a full control  with any branding


documented topics
ensure consistency in across our product



faster than before


~30 hours

time saved every month
by the design team


quicker and consistently


Context — working on a white-label application

What is a white-label product?

You won’t find a Simplestream app on any app store, but you’ll find 100+ apps that we built.

This is how Simplestream pays the bills. We design and build some of the most advanced video streaming apps available, and, for a monthly fee, each of our 20+ clients (mostly media companies) gets their own app for iOS, Android, Web, tvOS, FireTV, AndroidTV, Roku & PS4 that they control through our CMS.

This is what some of out clients' iOS apps look like.
They share components, but each has unique content, branding and architecture.

Why do we need a design system?

Our problem

Inefficiencies common on many digital products quickly become extremely wasteful on a white-label supporting 100+ apps on app stores.

This has the single biggest negative impact on the bottom line.


Big product, small team (working on the design system part-time)

We are 2 designers and 15 developers. Our day-to-day responsibilities have not changed and we are still responsible for the design roadmap across 8 platforms. Realistically, it may take years until a design system is fully implemented.

Our approach: Solve problems one at the time. Agree on a small, obtainable goal and validate solutions through experimentation before implementation.

Efficiently launch, update and maintain 100+ white-label apps across 8 platforms.

Each new client requires our apps to be re-skinned and re-architected. After launch, we must also update and maintain all of our 100+ live apps.

Our scale and constant growth means even small issues quickly pile up and turn into huge problems for developers.

Our approach: because of this huge existing code-base, we tackled high-impact, low-effort solutions first, progressively reducing the workload required to maintain both design and code.

Maintain a high quality, consistent design language across mobile, web and TV.

Over the years, inconsistencies between our platforms have grown. These make the code more complex and create usability problems for users.

Our approach: so much has been done that is hard to define a single approach. Our highest-level aim has been to simplify by (1) Building an overarching style across our eight platforms, and (2) Creating a single UI for each of our four device types (mobile, tablet, desktop and TV).

Solve localisation for 10+ languages and fully dynamic content.

Through our CMS, a client can edit almost any text string and image on our apps. We also offer support for any left-to-right languages, including English, French, Spanish & Icelandic.

Our approach: on the engineering side, we have been working to integrate dynamic content into our apps. From the design side, we worked to set rules on the behaviour of text strings and images that give freedom to each client but maintain the UI integrity.

The journey before the beginning.

We can't start thinking about a design system before we have a pattern library.

Even before I joined Simplestream, the team was aware that the design files were not in the best shape.

Each of our eight platforms had a small pattern library, but it was incomplete & inconsistent.

This was not helped by the fact that our design files must be re-skinned for each client, which restricts the ways we can use our design tools.

During my first 8 months, I was supported to spend as much time as possible getting our design files in shape.

We defined styles, componentized the UI, and created separate pattern libraries for each platform. All while making it possible to easily re-skin any app.

We increased the number of components from 195 to 800+ and styles form 5 to 27. This lead to a massive increase in the quality and speed of any new design work.


Public design system docs and design files. Material design proved our go-to as it's built to be white-labelled, but also, Shopify’s Polaris, Atlassian,  Microsoft Fluent,, and more.

Articles & books by design system experts. Of these, articles by Nathan Curtis stand out by providing incredible depth on many of the aspects of a design system.

In-person Meetups, YouTube videos, podcast and more!


Audit and comparison to code

We performed an exhausting audit of every component. To save time we were further refactoring those components as we went along.

Key insight

Our new pattern library allowed us to analyse our components. We found a large inconsistencies at every level of the UI (from patterns to components to fundamental properties like size, colour and spacing).

To make our system scalable, we had to design and code strong foundations. These would serve as a framework to build more complex components.

Iterative design–development collaboration.

Cross-team alignment was built in at every stage of the process. This allowed us to catch problems early, reducing costly rollbacks.

Tokenising the UI

Produce the sub-atomic elements and rules that underpin the system

Based on the insights from the UI audit, we embarked on the process to define and document the fundamental properties that give UI components their appearance and behaviour.

The most important are: layout, colours, shape, and motion…

But also: spacing, text styles, icons, corner radiuses, shadows, image ratios and more…

After identifying these properties, we went through a process based on small experiments and consultation for technical feasibility to eventually come up with solid rules that underpin our design system.

TailwindCSS utilities to bridge the gap between design and code

Under the direction of our Head of Development, all designers and developers began adopting Tailwind naming and utilities to build our UI.

Why? This allowed us to standardize our components and speak the same language across all teams and platforms.

Defining and documenting these rules proved the key to success.

Solid foundations. These properties provide the foundation on which every other piece of UI is built on. Creating more complex components became a lot easier.

Political capital. Once implemented, these properties provided an immediate benefit, convincing more teammates of the benefits of a design system.

Example: colours and accessibility

Colour might seem like an small problem to solve, but when dealing with a white-label that launches several new apps every month, it's essential to get it right.


Anyone that has done a rebrand knows, re-branding an app is not as easy changing the colour values. There are many instances where this approach breaks down.

Because of this, a new client might required hours of manual overrides by developers and designers.


We needed to be very granular about how we controlled colours on our UI.

Over several months, we introduced and tested dozens of new colour tokens.

When applied to specific UI elements, these tokens gave us full control over accessibility and the final outcome.

These included:

Brand colour tokens. Provided by the clients

On colour tokens. Define elements that sit on top of other coloured elements.

Text colour tokens. Define the colour of particular text elements.

Button colour tokens. Define the colour of buttons and their different states.

Our spacing token library in code and in Figma

The result

After applying our colour tokens, our apps could be re-branded by just switching the colour values on the API.
This made the process 5x times faster, produced better results, and ensured accessibility.

Our process: start at the highest level of abstraction, and work our way down.

Simplify and standardise with Atomic Design

We used Atomic design as a framework for our design system.

We went through a process of breaking components and using our design tokens to rebuilding them in a standardised, documented, and reusable way.

Beginning work with the smallest atomic components (e.i. buttons, flags, thumbnails...); and combining those atoms to form progressively more complex components (e.g. thumbnails + text into content cards, content cards into playlists, playlists into sections, sections into views...)

Example: building responsive playlists.


Building our web carousel was a real challenge, not only because it had to be responsive, but because the designed changed depending on the content displayed (live, on-demand, catchup...) and entitlements (AVOD, SVOD & TVOD).


We fist began by solving the highest level problems. Properties like corner radius, size, overlays and colour were applied inconsistently.

We worked together with developers to come up with a standardised system for each property and created the documentation to support them.

We then used these properties to build the atomic components of a carousel and used those atomic components to build more and more complex components, eventually defining the whole carousel.

We used Figma Variants to keep a live copy of every possible carousel type.


For designers and developers, having all our components worked out and clearly presented, allows us to work faster and more consistently, with any problems being immediately highlighted.

How does it look in Figma?

Without a great Figma setup reflecting the design system, design and communication with developers breaks down.

The challege

Our challenge was to keep every UI component connected to the core of the design system while allowing for colour, fonts, text and layouts to be customised to each of our 30+ clients.

Our set up

Using libraries and strong naming conventions we can keep styles and UI components separate yet interconnected.

We use libraries to keep styles and UI components separate from the final UI.

This allows as to change any style in the final UI in a way that is predictable and that doesn't affect the core components.

If anything changes on a core component, we can easily update the final UI with the click of a button.

Impact of our Figma setup

Using libraries and plugins on Figma we can ingest a client's styles into our system in about 15 minutes and rebrand any app with their styles in under 30 seconds.

This is 800% faster than before and lead to time savings of ~30 hours each week.

Our massive time savings allowed us to push forward the design system while meeting all other responsibilities.

Here is what the process looks like:

This is what switching clients looks like, in real time.

A map of our Figma libraries:

Documentation — The cornerstone that holds it together.

We can’t stress enough how important documentation is for a design system. It's the reference, the single source of truth, and where conversations about evolving the system begin.

These are the main topics of our documentation, it goes far broader that just UI.

Documenting styles & their use

Making styles and best practices easily accessible to the whole team promotes their correct use.

We used Zeroheight and Loom for design documentation while developers used Storybook.

Documenting reasoning

We found documenting what and the why behind the system was extremely useful for other members of the team to understand why things are like they are.

It also makes it easier to find holes in the reasoning and evolve the design system.

Documenting workflows

Developers created their own, extensive documentation around their workflows.

Designers created new workflows on everything from creating components and styles to including a new client into our design system.

Documenting these workflows is essential in maintaining our design system and we document them in the same tool. We outline the workflow on Zeroheight and use Loom to walk through the steps.

Examples of our docs on Zeroheight:

© Ignacio Allendesalazar