Getting into design systems

Hey Frederick,

1. This might help because there are a lot of things that you could think of, even things that are not directly design related:
   Build a Design System Collection - Playbook

2. Start with creating overall styles, e.g. the color palette, typography (headlines, paragraph text), spacing (recurring values, maybe spacer components), grid / layout styles, shadows / elevation styles and iconography (icon set).
   As your project grows you’ll always improve the basic styles. Don’t expect to nail all of that on first try before you start creating components.

Components you’ll need almost in every project:
Buttons, Links, Logo, Header, Footer, Cards, Images (pro tip: define image variants recurring aspect ratios), Input, Select, Checkbox, Radio Button, Switch Toggles etc.

3. Not sure… maybe work with different files that are connected libraries? Tokens sound like a good solution though.

4. Its quite work intensive if you create a lot of instances you have to maintain. You could work out your basic component structures, variants and component properties (such as states, sizes, icon yes/no, icon position etc.) and create new components based on that and adapt them to your brand style. But keep in mind they no longer have any interconnection and are separate components. So if you want to change things you’ll have to change multiple components instead of just one.

5. Maybe this helps: https://help.figma.com/hc/en-us/articles/360040449513-Add-icons-to-text-layers-with-icon-fonts
   However I recommend using icons as vector images / svg and using Icon components.
   Due to bugs its quite tricky though because there are certain things to keep in mind.
   To keep it short: if you want interactive color changes in prototypes with icons (e.g. link hover) every icon you use there has to follow these rules:
   same exact layer structure, same layer naming (except component name), don’t mix fill and stroke icons (outline strokes to have fills only).

Many public design systems exist that you can study and learn from. Some even have public Figma files:

Those are good resources as well:
https://www.figma.com/community/file/867135839870202854
https://www.figma.com/community/file/912837788133317724
https://www.figma.com/community/file/831698976089873405

In addition to @dennsi’s suggestions, I wanted to offer these answers for consideration:

What do I have to think of before I start creating the design system?

I suggest thinking about your design system like a product tailor made to support you/your design team’s work. What problems or pain points will your “product” (design system) solve? If you’re a small team, or team of one, keep your ambitions realistic. The design systems that are publicly available for us to browse or featured in conference talks are supported by massive companies that can staff big, dedicated teams. Their goals will naturally be different from a solo practitioner’s goals.

If your goal is “have more consistent color usage in consuming products’ UI”, your design system goals might involve investing time in creating a strong token and style system.

If your goal is “reduce time spent and confusion during dev handoff”, your design system goals might be less about building things in Figma and more about maturing your processes. This could involve some Figma work (maybe you need annotation components, especially if your devs don’t have dev mode), and standardizing how you name pages and organize work on the canvas.

What are the best components to start with, based on atomic design?

Dan Mall and Nathan Curtis each have good, but conflicting advice on this. If a world where Dan is helping a team like Uber answer the question “what component should we build first?” he would suggest a “map component.” Nathan agrees with Dan’s sentiment, but not the example of the “map component.” Skip ahead to 53:00 in this talk about design system health hosted by zeroheight.

From what I can tell from these two thought leader’s guidance, you want to strike a balance between:

1. Impact to consumers (what component would save them time and reduce stress)
2. Realistic for you, the component librarian, to build at a high quality without losing steam and motivation.

How you use those criteria to narrow things down largely depends on where you work, the product your design system supports, the business goals, and your own capabilities and bandwidth.

What are best solution for multi brands? Token or using master components?

If by “multi brands” you mean “I want to have brands as a theme I can apply to UI”, then 100% use tokens if you can! Even if that’s not in the cards today, it’s good to know that there is a high likelihood you will need tokens to support this kind of feature later down the line when your design system matures. But if that’s not possible today, yeah, master components! Again, I’m making some assumptions about what you mean for “multi brands.”

Working with master components, because Ive got 4 brands, Is it right, that I create the master component, copy the child from this component, change color, font from it and create out of this component a new component for brand?

I discourage anyone from taking this approach. It is very close to base components, which was once a popular idea for making the management of componentry easier, but it often comes at the expense of the consumer experience. Negative outcomes include overrides getting lost on swap, file memory is at risk of getting blown out, and the layer architecture can be unnavigable for larger elements (eg global navigation).

How to add and use a icon font in Figma?

Like Dennsi, I also recommend using vector paths instead of an icon font. Come to think of it, I should write about why on my blog… I’ll try to remember to come back here and edit this reply once I’ve organized my thoughts. But if you’re adamant on using an icon font in Figma, I believe this documentation on adding custom fonts to your Figma account will cover what you need to know.