Creation of Design System for Group of Related Projects

In this story we will tell you how we decided to build up a single UI/UX system for different apps of one of our clients. You will see what principles and technologies we implied into it. 
 
 We hope our experience will be really interesting for UI/UX designers, frontend developers, and brand managers — those who have come across such tasks at work.

When there is a need for ecosystem: our experience

For many years, we have implemented numerous IT projects different by complexity and usage (public/internal). At the moment, there are 30 such projects. In the process of development we have done a lot of changes in design including total update of the corporate colors. In fact, most of design and development were done spontaneously which means that each project was done from scratch.

You can easily see the impact of such work for us — developers:

You always work with heterogeneous and constantly changing design for new modules.

· If the corporate style is changed, you have to change the design of everything. What is more realistic — you will have the whole zoo around you (priorities, resources, budget — you will be fully supplied to be busy)

· Designers always keep an eye on frontend developers. And in their turn, frontend developers write lots of repeating code (this is another big story to be told later)

As for the client, such inconsistency is also not very helpful:

· Users are not comfortable with the app. When one and the same person should use several systems with inconsistent UI where controllers behave a bit differently, some frictions appear characterizing UI as good or bad. Such frictions are taken quite seriously by users, as they do not allow working smoothly.
 
 As soon as we are speaking now about business systems, users have to use them. And of course, the efficiency of work drops down.

· In this case, the quality of communication is not really high. The companies strictly follow the corporate style for all the carriers. The detailed brand book describes all non-digital carriers — from the business cards to souvenir mugs in corporate style. However, it happens so that digital carriers are not well specified which “helps” to break the brand.

Language of design. Stages of development

As soon as we realized all hopelessness of the current way of development, it occurred to us that we need a system. This is how we were building it up step by step.

Step 1. Identification of the basic principles

  1. Unity

Language of design is a system. It should work as a system based on the same principles from the beginning to the end.

· Single layout and location of the key controllers.

· Single notations for the typical data: money, statuses, texts, date, time, periods…

· Single accents which prompt correct workflow in any app of the system.

2. Simplicity and utility
 
 Our language of design serves for business communication. It is not a genre for decoration purposes at all. That is why:

· All interfaces are cleared from all beautiful, but totally useless items.

· We use only a required minimum of icons. As we learned, icons do not simplify app usage, but make users play “guess what?” game.

We could not refuse using them at all. The thing is we try to use only the needed ones and not like messages, but mostly like illustrations for the page information. The icons are the same for all the systems and their list is specified in UI KIT.

3. Proactivity
 
 We increase user efficiency to get required results, because UI shows users all the right ways.

· We use intuitively clear associations. 
 
 Not everybody remembers what is CVC code, but all of know about the “three-digits-on-the-bank-card”. That’s why on the online payment pages we usually see the image of a bank card. 
 In our case with the airline employees we imposed the data displaying according to the standards of airline tickets.

· We also regard human perception of colors when choosing them for our solutions.
 For example, the red color is usually used by accountants to show expenses. So, when we create a financial system, we “paint” the money for them the way they are used to. This is something that should be done with every group of potential users.

4. Flexibility
 
 Any system reminds an organism which can adapt to new situations with no damage.

· It supports the development of the functionality.

· It supports different platforms: web, mobile.

· It leaves some space for creativity.
It is possible to make up special design for a holiday or promotion campaign.

Step 2. Implementation of UI Kit

All the described above principles can be practically implemented in the frame of the single UI Kit. For typing of all the interface items, we analyzed all created projects for this client:

· Outlined all types of functionality and required design elements,

· Brought them all into sync with the current corporate style of the client, which will be actual in the future several years. On the basis of this information we implemented UI Kit.

Factually, UI Kit is a continuation of the brand book of the client, but only for the digital carriers. It has all the typical pages, items, controllers and their possible states, and set of the required icons. It solves the same tasks as a typical brand book: increases brand recognition, create a unique brand image digitally.

The further projects are based on this catalogue. Designers need only to think about unique for this particular project items. Thus, a designer now spends more time for project development, work on usability, and not for styling issues.

From design to development

The further project development mostly fall on the shoulders of the software developers. Designers play a role of product owners and managers of the technology cover done by frontend developers. As soon as the article is devoted to design, we will mark some steps, but the full technical story will be told in a separate article.

Step 3. Technology package

A good bonus we get with the design ecosystem is a possibility to reuse the code saving huge amount of time for integration issues.
 
 Of course you have to keep in mind that integration does not always go simply. UI Kit is not something made of stone and its update will continue even after the end systems are implemented. Sometimes, it happens even after they go to the support phase from the phase of active development. That’s a reason why it is important to let software developers know about UI Kit updates; understand what is changed and how complicated it is to integrate the updates into the project; estimate and plan the integration work.
 Apart from the design changes, there can be some errors in css representing the implemented design. These errors should be possible to make and fix in one and the same place and not in every system.
 
 The solution of this issue is quite simple — creating a library which implements all concepts of the design. Visually it looks like a bootstrap theme packed into private npm-package. Software developers install it on the bootstrap and get the needed design.

Step 4. Creation of “documentation”

Instead of the long user guides we created a demo-app showing all the capabilities of the library and some examples of layout needed for the implementation of this or that item. The clients can “touch and taste” any design idea before it goes to end apps, and, if it is required, introduce additional ideas.

Step 5. Providing the Versioning

…total and painless. We will tell another story about it giving a chance to frontend developers to speak.

Results of the design part of the project:

· We learned how to create own “language of design” adapted for the specifics of the IT services ecosystem.

· We turned the “zoo” to single ecosystem by experience of IT services of a particular client. We developed a single UX concept which lets minimize the “frictions” when working with our systems.

· We created UI Kit which allows the clients to support and develop all the systems in single style saving time for our designers.

· We implemented distribution of the library updates in the form of npm-package which allows fixing the issues and providing updates painlessly and separately for each project.

· We fully illustrated the work of the library with the help of the demo-app which let the developers act without designers and web designers.

To be continued…

Next post will be devoted to the details of frontend part of the solution. Just keep in touch.

Find more enterprise cases at eastbanctech.ru