Design system in focus/part I

Why create a design system? People like to find everything of their interest in one place.

This is the first part of the design system series. In this piece, Ana Masnikosa, Product Designer at Studio Direction, explains how a design system depends on the tool used to assemble it, its structure and how the depth of the design system varies.

Design systems can be very small and simple, or very intricate and maintained by a bunch of people. Creating one is always cost-effective, the scale and its depth is what makes a difference in terms of use. What problems can be solved with a design system; lack of visual consistency, faster iterations, cluttered files, conflicting design elements, communication between teams, or all of the above and more.  

I had the opportunity to work on really small design systems, but also setting up really large ones. I’ve also done it through all sorts of Figma updates, this sometimes meant changing a thought that conceived the design system in the first place and adapting to the new system. This also means that you are a part of a system of the tool you are using. System in service of creating a system.

What can a design system solve and how can it make your life miserable?

The use of design systems significantly increases the efficiency of the design and development teams while also maintaining the design consistency throughout the digital product. At the same time, this is a dynamically updated design document and therefore should be adaptable to change, always expanding, and accessible to everyone working on the project. Design systems also point out rules of conduct between colors, components and other elements of design so the whole process is efficient and scalable. On the other hand, design system can be rigid, difficult to iterate, and it can work against the team. When it comes to large scale systems, it is not unusual for them to hinder progress. Sometimes it is too expensive to change a system when it has already been implemented throughout the product. Other times, if the design system is practically bulletproof, it’s frustrating how many iterations you have to make just to change an article card, or try another layout. When I think about it, there is no try, you either make a change or you don’t.

Creating a design system is always worthwhile, even if it’s so small that it contains a text field and a primary button, or just color variables. I haven’t been in a situation where that wasn’t useful in the long run.

So when in doubt, always create a design system, no matter the scale.

History in the making

I am a product designer who designed its first website in Photoshop. So, obviously when Figma arrived it was like a breath of fresh air. Finally we had something created precisely for UI/UX and product design. This also means that our knowledge of Figma, and its possibilities had to be learned while Figma also developed further its product.

A few years back, I was developing a design system for a year already and realized that Figma pushed an update changing the logic of how components work together and in file. Obviously, I was crushed. I had to change almost the whole system because it wouldn’t be of much use in the future if I leave it as is. I suppose that’s not a bad thing even though it was really stressful. I guess Figma had to find its way as well, and it really has improved now.

When I started the project in question, I was the only designer, and I actually started it in Sketch. At some point, my holiday vacation started, and Vlada decided to transfer everything to Figma. That was back in 2021. I mean, I must admit I wasn’t happy, but that was the right call. Soon after that, the project developed further, as well as its design system. The logic back then was to have one base component, and that one is set in stone. From the base component, a new default component is built and its variants. When something is changed you do it on the default component, rarely on the base component. It’s like one more layer of insurance for making everything consistent and easily editable.

Soon after, library files came to order. For large products, especially the one I was developing, this was really a game changer. Like I said, as Figma grew, so did our files, and options for improvement design and organization-vise.

Design system structure

At the very beginning of a design system, I start by giving the file itself more structure. This way, I have already done some organization inside it, and know what I need to do. It’s like getting familiar with the file, even though it is mostly empty. Page organization makes it much more accessible to a larger audience (project owners, managers, developers etc.) This is important especially when one product has a myriad of files. In this case designing a comprehensive thumbnail with the right information can be a visual shortcut for finding the file you need. We usually put the logo of the company we are working with, name of the file, visual mark whether it is a regular file, or a library, designated designer, what the file contains (UI/UX, components…), and status (ongoing, done etc.).

The structure highly depends on the product in question. Figma also provides adding variables like color, typography and layer styles. Even so, it is necessary to document values and design decisions made throughout the process of designing. This is important because the design system should be comprehensive and readable to everyone, not just the design team. Every file should have at least a styles page with documentation, components page, and a UI page.

Component documentation is the most important part of the file. Every component should have a laid out structure with spacing, sizing, variants, states and rules for behavior on different resolutions and devices. Variables inside Figma are used for consistency, and they come in handy in Dev Mode.

This kind of approach is tool based.

This means that if, in the future, we choose a tool with different features and organization, the structure and workflow would probably be totally different from this one. Our files are constructed around the rules Figma set.  

Atomic approach is what would probably remain. Every design system consists of building blocks. They are organized based on levels of complexity. Atomic means these building blocks are also made of smaller parts. We start building with color, shapes, typography and effects, these values are atoms. When values are assigned to buttons, input fields, radio buttons, in one word components, they make the molecules. Components aka molecules are organized in organisms like complex cards or different types of navigation. Organisms make patterns such as contact forms, pages and patterns make the so-called greyscale of the design or wireframe. Patterns in full color and with replaced placeholders form a final design.

In large and complex systems applicable over multiple digital products before atoms come tokens. Tokens are the smallest part of a design system. They are used to connect design and development in a way that changes are much easier to conduct. Tokens are values like HEX code for color, and by updating one token, the change scales down to every single part of the design.

In practice we try to introduce a design system as soon as possible. We start by defining the colors, radii, border width, sizing and spacing variables. Components are added as the design progresses. Modularity is what counts, so it is crucial having that in mind while designing the system. After the base atoms and molecules are defined, every other pattern or page is done by stacking those smaller elements together. In this way new pages are instantly part of the design system.
For products with several UI across several platforms some percent of the components will have to be designed separately. Primary buttons, alphanumerical fields and similar, would probably rest the same, with some differences in height or width. Patterns such as cards, infographics, tables, or any product specific components usually behave differently on different resolutions, so some modifications are needed. It all depends on the scale of the project, these components can be in one library, or can have separate files.

Sometimes I forget that a design system must be usable and people friendly, not just packed with information, components, and my idea of great file architecture. The main feature of the design system is its dynamic nature and adaptability to changes. Digital products are about human behaviour, this applies to a design system as well. A design system is as strong as its level of usability.

‍