Implementing Design Systems: Three Different Real Case Studies
Implementing Design Systems: Three Different Real Case Studies
Hi, this is Mateusz! Welcome to Fundament, a newsletter that enables growth in UX and product design. Not subscribed yet? Join for free now:
Everybody knows that implementing, developing, and maintaining design systems is not easy. Furthermore, it's challenging to identify a single, correct, and foolproof approach, as each case is unique, and each organization faces different problems and challenges.
In this article, I’ll describe three cases of implementing a design system in organizations that had never used one before. I had the opportunity to work on these projects in three completely different organizations.
This article will not delve into the persuasion process of stakeholders for the design system, as this will be covered in a separate article (additionally, I was not involved in this process for every selected case). It will also not be another article on creating components, typography, or colors in the context of a design system. Instead, it will focus on real processes, decisions, and challenges in the design system creation process.
If you would like to organize your basics regarding system design, make sure to check out one of my previous articles:
Let's dive deep into the details.
#1 A SaaS with over 100k active users
Before the work began, the application was characterized by a lot of inconsistency in terms of visual issues and user flows. Different areas of the application were created at different times, often by people who were not designers. We had a very old administrative section, mainly used for environment configuration (product and/or customer administrators), a slightly newer section for environment management by customers (mainly lists and forms), and the rest of the application for regular users (including those involved in management) consisting of, among other things, training course modules and cyclical employee evaluations. Additionally, we were also starting work on completely new features (larger ones like a communicator or knowledge base and smaller ones, mainly implementing missing features for existing solutions).
We started with a visual audit of the entire application. We wanted to know exactly how big the inconsistencies were inside the application and also identify the number of potential components that we needed to recreate at the very beginning. It turned out, among other things, that the application had about a dozen styles of different buttons, the same form elements and shades of basic colors, as well as a lot of typographic styles. This formed a huge visual mess throughout the application, reduced usability, and made it significantly more difficult to develop it in a coherent and thoughtful way. This was the consequence of years of app development without clear design guidelines or strategy.
We've divided the design system implementation process into several areas:
Completely new functionalities were implemented entirely based on the design system.
The most important and frequently used views were redesigned and implemented based on the design system (mainly repeatable, similar list views and forms).
We decided to implement smaller changes in lower-priority areas in the current version until they could be redesigned. However, in many cases, we managed to make these views more consistent, e.g., in the button area, which increased consistency throughout the application and improved the user experience.
The remaining areas were prioritized in the context of the above activities and were waiting to be redesigned and implemented based on the design system.
All of the above actions were carried out within two Scrum teams, each consisting of one PO, several developers, and myself, the sole designer in the organization. I was a member of both teams, simultaneously working on application development and design systems alongside ongoing tasks.
After preparing the basic components and styles, subsequent components were prepared as needed. If the current system design resources were insufficient when designing new functions, new ones were prepared and implemented into the DS as part of work on a given functionality. The component was designed and tested, and after passing the test, it was used in its entirety and added to the component library along with the documentation. Working on styles and patterns looked similar.
Regarding the tools we used, all components and styles, along with the necessary documentation, were designed and stored in Figma. New features were also designed there, and coded components were stored in Storybook. Additionally, we tried out Zeroheight, which was intended to be a link between Figma and Storybook and the single source of truth; however, I did not have the opportunity to participate in its full implementation.
Some of the challenges we faced:
The team members had not worked with a design system before. A long time was needed to develop awareness of what a design system is and what it certainly is not.
Limited resources on the design side made it impossible to address all needs in a short period of time. For this reason, we had to come to an agreement together on the priorities related to the design system and ongoing development of the application.
Developing the best method of handoff. While implementing subsequent components and styles, we were able to collect the needs of each team member involved and address them, e.g., in the form of appropriate documentation in Figma. Additionally, we introduced an audit on the design side of the implemented elements so that I, as a designer, had a chance to check whether the components were implemented correctly in terms of visual and functional aspects.
#2 A family of applications
This case is a bit more complex. We were creating a design system from scratch for an entire family of applications and a variety of user roles. A single design system was to support a client-facing marketplace, an ATS used by our employees, and a VMS used by both external and internal users. As a cherry on top, an environment management application for our admins.
In addition, we also developed a separate design system for the mobile marketplace application.
In this case, the development of the design system looked completely different from the previous one. This time, I was not a lone rider, but I worked in a five-person design team. Each of us was assigned to one of the products and the team responsible for its development, which consisted of POs, designers, developers, and testers. At the same time, our entire design team worked on the design system.
Similarly to the previous case, the development of the design system was driven by ongoing work. After creating the basic components and foundations as part of our daily work, we developed the design system according to the needs arising from the development of each application. If a new need arose in a product, the designer of that product was responsible for delivering the component and was its "owner.” That means they were responsible for its development and maintenance, and the team in which they worked was responsible for its implementation. The work on the components was part of the sprints, but in addition, every Friday was dedicated exclusively to the design system. Fridays were for creating components, patterns, and documentation. We also had weekly meetings with developers to discuss current issues and verify our ideas.
Every newly designed item was discussed internally with other designers and developers at various stages of creation. We analyzed similar needs in our products and collected feedback from other team members. Finally, each team member had to approve a component or other design system element before it could be added to the Figma component library and used in any product.
As in the previous case, when creating the design system, we already had existing applications that did not show visual or functional consistency between them. Additionally, applications within themselves could have screens designed at different stages, which also caused additional inconsistencies within the applications themselves.
The design system implementation process was divided into several areas, which is interestingly almost the same as in the first case:
All new functionalities were implemented entirely based on the design system.
Key and frequently used views have been redesigned and implemented based on a design system.
Smaller changes in lower-priority areas were implemented in the current version.
The remaining least priority areas were waiting to be designed and implemented based on the design system later after the most important areas had been addressed.
In terms of tools, the weapon of choice was Figma, which we used to design components and create documentation. On the development side, it was Storybook again, which was to become the single source of truth later on, so we planned its structure, created additional pages with foundations and patterns beyond the components, and started to move documentation from Figma to Storybook.
The challenges that appeared during the implementation and development of the design system were also very similar to the first case. They mainly involved fostering cooperation between team members, building awareness of the system design in the organization, and quality control. To solve the last one, we introduced visual audits as a part of the designer’s duties.
#3 A multi-brand news platform with over 16m monthly users
The third, last, and biggest case study is an online platform made up of dozens of different thematic brands.
It's also worth noting that this is a best-case scenario for someone developing design systems, as the organization has decided to create a dedicated design system team consisting of designers, developers, QA testers, and POs with its own backlog, roadmap, and scrum teams.
But let's move on to the implementation and maintenance process.
When we were working on the strategy, we assumed that the implementation of the design system in the first stage would cover only one of many thematic brands. Most of our brands have similar needs when it comes to components, but at the same time, each needs components that will cover functions not available in other brands. So, we first chose a brand that allowed us to create as many basic components as possible, which would also cover most of our other brands, and we delivered brand-specific components.
In the beginning, we recreated the previously mapped components based on the selected brand and then delivered specific components. Because we assumed that we were not implementing the entire brand at once, we started with a few, often repeating views. This also allowed us to test different solutions and approaches in terms of the design process, collaboration between team members, and technology while providing the most important views for the users.
In contrast to the other two cases, here we had a single development path: to meet the demand and gradually implement new views based on the design system. We did not need to develop simultaneously and dig into and develop old views that were not based on the design system.
It's worth noting that before we started designing the components, we had already developed the necessary foundations for their creation, including typography, colors, grid, and spacing. At this stage, we also prioritized the foundation issues to focus on the most important and most needed ones while addressing the less important areas due to future resource constraints.
Additionally, due to the project's large scale, it was obvious to use design tokens (we used Variables in Figma with the support of the Tokens Studio plugin). This allowed us to scale the design system to other brands and, in the future, to go beyond the platform and support other products.
Thanks to this approach, we are able to quickly recreate most of our several dozen brands based on the design system. The additional work needed is to refine the colors and provide specific components. In the future, once our brands are fully covered with the design system, we will be able to address other, less important areas related to the design system.
The design system team is also responsible for developing the previously mentioned brands, which is why, at this stage, we do not have any other users of our design system. However, there are also a few other teams in the organization responsible for, among other things, the CMS that supports the platform and a few other applications that do not currently contribute to the portal's dedicated design system. However, analyses are underway to include the CMS and other products under a single design system. In this case, the design system team will no longer be designing just for itself but will also have its own users as a product - designers, developers, and stakeholders from other areas in the organization and will need to address their needs, which will significantly change the approach to developing the design system in the future.
Regarding tools, our primary tool is Figma, where we design components and create documentation. On the developer side, it was Storybook again, which is ultimately intended to be the single source of truth, so we planned its structure, created additional pages with foundations and patterns beyond the components, and started transferring documentation from Figma to Storybook. Tokens Studio is also an additional tool for creating and managing design tokens.
Various challenges have emerged and continue to emerge along the path of design system development, some of which overlap with challenges from previous cases:
As a new team, we needed time to develop appropriate processes and communication to eliminate errors in the components we delivered. One solution is the already mentioned audit of the delivered components, where designers check the correct implementation and compliance with the guidelines. Additionally, we conduct 1:1 handoffs with the developers responsible for implementation and ensure the documentation is detailed.
The growing team meant that meetings were overloaded and unnecessarily long, and it also made communication and information transfer difficult. We decided to create two smaller scrum teams that address different needs. The first one maintains what we already have, and the second one develops the system's design, provides new components, and addresses brands' needs.
As a team, we are still working on raising awareness within the organization of what a design system really is and the value it brings to the organization, as well as the role of designers in this process.
The approach of working with design tokens is evolving over time. There is a dedicated person in the team who takes care of token development, analyzes their current usage, optimizes them and eliminates errors. This sometimes requires additional resources to modify the existing token structure.
Also, over time, we return to areas developed at the very beginning, e.g., rules regarding the grid and building views in Figma. As a team, we already know the advantages and disadvantages of the first approach, and we work intensively on solving problems that appear during work.
To ensure the quality and consistency of the solutions we deliver, we, as a design team, are streamlining our internal communication and processes. One practice that works well for us is the internal review of created components. Each of us is responsible for a component that we deliver, but in order for it to be included in the design system, it must be approved by other members of the team. We check for compliance with the rules, the structure of design tokens, the construction in Figma, and the documentation.
Lessons learned
Although each organization, product, and design system is a unique case requiring a unique approach, we can find many similarities. I have encountered identical challenges and developed a comparable strategy for implementing a design system in organizations that have never had any experience with it.
Nevertheless, it is important to approach each case individually. Even if we take the same steps as those I mentioned or those we took on another project, let us be sure, supported by analysis, that this is the right choice in this particular case. We don't have to reinvent the wheel, but let's not blindly follow what worked in the past, as it may not always work in the future.
Tool of the week
Spline
Spline is free 3D design software with real-time collaboration that creates interactive experiences in the browser. It offers easy 3D modeling, animation, textures, and more.
♻️ Share this article
If you found this post useful or entertaining, consider sharing it with one of your design or product management pals!