Why you need a UI Kit

UI Kit is a set of user interface elements that designers and developers need to simplify their work and create a unified product design for users. It allows you to quickly and efficiently create complex interfaces.


The easiest way to assemble the main UI Kit is to identify the interface elements on the main screens and place them in a separate place so that all subsequent screens are created from ready-made components. 


Typically, a basic UI Kit includes:


  • All interface elements (buttons, input fields, list items) in different states;
  • Color palette of styles for the normal state of elements, as well as the state when pressed, in focus, and colors for inactive elements;
  • Text styles: headings, body text, links, footnotes, notes, etc .;
  • Icons set
  • Illustrations to understand the overall style of the brand graphics

Uniform style

The UI Kit will help you unify colors, sizes, fonts and behavior of elements. The product will consist of elements in the same design language, users will quickly get used to uniformity, remember familiar interfaces to make the product stand out from others.


Accelerating new design development


With a detailed UI Kit, it will be easier for developers to create new features. They don't have to re-program new screens if the interface is made up of off-the-shelf components. Product development becomes flexible and the product easily scalable.


Large scale team access to design


Modern tools inside Sketch allow you to create a UI Kit in a separate file that you can reference when developing and creating a new design. This makes it easy to maintain, update and version the UI Kit without affecting other parts of the product. New team members get on with their tasks faster if they have access to a well-written design guideline that describes all elements and their behavior. Managers and developers will be able to create new systems even without the help of a designer, without wasting the rest of the team's time.

How to organize a UI Kit

Uniform rules


To make it easier for designers and developers to communicate with each other, we need standards and general rules for the names of colors and components. To designate components, use the names from the guidelines of the platform for which the product is created. For example, iOS uses the Tab Bars element to navigate, and Google calls it Bottom navigation bars. Observe the same terminology and do not get confused.

Organizing a UI Kit with Sketch

Library


Sketch has gone a long way in component creation. You can work on the UI Kit in a separate file from the main product and use it as a library. This will simplify collaboration and allow you to use one UI Kit for multiple projects at once.


Styles


Use styles to organize the palette, appearance of elements and fonts. Developers can easily get confused about 50 shades of gray if the designer doesn't keep track of how colors are used in layouts.


To make the palette flexible, colors should be named meaningfully. Avoid names that reflect hue ("Red", "White", "Black"). If the overall design of the product changes, for example, the Blue color links will be Violet, these color names will become irrelevant. In addition, if you design a dark theme, the colors will be inverted and such names will lead to confusion.


The name of a color should depend on its purpose (Success, Action, Error), the interface elements that use it (Background, Text, Link, Button) or its state (Default, Hover, Disabled). Thus, the color can be named, for example, "Button: Hover" or "Text Paragraph: Disabed". Then, when you redesign the product, the organization of your UI Kit will remain unchanged.


You can read more about creating a color palette.


To organize text styles, consider what type of content is used on screens, how many headings and styles you need for other texts. You need to minimize the number of styles and combine similar ones. Also note that Sketch treats text alignment as part of the style, so you'll have to create separate styles for "Label_align_right" and "Label_align_left".


Symbols


You should definitely use symbols for buttons, input fields, checkboxes and other commonly used elements. For interactive elements, add each symbol for each state.


For example, a regular input field, which consists of a rectangle, text inside, a caption outside, an icon next to it, or a link, at first glance does not look difficult to add to the UI Kit. A sufficient set of states would be:



  • Enabled: Empty state by default: The field is available for entering text, instead of text inside - a gray placeholder.
  • Hover: The box is highlighted on mouse hover, usually a simple change to the stroke color.
  • Focused: A cursor appears in the field to enter text.
  • Focused Filled: A state in which a field has focus but already contains text.
  • Filled: The field is filled in and out of focus, and the placeholder is replaced with the entered text.
  • Disabled states: They also differ slightly depending on whether the field was filled in or empty.
  • Error: Don't forget about the states where the interface should report a user error.


A similar set of states will be for the button:

  • Enabled
  • Hover
  • Pressed
  • Loading
  • Disabled


Don’t forget that there can be several types of buttons: main, additional, a button with an icon and text, no text, a button without a stroke, large and small.


Make the symbol areas for icons the same size so that they do not change the size of adjacent elements when replaced. For a complete design, put together two sets - icons with fill and stroke. Don’t forget about the names of the icons that the developers will use. Icons should have common names if they are of the same size ("24x24px"), such as ("Filled", "Outline"), or combined by meaning ("Actions", "Brands", "File Types").


Symbols are the perfect tool for organizing these many interfaces. For flexible customization of complex components, nest some symbols inside others (for example, buttons with an embedded icon symbol or a form consisting of ready-made fields). It's easier to render each element once, add it to the UI Kit and then use it in all projects.


Hierarchy


As the UI Kit evolves, the number of buttons, icons, colors and text styles will only grow. It's important to organize your component hierarchy wisely to make life easier for developers and other designers on the team. In addition to understandable names, created according to pre-agreed rules, sort the symbols into folders using the "Button / button-name" naming system. The "/" symbol will create the desired folder in the tree. Another way is to use the new component display mode in Sketch. It will automatically sort them based on type (symbols, text styles, layer styles, colors) and on the name in the hierarchy.

What's next

UI kit support


The Ui Kit is a living, ever-changing and updating document that will never be finished. You should not forget about it, and as the product develops, constantly edit elements, delete unused ones and add new ones.


Minimize colors and styles, organize standards, and maintain a UI Kit. Add all the colors that you enter in the layout to styles and update them only through Sketch styles. If you need to introduce a new color for experiment, create a style called Experimental so that when you replace it in the future, colors in layouts do not duplicate and colors outside the UI Kit do not remain in layouts.


Development into a design system


The next step is to turn the UI Kit into a design system with examples of component layout, ready-made templates and a detailed description of the design principles and interface behavior. We wrote about this in earlier article.