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.
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.
“Yuting did a fantastic job working on our system UI, design rulebook, print and website over a period of 3 years. She combines great attention to detail, logic and layout, as well as lateral thinking to how design impacts the overall UX. A very solid all-rounder who I would recommend.” — James Weatherill, CEO at Arbor Education
