Why products are getting worse after a time? You have a great team, top programmers, talented designers, tracking metrics, email full of CV from lords, but a product is getting worse from release to release. The thing is, that tasks are solving without enough quantity of limits for designers. A clear Design System can help to provide a solution.
A Design System is a top level in the hierarchy of design structuring, it is separate full-fledged product combining Pattern library, Ulkit, people, etc. A business needs it, not users. The closest example is Apple Human Interface Guidelines which consists of: UI components, navigation systems and all this has a form of a library on ObjectiveC and has a documentation to the code. Such a Design System Apple provides to designers and developers.
We need to understand that trying use only Ulkit is the same as to sprinkle Lego constructor all over the floor. We have a lot of solid components, but don’t have any guarantees that results will be the same as expected. Design System should limit not only components but a structure too. Just like a good logotype which is not only an icon, but a visual system which is suit to different contexts, your Design System should be as strict as flexible to solve all tasks.
Not everyone understands the difference between Ulkit and Design System. Ulkit lets to keep elements regular, for this sketch symbols are enough, these are atoms of Atomic Design approach. Design System makes molecules from atoms. Atomic Design means that a small collection of elements should be seen like a single component (contact form is a component- molecule, atoms are buttons, text fields)
Let us ones more to look at the Apple’s experience. They gave a freedom to developers. You can take ActionSheet component but you can’t even change a color in it. Can’t help saying about Google’s Material Design which is realized with the help of Design Support Library and it belongs to high-level guidelines. Here we need to take components as they are, while Apple offers to be more flexible and write own components.
Usually Design Systems of most vendors include: a set of basic elements, colors, pattern and size of a type, components, model screen, patterns’ behavior and a description of a behavior of all the above on different platforms. I add some more points in my projects:
- A diagram of components’ interaction.
- A common language for components naming. All the team from designers to a tester should understand this language. If we decide to use CamelCase, everyone should use it.
- Common resources for projection and design.
- The conformity in Sketch and Front end should be 1 to 1. For that you can use systems of versions control (Git, github, SVN, Mercurial) and Abstract or use a couple programming by designer and developer.
The last point causes difficulties most of all, even among huge vendors. For making confusion less we can use a system of versioning (SemVer). Let us take for example r 2.3.1 — here the first number means major version, the second minor and the third means a patch. Patches include small changes of components, in minor versions we add new conditions of components, in major we include changes of style or new meaningful functions. Both developers and designers should synchronize their components on the level of minor/major changes.
So we have Ulkit and Design System, but where are guidelines? Because Google provides guidelines and not Ulkit. Guidelines are a part of a Design System.
Guidelines could be of three types — inside, outside and usual for real users. Each of these types has a description of UI-components and principals which design-team is using. Principles include a description of an interface availability level for different target groups, results of researches and testing, methodologies, processes, ethics, problem statements, a manner of communication with user.
Each type of guideline can be open/dynamic, it is when possible to enter data from outside (Social Media) it also can be close/static, in that case a system doesn’t change (Landing pages). Static systems do not imply a development, while dynamic are evolving all the time. The analogy of open inner guideline from branding world is generative identic. It is an example when logotype is formed from different setting entities.
So, let’s get an order in the head.
Design System consists of: element> component> connection> structure> element.
● Element is the smallest part (atom);
● Component is an independent part of a system (contact form);
● Connection is the rules of matching (a button + text fields = contact form);
● Structure is the system of disposition;
● Aim is tasks’ description of buttons and fields in the system.
A value of a whole system is higher than a value of separate elements. Ulkit from the internet will help to make a page, but these are bricks for the house, and the house itself is more important than bricks.
We can add:
● A documentation which include — brand description, visual language, communication and location, values, principles.
● Sources which are files of UI-kit and guidelines.
● Components which are better to be ready made fronted elements.
● A brand — the reason why anything is done exactly in this way.
You can write components with the help of Anjular, VUE, Bootstrap, React, it is comfortable. You have guaranteed testing of responsiveness and checking of micro-interactions. There is also components’ checking in different conditions and with different browsers, on different devices with different screen orientation. Ulkit’s collector is helping much.
Now comes story about pain 😱.
«It’s a great article, thanks, but we already have a lot of entities of one and the same in our project, I cannot start from scratch.» — you think like this. Everybody has the same, and solutions of this problem already exist, I’m going to share them with you. First of all, we need to order all the mess.
You can ask a developer team for exporting all the components and choose only which are the most often in use. You can compare these components with the most popular user’s cases. As a result, you can make a conclusion about which components are more important and use them in other places. So you have covered a most part of your UIkit. You should aspire to use minimum components, and use them flexibly.
Also you need to find out which guidelines are more relevant, designer’s or developer’s. As for my experience designers’ components are more relevant. But the developers should have a right for the last word.
The more massive is a Design System, the more often you will meet a concept of «price for changes». To change a step of a grid on 20px at ones is a very difficult task, but you have to get through this sometimes and you need to accept it. A Design System should suit to the change of specification of a product. Don’t be afraid of refactoring of a system.
A positive side effect of a system approach to interfaces will be standardization of processes not only inside design department but also in an interaction with product teams. The united vocabulary will appear, centralized collection of specifications will go better and a testing of a product will become easier.
A Design System between platforms should be friends at the level of basic conceptions, and not at the level of fall out dropdown list and radio button.
The animation in a Design System usually is cut down by common parameters, such as durations, but the animation will stay on the platform’s level it realizes like a platform depending thing.
How to keep?
Often the answer for the source codes keeping will be Sketch/Figma/Illustrator/Photoshop kit. Actualization and keeping of source codes is better to control with the help of Abstract. For team work with the components it is better to use Elements. Or it can be inVision DSM, or even Sketch Libraries.
May be you are using libraries of components in Axure. Such an approach has its difficulties. You have to delete build-in styles of elements within a project. You also need to conform all parameters for Widget Style Manager.
Any guidelines mean work with typography. In Axure you can use Publish -> Generate HTML Files, you add Web Fonts and later on a type will be downloading from the internet.
One more possible way to descript components is Confluence. It is about static pictures, gif, textual description. In general, it is common documentation of a project. You can implement interactive prototypes and projects in Figma with the help of iframe, or insert interactive elements. Don’t you think about implementing on one page at once several iFrame areas of Figma? It will be an original Dashboard, with the help of which an art manager will be able to control all the projects with a single glance.
If guidelines belong to external and live in public repository it will be a good idea to make a private fork for an additional code and a documentation.
Actualization and tracking
Control of versions, files numbering all this is a headache for all Design-leads of industry. It is impossible to track all updates, somebody will forget to add a new button or a color into guidelines, will not give results of testing in time, or realization in different products will not suit to guidelines despite all saying above.
Branding, models, user’s behavior, researches — all these need to be discussed in design chat of a team. A regular revue for synchronization of all members of a department will help to minimalize divergences.
If not consider all stuff above-listed, sooner or later you will come to components which are look as the same but work differently.
For sure your icons live in form of PNG and SVG files. May be in form of sprites or Font File. Do you want to add a new icon in all projects? So, send a hello to developers from all teams. Source codes of all these are kept in AI, Sketch, Zeplin, Figma, and some live only in readymade product. It is a chaos.
The first approach for solving a problem is to collect all icons in Zeplin or in Lingo (this variant is better). You will see immediately different icons for identical actions in different projects and will form united place of truth.
Let all participants of a team write about their achievements, problems, let them summarize all knowledge in to inner Wiki. It will help to keep experience of a resigning officer for the new one, and make business of your employer more defended from losing a knowledge with a quit member. As I’ve said in the beginning business needs a Design System, not users.
What are waiting for us after a Design System? Airbnb works with Design Language. Such an approach let us describe a design at once and get a result on all platforms. Future is exiting, isn’t it?