arbor_logo.jpg
 

BUILDING A DESIGN SYSTEM

Nov.2014 – mar.2017
 

I was the first in-house designer to join Arbor in November 2014, and before then was no clear design process in place. Very soon it became apparent to me that the product lacked a great deal of design consistency, as the different parts of the system were built by different people, each one with his/her personal style. The lack of consistency in a product not only confuses the users, but also it slows down the development process as well as making it difficult to onboard any new developers/designers. Since then, I took on the responsibility to help putting a process in place to ensure design consistency, and to ultimately enable the scaling of design and development for this enterprise product. 

The Challenges

Initially, the task was to produce a Style Guide for the enterprise software MIS. Through a steep learning curve and working with the Front End team, we realised we needed proper design rules and a better process in order for the Style Guide to actually be useful. Since we couldn't keep track of the changes across design and development in a rigorous way, the Style Guide was constantly getting out of date with the live product, which lead to further inconsistency. The challenge was to come up with a systematic way to ensure consistency and improve efficiency along the way. 

MIS Rulebook version 1.1 - it is called a rulebook as opposed to a UI Style Guide, because it contains guidelines about the design, implementation and when to use what components (UI rules).

 

the SOLUTION

We decided to build a design system. This means to define top-down rules behind design decisions, guided by our predefined design principles. Everyone in the product team, from Product Managers to developers, must be aware of these principles. The product is built by a large team of people who inevitably have different ideas on how to solve the same problem. This created an incoherent experience across the platform. For example, choosing between using a ‘tab’ and a ‘sub-menu’, when both components seem to achieve the same outcome (i.e. creating 'children' pages which are logically connected to the same 'parent' page). Or when to use a ‘pop-up’ (modal) against a ‘slide-over’? And when to use an orange button as opposed to green one? The Style Guide contains visual specifications about a series of UI Element and Components, but it must also contain design rules. Components are the building blocks of product pages, and design rules make sure that they are used in a consistent way, including the dos and don'ts.

As part of building a design system, we had to refactor most of the front-end architecture, to align it with the new design paradigm. We started by looking at all the inconsistencies in the UI elements, such as font, colours, buttons and icons. Literally 50 shades of grey existed in different parts of the system, because every time a new component was implemented new colours were being added. We reduced hundreds of colours down to a set of 7 base colours, extended by 4 tints for each colour. We tried to give meaning to the naming of each tint: for example, for 'Green' we had 'Lightest Green', 'Light Green', 'Dark Green' and 'Darkest Green'. This way of organising colour becomes very useful when it comes to defining components' colours in a systematic way. For example, to define the colours of a 'System Notification' component (see below), which has green, orange, red and blue, I now just need to say the border & icon colour is the 'Base' colour, and the background will be the 'Lightest' of its base colour. Not only is this just one line of code, the consistency is absolutely kept here - because when/if someone decides to add a new colour to the system notification, same colour rule will apply. Same logic applies to all the other UI components, such as grids (which contains coloured cells) and . The result is that we achieved a much better visual coherence and development efficiency.

UI Colours

System Notification

Buttons

 

Page Layouts

Everyone in the product team needs to understand the basic structure of a page and know the page layouts available, their purpose and restrictions. For example, the purpose of a 'widget column' is for additional actions and only widget components are allowed in this column. We made sure that these UI rules are written as part of the implementation guidelines and enforced in the code so that only pages that comply to the rules can go to production.