Almost everybody in the tech world knows the term “design system” these days. There are many articles around the internet and there are also special websites like this one which accumulate various design systems from around the world.
Here at Showmax we had a historical problem with inconsistency not only across all the platforms we support, but even within one platform itself. This problem caused many issues like dropping brand awareness, inefficient work on the designer and developer level, slower execution time as we didn’t have coherent and standardized design foundations and components.
How did the company get into this situation?
The first full-time designer was hired after 2 years from the time that Showmax was born. The company used different design agencies with different mindsets and guidelines. As Showmax grew, there was a need to build and establish a product design team in house. This is where it all began and the idea for creating our own design system came to light.
We tried and …. we failed (miserably).
The first attempts ended even before we started. We realized very quickly that how designers talk and name several elements is very different from how developers see it. We couldn’t find where one element ends and the other begins. We tried to separate the effort into different teams with dedicated designers for mobile apps and for web & Smart TV teams (btw, we are hiring) and work on two streams. The idea was to gather the results and see where we match in our thinking. We had several sessions, discussions and workshops around the basics but without any progress – everybody was super frustrated about the result and we had to put it on hold. Total failure.
So we tried again … and failed again.
Some time after the first attempt we hired more people into the team and the need for design rules and standardization was even higher. We knew that we were going to slow down the whole design and development process if we did not have the design system in place. The system can decrease the time to deliver and experimentations within a team significantly. This put pressure on us to reopen the topic again. This time we agreed on a dedicated designer who would work purely on the design system with all frontend teams. They started with an audit of all the components we had on every platform. The team had weekly sync meetings, workshops and other activities, but after some time the team was tired and unmotivated as they didn’t move fast enough. The energy and the setup of the team was not right and instead of constructive feedback and progress they challenged each other on almost everything. Total failure…again.
We did it! And it is a real success.
After all the experience from the past, we made a complete pivot in the journey. We established an internal “design group” consisting of product designers that are working on each platform - David Lengyel, Matouš Jemelka, Lukáš Podhola and Daniel Valčík. We also asked for support from a project management (yes, we know Design system is not a project, but product itself) to handle our operational, organizational, and tracking needs. So Pavla Safronov joined our group. The fun began.
We knew that we would have to gain the reputation and trust back from the failures that had happened in the past. First things first – we mocked up the structure of how we want our design system to work in Figma (the main design tool we use) and we started to write a solid business case for our C-level management to convince them, so that they will give us the time to build it. After the presentation to our CEO (Yolisa Phahle), COO (Barry Dubovsky), Head of Product and others, where we demonstrated how many shades of gray there were (not 50 but 39 – only on iOS platform!!) and how the design system impacts costs to build anything frontend facing for the company, we received the time we needed. But … we had to work on our daily agendas and tasks as well.
Equipped with the right team, the motivation, approval from the senior management, and a clear time limitation, we mapped out what components and foundations we needed. This gave us clarity on how high the mountain was. To manage expectations we created a timeline (roadmap) where we applied all the foundation blocks and components and divided them into design work and implementation development work. This set an expectation for our stakeholders. Each Friday we have jumped on our weekly DS sync and updated each other on the status of our respective design system tasks. There have been many topics where we have opened Figma with our exploration file and showed each other different approaches and techniques and made conclusions.
Our product is not complicated, but what complicates it is supporting many platforms and teams from landing pages and payment secure pages where our acquisition teams are working via mobile apps (iOS and Android - smartphones and tablets) to leanback experiences such as Smart TVs, tvOS, and Android TV.
With such a diversity of development teams, we had to create strong foundations that are shared across whole teams and act as the basics for component creation. Those components might differ based on the libraries linked to each team. As you might expect, native mobile apps use different patterns, approaches, and goals than, for instance, a Smart TV or the acquisition part of the product. A component that works on one platform (e.g. the bottom bar) will not work on a Smart TV. For this reason, the libraries contain components that are usable on a specific platform or part of the product only. Our development teams have created their own code libraries with the same design tokens and naming convention that we use in Figma. Expect an article already being written by Zachary Rowden on how our acquisition team implemented our design system for their code base.
Doing everything remotely and asynchronously
The Covid era opened our mind to how to work, even on complicated tasks and activities, fully remotely. And across continents. All the work we have done on the design system was built from our homes via video calls and Slack channels. We have got familiar with this setup and it helped us to introduce a means of communication with other departments within the company. We use several channels in Slack:
For any update or announcements from our side about design system changes (just recently we refactored Table Row for the iOS team). This channel is for announcements only.
For any discussion between designer, developers, product managers, or anybody else from the company.
For “design group”, we have a private channel where we discuss day to day progress, iterations, ideas, feedback, and more.
In case you are interested in working asynchronously, Matouš Jemelka (one of us) wrote a really cool article about it – check it out here.
Where are we heading?
Building a design system is just the beginning of a long-term journey. Count on that before you build your own. We want to focus on usage and its analytics in Figma and in the code. Luckily, the Figma Organisation plan has the ability to measure each library and component.
Our plans are to integrate more teams into our design system, we have already started to talk with our Marketing department and CMS team as we can involve other parts of the company and establish many more synergies. We are also working on our Copy system which will cover every corner of how we communicate within the product to our customers and visitors. But we will write about this part in another article.
Check out our first version of design system documentation created in Supernova and send your feedback or comments to design@showmax.com.
