Building PleaseFix’s multi-brand design system with a single specialized designer
Case study: The challenges, insights and successes of creating and maintaining a multi-brand design system for PleaseFix.
By Edern Talhouet, Director of Product Design
🔗 A public version of PleaseFix’s default theme library is available on Turbulent’s Figma community page.
The importance of a multi-brand design system for PleaseFix
PleaseFix is a bug-reporting product developed by Turbulent for the video game industry. Its client list includes studios such as Ubisoft (Rainbow Six Siege), Cloud Imperium Games (Star Citizen), and Ghost Ship Games (Deep Rock Galactic). PleaseFix aims to turn player frustration into engagement by leveraging high-quality and comprehensive bug reports generated by players.
The current PleaseFix team consists of a general manager and product owner, three developers, a QA analyst and two designers. One designer focuses on feature improvement while the other is dedicated to the design system.
Design systems have become an integral part of Turbulent’s design and production processes. This wasn’t always the case, however. Turn back to 2019 when the PleaseFix project began. At that time, designers were creating simpler UI kits using Sketch, with basic technical documentation only. Designers and developers also collaborated much less during the production flow compared to today.
When we began designing the initial mockups for PleaseFix, it was apparent to us that we needed to provide clients with visual customization options that would integrate seamlessly into their ecosystems. Additionally, we observed an industry-wide trend towards creating and sharing comprehensive multi-brand design systems. Despite having a limited budget for only one, and eventually two, product designers, we viewed this challenge as an opportunity to expand our expertise while developing a new product.
We have strengthened our commitment to creating comprehensive design systems since the PleaseFix launch. Drawing from the lessons learned through this project and other internal initiatives, we are currently developing design systems for multiple products. This approach empowers designers and developers to create cohesive and scalable products.
Learning by doing…and failing 😨
In 2019, we developed our new product and created mockups and prototypes with different visual styles based on existing and fictional games in order to determine the level of customization for PleaseFix integration.
Once we had completed this stage, we quickly moved to create a minimum viable product for the Star Citizen community. Launched in early 2020, it was a tremendous success, with the community adopting it from the outset.
Following the launch, we began working on PleaseFix’s second theme for Ubisoft’s Rainbow Six Siege. The team’s vision for a semantic design token system covered all text styles and colours. It was an exciting and inspiring new process, which, if successful, would allow us to create new themes quickly and efficiently.
Initially, we believed that our design token system was solid enough to serve as a durable foundation. However, its limitations rapidly became apparent as we began developing the second theme. In order to remain aligned with Ubisoft’s visual guidelines without deviating from the existing Star Citizen theme, we had to create numerous custom overrides on top of our semantic design tokens in our design and CSS files. The resulting complexity weighed down the design process.
The second product launch was nonetheless a success; users, players and Ubisoft management all lauded the results. Internally, the mood was more mixed: It had taken us more than two months to develop the second theme — far longer than anticipated — and the technical state of the components was subpar. In all honesty, it was a mess. 🥲
In hindsight, defining our design tokens so early was the wrong move. We failed to properly verify if our initial decisions still made sense. One theme was in production, but as our workflow became more complex, unexpected issues arose. Our approach ultimately proved to be unsustainable. To address the problem, we modified our process to empower designers and developers to make updates to components without the worry of disrupting our various themes.
Our journey to refactor (Hello, Figma 👋)
Other teams at Turbulent started adopting Figma around the same time (Sketch being the preferred tool prior to that). Switching software presented us with an opportunity to refactor all of PleaseFix’s components. Drawing on lessons learned during the development of our first two themes, we mapped out a new production process and built a six-month roadmap centred on the design system.
Dedicated design system team members
To enhance the workflow, the team first hired a UI developer and a designer to work specifically on design system tasks during each production sprint.
Two years into the project, several major companies (such as Shopify or Atlassian) had made their respective design systems public and many expert articles on design tokens existed. It was (and still is) very inspiring. However, with only one dedicated designer, we needed to set realistic goals that matched our velocity.
Various processes that initially seemed promising over time have proven to require a lot of effort for very little in return. For example, we previously manually documented direct Storybook links for every component in our Figma libraries. While this approach seemed like a good idea at first, it turned out that those links were never used by the team. We have removed those links, and we planned a discussion 3 months later to verify whether it was the right decision. It is crucial to regularly question decisions that seemed best several months or years ago. This ensures that you do not end up with an unnecessarily long list of tedious tasks.
A more robust design token system
First, we learned how to use Figma by recreating our existing components. We identified every customizable variable in each theme, including colours, fonts, image assets and icons. We then defined three levels of design tokens:
- Global tokens for the theme’s colour palette (primary, secondary, highlight, etc.)
- A few semantic tokens from our first version for generic colours (focus state, validation colours, etc.) and typography
- Component-specific tokens to be able to adjust a range of visual elements to fit each game’s visual guidelines. At Turbulent, we usually rely on global and semantic tokens only in our projects. However, for PleaseFix, the system needs to be adaptable to align with the visual guidelines of both our current and future clients.
Each token is thoroughly documented in Storybook and created as a style in Figma to ensure consistency.
Additionally, we revised each component’s contrast ratio to comply with the latest AA accessibility guidelines and adjusted their size and spacing to align with a 4–8 pixel grid.
Figma libraries, reviewed by devs
Given that we only have one designer for our design system, it’s crucial for us to maintain well-organized, future-proof Figma files and ensure seamless collaboration with other team members.
All our components are reviewed in Figma and referred to by our UI developer(s) during Storybook integration. Additionally, our design system designer provides documentation for other designer(s) on how to use complex components in mockups, as we use advanced Figma features such as component props.
Successfully building our default theme
As we approached our six-month deadline, our confidence was low; only half of our components had been refactored, despite a great collaboration between designers and developers. Our initial goal was to create a new theme quickly. Now we needed to test our theme creation process in order to validate our recent work and reassure the various stakeholders.
The need for a neutral default theme became apparent for two reasons:
- Technical: Our previous design token system had failed because we worked on two custom themes without relying on standard rules. A neutral source of truth would eliminate such issues in the future.
- Business: A default theme would serve as our entry-level plan for clients who don’t require a fully customized PleaseFix instance.
With our refactoring process on pause, we rolled up our sleeves to design and develop a new theme as if it were a client request. From our PleaseFix marketing style guide, we built a new Figma library in a matter of days, created the theme and updated the tokens in Storybook before publishing it in a QA environment.
Although some slight visual corrections were necessary, we achieved a significant milestone by slashing the development time from two months to just a few days. More refactored components would eventually make this process even smoother and more efficient. Clearly, we were on the right track. 🎉
Design 🤝 devs
With a project involving multi-brand stakes such as PleaseFix, having a product designer specialized in design systems (👋 Lizbeth) was essential to our production process, especially with a complete refactoring of our libraries.
Our themes now in better shape, we expanded the team by hiring a second product designer to work on feature creation and improvement (👋 Léna).
After the conception phase, which includes research, wireframing and mockups, our component creation and refactoring design process follows a structured workflow:
- Technical analysis workshop: The product designer(s) review(s) the mockups with the developers to determine how each component fits into our design system structure. They discuss which existing components should be used or updated and, if necessary, plan the creation and naming of new ones. They then present to the product owner(s) to create JIRA tickets, flag upcoming challenges and update the roadmap if necessary.
- Figma — Default theme: The product designer creates or updates the components and colour tokens (documentation and Figma styles) in the default theme component library and updates the mockups.
- Storybook — Default theme: A UI developer works on the Storybook implementation. If necessary, workshops are scheduled with the designer to ensure components are identical in Figma and Storybook.
- Figma — Other themes: With the default theme complete 🎉, the colour tokens in the other libraries are created or updated. Figma plugins, such as Design System Organizer and Token Master, can make the task more efficient.
- Storybook — Other themes: If the colour values of some component-specific tokens change from the default theme, our UI developer updates them.
- QA design: The product designer conducts a final design QA feedback session in Storybook and in the product (on a QA environment).
In addition to this workflow, we have a weekly check-in meeting where everyone shares their current design system-related work and gets feedback from peers.
What’s next?
As we continue to refine our design process, we have identified three areas of improvement to further enhance our design system:
- Continuous refactoring: Although we have made significant progress in transitioning from Sketch to Figma, certain components are still missing. To address this, we plan to add them gradually on new features as needed. According to our current roadmap, all or most of them will be completed by next year.
- Variables in Figma: For years, designers working with design systems have been asking Figma for support of design tokens. This feature has finally arrived with Figma’s variables and we are currently switching our styles into variables. It currently supports most token types, except for typography, which will come in the second iteration later this year.
- Automation: Lizbeth, our talented product designer, has developed a plugin that streamlines her daily workflow by reducing the need for copy-pasting. By relying more on automation, she can save time on repetitive tasks to maintain our custom themes.
Conclusion
Creating a multi-brand design system from scratch taught us how complex this topic can be. Although we still face many challenges, our current workflow enables us to effectively adapt our components to each game’s visual guidelines.
Collaboration is essential in product teams like ours, where everyone must be willing to help each other when needed. Thanks to our own design system workshops and processes, the relationship between designers and developers is significantly stronger. Additionally, our product owner have a clearer picture of our design system challenges, allowing them to plan design system tasks with greater accuracy.
Switching to Figma and beginning to refactor our components was the right decision. We set out to complete an entire design system within a few months; experience taught us the futility of that objective: A design system is never truly finished and is in constant evolution.
With a single designer specialized in design system components, it’s essential to have high yet realistic expectations, be proud of the work accomplished and avoid burnout from striving to produce the same level of polished results that larger companies are capable of. That said, we think we come pretty close. 😉
