Building a Design System for a Cross-platform Product

The main purpose of building a design system is a high-quality and timely-released product, where any changes take as little time as possible. Design should promote business interests and be flexible enough to allow drastic changes. However, there are several problems that can reduce the efficiency of work on the product.

Designers are usually not technical specialists, meaning that their approach to process building tends to be more artistic. This results in poorly-structured projects, random layers naming, and other inconveniences. In such a project a person who opens it for the first time will quickly get lost (a situation that often occurs when working in a team).

What is the root of this problem? It might be because in the middle of the creative process we forget about the structure. Besides, just take a look at Adobe Illustrator – it brings up layers (not to mention the names of objects and groups) at the very last minute. This is true for other software as well. In the end, we usually get something like this:

Not very helpful, is it?

Design system. Is it really necessary?

Design system is a more technical and structured approach to working on a product. Imagine developing a product and only seeing its architecture in the last stages. Awful, isn’t it? No scalability, complicated support, and constant error correction. The only person to not get confused navigating in such a project is the person that developed it. This renders teamwork nigh impossible.

It’s not enough to explain the project in words or by example, as this is a one-off help. For designers to really build the product, not merely draw the application, they must have some sort of technical background. They will then be able to use this knowledge during their work on the project. You may think that I am trying to turn a dedicated expert into a multi-tool here. However, this is not the case.

The thing is, to know coding and to code yourself are different matters. Even if you’re not required to do it yourself, you should know it. Basics of programming languages and technologies should not be optional for a designer. A more technical approach to working with your project brings several advantages:

• Deep understanding of the process. Knowing the system that you are implementing helps make quick and correct decisions. Thus, when solving the task, you have several options to choose from, can anticipate how long it will take to implement such a feature and how difficult this will be within the framework of said system. You can improve the performance of your department and the development speed of your product;
• Accelerated teamwork. A unified design system is a must for teamwork. This includes a standard readable structure in all projects and automatic layouts updates in case of revisions;
• Common language with the developers. “This is impossible”, they said. Now you can understand that everything is possible, it is only a matter of time and feasibility. Unless, of course, this concerns the system’s limitations that we, designers, will have already known before the implementation;
• Independence. You can become self-sufficient if you desire to. This is a matter of necessity, but the very fact that it’s possible to make a product from scratch by your own hand can be quite motivating;
• Professional bonus. Deeper understanding of your profession and, consequently, a new evolutionary step in your career. This grants you a competitive advantage and increases the salary.

How to create a design system based on the scale of your product?

Design is a dynamic environment. Setting the necessary style and set of objects from the start helps maintain the necessary consistency. So, having defined the concept of design and already having a specific layout, bring it to a structured form. Don’t forget to name all elements deliberately, so that from the name itself it is immediately clear what kind of element it is and in what condition.

Yes, long names can look frightening, but this will make them comprehensible for your colleagues.

A for Architecture

Note that there are elements that might be reused later in the project. Let’s take a closer look at them.

Does it make sense to constantly copy a group of elements for the Button object? Especially considering that this element can have different states? Or that a teammate may be using this button with another shadow?

PS: If you work in a team, it is recommended to create a shared symbol library file. This way the team will always use the up-to-date set of elements. You can do this in Sketch app, though other alternatives also offer shared library symbols.

Thus, by sorting all the elements and designating those that will be used repeatedly in the project, we get this mini-symbol library:

The list of elements that are used frequently in the project

To illustrate, we’ll take our cross-platform e-Signature app KeepSolid Sign. It is available for 5 platforms, thus, elements such as Button, Input, etc. must remain within the operating system style. However, there are also elements that do not belong to any specific system, and must be the same everywhere – for example, the look of annotation. Such elements should be identical on all platforms, so they are placed in a separate global library.

Universal look of annotations for all platforms

Having invested some time at the start, you can come up with a style guide (see below). From now on, you will simply have to follow it, without concerning if you’ve applied the right properties to an object.

Primary Style Guides for KeepSolid Sign Windows version

Once we’re done with the Windows version of KeepSolid Sign, we can begin implementing the design for a different platform, such as Web browsers. The user flow of the app should be the same, so we can take an existing library of elements as a basis and, by performing a small redesign within the framework of the new platform, prepare layouts for the Web version quickly enough.

KeepSolid Sign Windows version

KeepSolid Sign Web version

As you can see, the application looks almost identical on different platforms and fits into the styles of each one. The only exceptions are the system elements of the platforms.

As a result, by constructing such a design system at the initial stage of development, we quickly developed the design of the KeepSolid Sign application for Web platforms, preserving the familiar user flow.

So, what’s next? Using this approach, we create a new look for the app on macOS, where user behavior is the same as on other platforms. If users change the platforms, we don’t need to re-educate them how to use the app.

The only issue, I would like to emphasize that user behavior on mobile platforms like iOS or Android is entirely different. For touch-oriented interfaces and relatively small screens, the user flow should be simplified (and, possibly, accelerated), but at the same time offering all the possibilities of the app. But this is a completely different story :)

What workflow advantages does a design system bring?

• Any changes can be made in the shortest possible time. Design becomes very flexible and quickly responds to business requirements;
• Layouts updating is automatic, you only have to check the results;
• All style guides can be found in a separate file. Developers are guaranteed to be grateful;
• Implementing the design of the application for a new platform goes much faster;
• Version control using Git (optional);
• Self-discipline at work.

All this thanks to structuring the project properly!

The aspects mentioned in our example are only a part of a large design system. There are even more vital elements that should also be described in the product, without focusing on a specific operating system or platform. A well-developed design system must also accommodate brand, colors, fonts, usage scenarios, library of elements and components. In this way, when developing a product in a team, you can quickly explain to your colleagues how the product should function and what rules they should obey.

Creating, implementing, and scaling such a design system is not an easy task. But if you work through this stage at the very start, it will be much easier and faster to expand the functionality of your applications later. The product’s design will be able to meet the requirements of business and the market faster, and teamwork will become much more effective! A preconstructed architecture at the initial stage of work on the product is the main goal of implementing a design system.

I hope this approach to the process construction will be useful to you and you will readily take it on board. After all, it’s better to spend a little more time at the initial stage and lay the foundation for the project’s development than to rework a huge chunk of work afterward.

The post Building a Design System for a Cross-platform Product appeared first on Speckyboy Web Design Magazine.