Multi-platform Design System components in Figma
The fragmentation of screen sizes in phones, tablets, and desktops, can create immense challenges for Product Designers and UI Engineers, especially in small and medium size companies seeking to develop scalable design solutions. While a design system is the most obvious answer to such challenges, how you create and segment components can be the main factor between success and failure.
Mollie’s design system team was created to solve this problem, but instead of taking a project-based approach, we decided to operate as a product team. So we framed the challenge with a “How might we” question:
“How might we allow fast exploration and implementation of high-quality user interfaces?”
This question helped us to think differently. The biggest realization was that we could create better components if we focused on the user context instead of isolated platforms (web, iOS, and Android). This approach forced us to think about the best possible experience based on the screen size and input methods. Therefore, we defined the scope of our components based on these properties, so all components would need to provide support and features based on the following:
- Screen size: Large or Small.
- Input method: Mouse, keyboard or touch.
The scope of this article will be the Figma part of our design system. But everything presented ahead also has a counterpart on Storybook for developers.
One library for all contexts
When it comes to components, we choose to have one library in Figma. The context of where a component can be used is embedded in its properties. The main advantage of this approach is that designers can immediately know where a component should or should not be used. All our components fall under one of these four categories:
- Large & Small screen
- Large screen or Small screen
- Large screen only
- Small screen only
As much as possible, we aim to have components that look and behave the same across different screen sizes. But depending on navigation patterns and input methods, this is not always possible. Here is a more detailed overview of each of our component types.
1. Large & Small screen
This is the most common type of component we have. The size, padding, and styles are kept the same across screen sizes and input methods. Buttons, Tabs, Badges, and many others fall under this category.
The main challenge in this type of component is that we have to predict all possible combinations of variants and states. This means that we need to provide all the interactive states expected based on the input method, such as mouse (hover), keyboard (keyboard focus) and touch (pressed).
2. Large screen or Small screen
These components present visual differentiation between large and small screens, so we offer a property allowing designers to change between these variants. In some cases, the placement of content changes, while in others, the padding and font sizes differ. We only create these variants when we are sure that the tradeoffs of having a different experience outweigh the cost of maintaining them.
3. Large screen only
These components are rare and usually related to our navigation patterns, such as the Navbar and Menu components on large screens. So we need to provide a dedicated component to support these patterns in a specific screen size. We don’t merge variants in this case because they differ too much in paddings, margins, typography and states
4. Small screen only
This one is the counterpart of the kind above, where the small screen variant offers a different navigation pattern. One example of such a component on smaller screens is the Tabbar.
Returning to the original “how might we” question, I can confidently say this approach was crucial to solving our challenge. The most significant impact was the ability to have scalable design decisions. Where a decision we make, for example, for small screen sizes, can be leveraged across our apps on different platforms. We still have a young design system, but that is rapidly evolving into a mature product.
Bonus: Our metric for building components
Adoption is not our primary metric, at least for now. Since we just went over a redesign, 100% of the platform is built using our design system. Instead, we focus on the availability of components and tokens. As we find ways to improve these elements, we flag items as “Known issue” when identifying an opportunity/bug. Which then becomes a task for our design system team.
Our scenario is relatively unique. Even though we have a small team with four Product Designers (we are hiring!) and 20+ UI Engineers, we have a dedicated design system team. An investment that allows us to work on this type of initiative.
Caio Manzotti is a Senior Product Designer for Design Systems at Mollie, based in Amsterdam.
