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.
bring design and code closer than ever
enable a full control with any branding
ensure consistency in across our product
faster than before
time saved every month
by the design team
quicker and consistently
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.
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.
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.
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.
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).
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.
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.
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!
We performed an exhausting audit of every component. To save time we were further refactoring those components as we went along.
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.
Cross-team alignment was built in at every stage of the process. This allowed us to catch problems early, reducing costly rollbacks.
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.
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.
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.
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.
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.
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.
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...)
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.
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.
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.
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.
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.
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.