The Design System That Alteos Built
Hello there! Today I want to share the experience of using a system approach in Alteos design — we will talk about design systems, how they help, how we build and maintain ours, plus a little about code.
My name is Pavel Laptev, I’m a lead designer at Alteos. As a modern insurance startup, we provide a fully digital approach to our clients and for all our products. We work in a B2B2C business model and develop many products.
That’s why for me, as a designer, it was very important to keep everything in order from the very beginning; to make strong connections between all our products, to have a complete overview.
Thinking ahead. Even if you work in a small startup, you need a good start to be able to scale your design, to make it flexible.
Spending more time on initial planning, reflecting about how to connect products and scale them will surely pay off in the future, way more than starting to build a UI immediately.
Here are four main reasons why you need to use a design system:
- You need a design system if you have multiple products. Interconnection between products is very important because this coherence will make an image for the company.
- Scalability is very important, especially if you have many products. Scalability can solve such questions as: “what if there will be more products? what if we need to expand a component with new features?”
- Flexibility is different from scalability. Flexibility helps us change anything in the design: not to scale, but to edit something across all company’s products. Flexibility is more about the readiness of the system to accept operational changes from different divisions.
- The single source of truth is one of the most important points for any system. It should be the only one to get used and cover everything. Also, everyone should know about it.
Tools
Figma. Having already worked with Figma, I knew this tool would fit all our needs.
First of all, because the design system was to be implemented from scratch and I had to manage feedback from many people. I needed an easy-to-use, online tool — which could also provide a simple method to make changes in a component-driven approach.
Figma is perfect for this: it offers online collaborative features, comment modes, and sharable libraries.
Figma API. Another very helpful feature is the ability to export anything from Figma via API. I wrote a script to export and convert design tokens from Figma, so that developers can skip the manual handling of changes. You can read more about it here:
System Structure
You should aim to make a design system with a solid foundation and strong connections between components. With this approach, you can change the global perception and adjust accents.
A solid foundation, in our system, for example, consists of three parts:
Design rules, tokens, and the main UI Kit.
Everything else can be produced based on the foundation — additional UI kits, pages, and flows; related products for social media; advertisement.
Design Tokens
In the context of design tokens, we often refer to the general parts that make the whole style — so we can also call them style tokens.
The set of tokens is flexible: it could include only two entities, like color palettes and typography; or be more specific, including even ‘border-with’ tokens and so on. It depends on the frequency of property use.
Our design tokens include so far seven groups, each covering a set of properties, which can be divided by usage or values.
For instance, grid tokens are divided by usage — mobile, tablet, desktop — while spacer tokens are divided by values 2px, 4px, 8px, etc..
- Grids. We use 3 main and 2 additional grids for mobile breakpoint.
- Spacers. All elements were built with certain sizes — the amount of these sizes are limited to be able to track and maintain consistency.
- Palettes. Two main, changeable palettes and four supportive, fixed palettes.
- Fonts. Two font faces — one for headings and one for body text and small font sizes.
- Radii. Three radii variables depending on the element size and purpose.
- Shadows. The same as for radii tokens.
- Transitions. Three transition variables depending on purpose and element size.
Tokens help us to keep our design and code clean and consistent — we always know where and what we need to use.
CSS and SCSS variables
As mentioned, we generate our design tokens via Figma API. But since we provide an individual approach for each B2B client, they must be able to adjust the design as they want with certain limitations. Hence, we divide design tokens into 2 categories — fixed and changeable.
$scss-variable. We store fixed tokens as SCSS variables; they are internal ones — only we can change them, in order to prevent broken layouts and designs. Token groups like spacers, transitions, shadows, supportive pellets, and grids are fixed. There are no cases when we will need to change them, else it will cause a lot of design issues!
--css-variable. Another category is CSS variables, such as two main palettes (general and accent) and typography. We store these tokens as CSS variables because it’s easier to operate and configure them. In most cases, it is enough to have only color variables to customize products for a particular client.
Design Rules
Unlike design tokens, design rules describe abstract entities — like general behavior rules. Design is more than just an image: there’s a lot of thoughtful work behind it, tiny details — the length of the line, line-heights, widow lines, how to write content, marketing recommendations, and mostly in DO/DON’T representation.
UI is important, but it’s nothing without content — good content is a part of good UX.
UI Kits
As mentioned above, Alteos UI is a general one. All base components are stored here, as well as unified components — this is a kit without context.
All extra kits like Landing Page and Selling Flow use the Alteos UI Kit. There are additional, derivative UI kits with components that are dedicated to a particular usage — these have a context.
We also have the Illustration Kit which covers all decoration needs — pattern tiles, small and large illustrations.
Basically, all pages are only compositions of components, wrapped in a certain layout (which is also a component in React). This means that we can very easily pull any changes from our UI Kits and keep flows updated.
Workflow
Most of our files have the same page structure, which provides an understandable and familiar pattern of the workflow:
✅ Ready: Only approved pages. Only a designer can edit. All requests only through comments mode.
🚧 Work In Progress: A sandbox field where we do all concepts and changes.
🗄 Archive: Frames and ideas that are rejected or outdated.
The introduction
Of course behind the scenes there’s much more going on, than we can cover here — we barely scratched the surface. However, we covered the first level and gave an understanding of the general settings.
To conclude, I want to share the Alteos Introduction guide. This guide is our yellow road — it helps new people in the company understand how the system works, how we organize the design tasks, and the processes in the company.
Thank you for reading. I hope you enjoyed it!
Follow Alteos Tech for more insights from other roles in the company. 🚀
