Maxime
Frere
Principal Designer, Design Systems, SOURCE
Maxime Frere is the Principal Designer at Source, a Product Design & Development agency. In this role, he leads the Design at Scale practice, which aims to help SMBs and international companies industrialize, organize, and elevate their Design capabilities.
Passionate about design, he is actively involved in the design community by teaching Design Language Systems (DLS) in higher education and participating in UX associations and conferences.
With over ten years of experience in the field, Maxime has worked as the Head of Design at BPCE (the 7th largest banking group in Europe) and as a Senior Experience Designer at frog Design.
BNP Paribas
L’Oréal
CMA-CGM
Can you walk us through the current state of the design system you're involved with?
We are currently participating in two Design Language System (DLS) programs.
In the first program, we have just completed the framing and build phases. This has been a challenging process as the DLS covers native, multi-brand, and multi-segment mobile applications. We have managed over 4,000 Design tokens to ensure optimal brand expression across the apps while maintaining the same assets.
Our current challenge is to expand the DLS to new Front-end technologies and encourage its adoption by other brands. We are currently in the process of consolidating the operating model.
For the second program, we are taking a different approach. We are working on a strategic framework that spans several months. The goal is to secure the buy-in of sponsors through a strategy and organizational structure that aligns with our customer's ambitions.
We have conducted assessments on teams and products to analyze the ecosystem, and now we are focused on structuring the launch of the build phase.
How do you usually work with your clients? What is the first step?
Our goal is to provide a solid framework that meets the customer's needs. To achieve this, it is important to understand the customer's operating environment: the product ecosystem and its organization within their company.
While the structure of the DLS can be influenced by the product ecosystem, the success of a DLS is heavily dependent on the organization.
This is why, we can only develop an appropriate strategy by analyzing all the factors that can impact the program.
Moreover, as an agency, we play a consulting role with our clients: We advocate for strong convictions based on our experience, such as treating code as the source of truth, maintaining solution agnosticism, and prioritizing the DLS consumer experience.
How the client responds to these convictions will significantly impact the construction of a DLS, influencing the structure, framework, and governance.
What tools do you use to build and maintain your design system?
Our primary focus revolves around three key aspects: the client's security constraints, the actual value provided, and structural decisions (such as brand expression strategy).
To minimize the risks of heavy dependencies or pricing bottlenecks with some tools, we mainly stick with major market solutions, preferably open-source, when possible.
For instance, we utilize Figma for design assets and its API, Style Dictionary as a parser, and Storybook.
In addition to existing tools, we develop custom plugins, scripts, or APIs tailored to our clients' specific requirements.
This versatile approach can also extend to handling Design Tokens in spreadsheets or documenting everything in Confluence, among other capabilities. It can be reassuring for some clients.
Lastly, we only advocate for third-party solutions when they have a substantial impact. Generally, we make exceptions for one or two tools in the IT landscape but not for multiple ones. It's all about picking our battles and being flexible when needed.
OUR TOOLS:
Figma
Storybook
Style Dictionary
Confluence
Custom documentation
How do you balance the need for consistency with the desire for creative freedom among your designers?
We emphasize that the Design Language System (DLS) should position itself as an enabler for teams, focusing on essential components (atoms and molecules) and providing the appropriate level of flexibility. Our goal is to minimize involvement in patterns or page structuring.
This is achieved through two main principles:
Coherence over standardization
Guidance over governance
The first principle emphasizes empowering teams by focusing on essential components and offering flexibility. We aim to exclude involvement in patterns or page structuring, allowing designers to create various combinations and adapt to their specific needs.
The second principle ensures that the DLS does not replace a design organization. The DLS teams do not conduct component validations, feature reviews, or screen reviews. The DLS is intended to ensure proper component usage without passing judgment on the relevance of the designers' work. It serves as an asset for project designers but is not the central source of design.
However, it's important to acknowledge that the lower the design skills of the teams and the higher the level of siloed work, the more the flexibility of the Design Language System will be reduced.
It is important to be careful when using the DLS, as it can present a significant risk.
How do you stay true to your vision for the design system, even when faced with external pressures or trends?
Throughout my career, I have encountered various situations where the Design Language System (DLS) has been rejected, ranging from outright refusal to the creation of shadow DLS. That's why adoption is crucial for the success of a DLS.
I firmly believe this requires striving for excellence and maintaining a certain level of transparency. It all begins by establishing solid design foundations that are difficult to dispute. We must pay meticulous attention to creating our color palettes, selecting typography, and choosing illustration assets like icons. We should be able to explain and justify every design decision.
This level of rigor should be evident in all design choices for different assets, and we must find ways to communicate this commitment to excellence effectively. With certain clients, each sprint's conclusion during the development phase provides an opportunity to examine a component thoroughly. By revealing the process that led to the final result, we enable future users to comprehend the various constraints that influenced each decision (such as accessibility and maintenance).
It is crucial that, from an objective perspective, this is difficult to dispute. Everyone should be able to understand and perceive that it is logical. Moreover, everyone should recognize that there is a solution, not just a personal opinion, behind each asset. By adopting this approach, subjective arguments have limited space to assert themselves.
We tend to record everything, from meeting notes (and command+f will help you bring back decision context) to online sessions, and we keep keynotes available for everyone. We also link components to a specific part of the keynote and consider it as part of the component documentation. Even the benchmarks or previous iterations are in an archive Figma file.
What does your ongoing collaboration with clients look like?
It is crucial to establish a true partnership and a special relationship in order to successfully carry out such a program. This endeavor requires both design and transformation, not just for the company but also for our clients themselves. Therefore, it is fair to say that without collaboration, the chances of achieving something impactful are slim.
The key for us is to be both thinkers and doers. When we formulate a strategy, we take responsibility for its implementation and ensure that we can overcome challenges even in small-scale operations.
In supporting our clients, we can break down our approach into three phases: Define, Implement, and Transfer.
The Define phase involves the entire process of identifying needs and finding the most suitable solutions. This phase is complex and engaging, often leading to significant decision-making.
During the Implement phase, we take the chosen solution and put it into action, closely monitoring and improving it. This phase requires flexibility to make adjustments between theory and reality. We are heavily involved in steering and tactical follow-up, as well as providing operational support for ramp-ups or specific topics.
The Transfer phase provides an opportunity, if we have effectively supported our client, to hand over the keys to the DLS. However, we often find ourselves in the process of transferring one activity while starting another :).
How do you ensure that your design system evolves with the changing needs of your users and stakeholders?
We approach this aspect from multiple angles:
At the asset level, we prioritize flexibility in components based on the company's strategy, as well as customization via Design Tokens. We also offer a comprehensive set of Design Tokens for visual systems, such as Color Systems. This allows for easy expression of brand identities and ensures smooth transitions for both DLS components and project-specific ones. These changes may be a result of a redesign or improvements based on user testing.
We give special attention to the contribution workflow, recognizing its importance. We aim to minimize the burden on the consumer side, as they have limited time available.
We also emphasize the need for a continuous feedback loop, with a run sized accordingly. This is vital for processing and efficiently handling requests for evolution.
Finally, we strive to integrate the DLS into the culture and workflow of product teams, making it a natural part of their work.
Are you tracking your design system? If you had to choose one metric to measure the success of your design system, what would it be and why?
We monitor Design Systems on various metrics, including usage, coverage rate, satisfaction rate, and team velocity. We use formulas to try and determine the gains or savings achieved.
The main challenge lies in setting up tracking, and the lack of pre-existing tracking makes it difficult to compare before and after situations.
However, if I had to focus on one thing to measure success, it would definitely be the synergy between engineers and designers. This may be specific to the clients or companies I have worked with, but we often see a significant gap between these two disciplines. Contrary to popular belief, this gap rarely originates from engineering.
When we establish code as the source of truth, it brings about significant changes in how both disciplines collaborate. We align our vocabulary, understanding of subjects, and we find that everyone starts seeking solutions instead of hindering progress in any way. Often, we see that this extends beyond the Design Language System (DLS), and methods and processes spread across teams.
This leads to a return on investment (ROI) that far surpasses the initial expectations from adopting DLS assets.
Do you use any kind of automation or AI tools?
We take a tool-agnostic approach to Design Tokens, which means we don't rely on any specific design tool. For example, when working with clients, Design specs consume the Tokens instead of managing them. This approach allows us to automate Token changes effectively, thanks to the Figma API. We can implement token changes in both the code library and the design library.
The Figma API also enables us to automatically export and integrate icons and illustrations into engineering repositories.
When it comes to AI, we closely follow the topic with great attention. With tools like Vercel V0 or Relume, the industrialization of interfaces and UI as a commodity is becoming more apparent. In a Design Language System (DLS), a lot of data is available to feed an AI, including tokens and documentation. We can also leverage these assets on the Figma side.
It's clear that there is currently a rapid acceleration happening, and the results in a few years will be incredible for large groups.
Where do you see design systems heading in the next few years?
I believe that headless and shared Design Systems will soon become a reality. Brad Frost recently emphasized the need for this in one of his articles.
I also think that AI will play an increasingly prominent role, initially as a co-pilot for Designers and Engineers. I resonate with the vision presented by Diagram (acquired by Figma).
In my opinion, Design Language Systems (DLS) will be recognized as essential infrastructures and treated as such by companies.
What's one thing you wish more people understood about design systems?
Building a Design Language System should also be seen as an opportunity for design excellence. While many people prioritize the aspect of 'industrialization', it's important to remember that if we standardize mediocrity, we will only achieve mediocrity.
Every decision related to the core of the DLS has a significant impact on the quality of interfaces, especially when dealing with complex interfaces. Therefore, in my opinion, we should not underestimate the time needed to define the foundations and standards.
In your opinion, what are the most overrated and underrated aspects of design systems?
To me, the role of design tools is the most overrated aspect of DLS.
Some people believe that they should be the source of truth, but compared to code, these tools have limited capabilities.
As Dan Mall has once said, "The more time people spend in Figma, the less time they are actually making software." Your design files, in the end, are just documentation. Users don’t perform any tasks in a Figma prototype.
On the other hand, if there is something underrated, it would be the ability of DLS to transform organizations with low design maturity.
If you could have a coffee chat with any person from the design (system) space, who would it be and why?
Choosing just one is so difficult! But Shaun Bent would be my pick, because I align with so many of the decisions made by the Spotify Team and I’d love to deep dive into everything they’ve done.
Coffee with Shaun Bent
What's one piece of advice that you would like people to remember from this interview?
If you have the opportunity to work on a Design Language System, seize it! I believe it's a valuable experience on so many levels. It won't limit you to a specific specialization but rather allow you to explore the essential skills of any designer. It will also enhance your ability to step back and identify connections and dependencies between different products, and even ecosystems.
What's your favorite thing to do when you are not in design systems?
I recently developed a strong interest in Muay Thai, and now I practice it regularly. I've always felt hesitant about combat sports, especially after experiencing a neck injury. But at 35 years old, I finally walked through the doors of a gym, and I haven't stopped going back ever since.
