Often, when reviewing the work of newcomers in design, we have to say the same things: You have problems with hierarchy; you need more systematicity; you have problems with the grid; you have problems with margin. And some of these problems can be solved very simply by introducing simple rules that our design will obey and introducing UI Kit.
Kit in the natural habitat
First, let's answer the question of what it is. Let's ask this question in Google and get the answer:
"User Interface Kit — is a complete set of elements and components required to assemble a large homogeneous product. It includes various buttons, icons, data entry fields, etc. and allows you to maintain product recognition and user trust." (and so on and so forth...)
Great, but I don't think it's enough, and I don't agree that it's only needed for big projects. We still have too much room for maneuver - buying parts from a car we still won't have a car. That's why I understand UI Kit a bit more broadly than is commonly understood. And today I invite you to dive into this confusing world of squares and circles, and get acquainted with three metaphorical whales that a designer should tame, in my humble opinion.
Rules
The most difficult, yet seemingly easy, is something that is almost never done, but is always needed - the rules. Indentations, rounding, positioning of elements, all this must meet the same rules. And it is very important not to look like Sheldon in one of the memes, to write down these rules.
Yes and the designer who will take over the project after you will thank you))))))
As for the rules of objects location, it's more about grids and alignment of objects relative to each other, here it is unlikely that something will be unclear and it's enough just to enter the project without comments, but the rest...
For example, when we introduce the indentation system, we write:
Margin 4px. Used in inputs as an internal margin at the top and bottom.
Margin 8px. Used between enumerated items, in pagination, internal margin in a card.
Margin 12px…
And so on and so forth. These rules can be changed to adapt to tablets (less desirable) and mobiles (often necessary), but within the same screen size the rules must be strictly adhered to. Exceptions are of course possible, but they should not shape the entire design.
In the same way, we prescribe rules for rounding, and it is very desirable to do the same for typography and coloring. Speaking of which...
Styles
In fact, we have already approached the concepts that everyone puts in the concept of UI whale when talking about it. Styles are everything that we can set directly in Figma.
Fonts and all typography basically, from the H1 header to the little error caption under the input.
Colors and shades - white, black, accent colors, and yes all the other 50 shades of gray. All this should not be in your head, but written down in styles. By the way, shadows can also be set in styles.
This approach, to create styles for everything, will not get confused, do not multiply the lettering and colors, and stick to a verified style.
Components
I think I'm not lying if I say that components are what Figma is used for. For those who don't know, let me explain. This is an entity in design, whose child copies inherit the properties of the parent, and change if you change the parent.
It's a little complicated, isn't it? Let's make it simple. If you turn a square component into a circle, its copies will also become circles. Therefore, all repeated objects outside the draft stage must be components. For example: buttons, inputs, product cards, lists, toggles, header, footer and much more.
You can use a simple rule - if something in the design is repeated 2 or more times, then you need to create a component for it.
Summary
Everything described above is a basic UI Kit. All of this is desirable to do even for an ordinary web site, and it will only grow as the complexity of the project increases. It's time to talk about the structure of layouts and how to build it correctly so as not to go crazy, but that's for another time. Understanding the things I wrote about will minimize errors, add logic and visual rhythm to the project, and set at least a basic hierarchy in your design.
Bonus
As a bonus, I'll talk about the Design System. In its essence, it is a logical development, if you will, even evolution of UI whale into something more cumbersome, complex and beyond design, in case fronts create their own "components". Such libraries are usually used when creating complex products, when working in teams in companies. It is not uncommon that a separate team of designers is responsible for the creation and development of the design system. Yes, development. In fact, it becomes a separate product within such companies, which is used by designers.
I participated in the creation of such a child for a number of completely different products at once, as part of my work in one of the companies. And it was interesting. Challenging. But very interesting.)