Building a Visual Design System
by Kenny Chua, Lead UI Engineer at Macquarie Group
Part One — Why we created a Design System
Almost a year ago, we noticed some visual inconsistencies across our flagship secure sites.
This includes Macquarie Online Banking which enables our Personal Banking clients to view and manage their everyday banking, Macquarie Business Banking which provide tools to our Business Banking customers to grow their businesses and Wealth Advisers which help advisers provide an effective service to their clients.
While small, it was leading to some friction for the customer experience, so we embarked on our Design System journey, and I’m proud to share some of our wins and learns from this process.
Benefit #1 — Consistency
Right off the bat, we saw the obvious benefit of adopting a design system — consistency.
We could now ensure that basic building blocks were now consistent across our multiple sites. An example of some of these items include:
- Our colour palette
- Responsive grid
- Font type, size and weight
- Iconography
- Buttons
- Input fields.
It allowed us to achieve more consistency within the same site by highlighting that there were differences in elements within the same site.
As an example, there were over 10 variations of a button when we actually only needed four.
Similarly, there were more variations of header styles than were needed, leading to unnecessary confusion.
Benefit #2 — Efficiency
When we started adopting the Design System, we noticed we were getting better outcomes while simultaneously being more efficient.
A rough comparison showed that a feature ended up taking almost three times less time and effort compared to an equivalent feature completed prior to the Design System.
This was the result of several factors, including:
- Shared cost in updating, maintaining and bug-fixing these building blocks, compared to previously where this effort was repeated multiple times.
- Guard rails established in the Design System (eg colours and button sizes) allowed low-value conversations around the right shade of a colour to drop away, and allowed the conversation to shift to higher-value topics such as the customer experience and journey while using a feature.
- Designers, Developers and Product Owners all sharing the same context and speaking the same language — no more misunderstanding and technical jargon, a button means the same thing to all stakeholders involved!
Benefit #3 — Quality
Since we now share common building blocks, we are able to remove duplicate effort and pool our effort on making truly excellent building blocks.
The time freed up from this allowed us to ensure that the building blocks cater for cross browser, cross device and cross platform support concerns while also factoring in support for touch interactions.
We are also able to ensure a very high percentage of test coverage to guarantee the expected behaviours in these highly-reused sections of code.
Most of all, the benefit here is that we end up with building blocks with great developer usability and excellent customer usability.
One such example is a button with a feedback mechanism while maintaining a contrast ratio for good visual accessibility. When put side-by-side against a plain button, one can appreciate how these small considerations make for a much nicer experience.
Another example is with a menu navigation system that allows some affordance during navigation so that a user can make selections easily with a mouse without needing to have robotic precision.
Interested in hearing more? Follow the Macquarie Engineering Blog on Medium for Part 2 where we discuss the ‘How’ aspect of implementing our Design System.
