Architecting a design system to scale to 100+ apps across web, mobile, and TV
Overview
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.
Company
Simplestream
Core team
2 designers + 6 developers +
Head of development
Time
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.
Tools
Sketch, Figma,
Jira, Storybook.
In numbers
1200+
interconnected components
bring design and code closer than ever
130+
token variables
enable a full control with any branding
40+
documented topics
ensure consistency in across our product
Impact
800%
faster than before
🚀
~30 hours
time saved every month
by the design team
⏱
Outstanding
results
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.
Challenges
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.
Our Sketch pattern libraries before and after.
(Left) Before, containing all the components for all our platforms.
(Right) After, iOS library only. Each platform is separated inside its library.
Research
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, Ant.design, 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!
These are some of the sources we kept coming back to throughout the project.
Audit
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.
During the audit, mind maps proved a great tool to explore component relationships at a high-level.
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.
During the audit, mind maps proved a great tool to explore component relationships at a high-level.
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.
Our spacing token library in code and in Figma
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.
Problem
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.
Process
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.
Problem
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).
Process
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.
Solution
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.
.jpg)
How does it look in Figma?
Without a great Figma setup reflecting the design system, design and communication with developers breaks down.
Mobile component library
Web component library
TV component library
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:
%201.jpg)
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
Would like help with a project, share feedback or ask questions?
Please get in touch.
I have an inbox zero rule so I’ll see your message for sure and, I’ll reply with at least one smiley. I promise.