Case study
Investec Design System
Fin tech, banking, web, app, design tokens, colour system, component library, accessibility, documentation, ui roll-out
Investec is an established international bank and wealth management business with headquaters in the UK and South Africa. Along with a team of UI, UX and developers, we spent a year creating a design system for Investec’s web and app platforms. In addition, we improved the companies overall product experience and brand. From a high level view we:
Updated the brand
Created foundation libraries and guides to assist in correctly applying brand
Build component libraries in line with existing and new features and products
Onboard in-house designers and engineers on using the system
What I did
Component libraries
Created components for web and app, built to latest best practices
Design tokens
Together, a fellow designer and I created a token system that catered for typography, colour, spacing, radius and effects
Documentation
Created foundation and component documentation
Colour system
Built a thorough and predictable colour system with Adobe’s Leonardo colour tool. The system is for light and dark themes and is built around accessibilty
Accessibility
Alongside a UX designer, we created a set of accessibility guidelines that formed part of our component building process
Onboarding
Helped other designers understand and use the design system
Section 1
Foundations
One of the initial reasons for introducing the design system was the misalignment between UK and SA products. Investec wanted bring the two together and solidify the brand between the two.
A design system serves as the bedrock of consistent and coherent visual and interactive experiences across a product or organization. The foundations of a design system typically include, a comprehensive color palette, typography guidelines, and well-defined spacing and layout standards. These elements are further stored in the form of design tokens. Having this foundation ensures that designers and developers can work in synergy, promoting efficiency, scalability, and brand consistency.
Colour system
My first task on the project was to create a colour system that incorporated the Investec brand and would be used as a foundation to build all components. I took a thorough approach, developing a logical system that had intentional target contrast ratios built according to colour roles and accessibility considerations.
I began by auditing all the existing colours and identified some key areas for improvement:
Update the palette to be predictable and have consistent contrast ratios across each colour set
Include additional colours steps to cater for a dark theme
Choose target contrast ratios to ensure components would be accessible
Build an accessibilty colour grid to assist designers in visualising accessible colour combinations
Colour contrast consistency
Using Adobe’s Leonardo colour tool, I built out a predictable colour palette. Each step in a hue range has a consistent contrast ratio across all hues. For example, navy-100, stone-100 and sky-100 all have a nearly similar contrast ratio. This enables us to easily predict the contrast of colour steps and assists in accessibility. Note that some colours, yellow for example, may appear to have a higher contrast than others at certain steps. This is because some colours naturally have higher luminance.
Contrast grid
With the consistent colours in place, we could then make a contrast grid, measuring foreground colours against background colours. Knowing the the contrast ratios are the same no matter what the hue, means we know this contrast grid works for each colour.
Colour step roles/use cases
The target contrast ratios were purposely selected to enable a useable range of colours to meet the demand of an interface, with all their variety and states. Each step in the colour scale has at least 1 use case. Later these decisions were ‘codified’ in the form of design tokens.
Design tokens
Crafting a Scalable Token Taxonomy
Embarking on a collaborative endeavor with a fellow designer from Investec, our aim was to make a scalable but understandable token taxonomy. This undertaking, and colours in particular, proved to be one of the most difficult challenges within the project, prompting us to delve into numerous iterations of the schema. When we thought we had arrived at the “perfect” naming conventions, we would soon learn that something didn’t quiet gel. However, through perseverance we eventually crafted a comprehensible and scalable solution that epitomized our vision. The tokens catered for:
Typography
Spacing
Radius
Colour
Shadows
For colour tokens we wanted to use alias-level (semantic) tokens as much as possible and limit component-level tokens, knowing that the amount of tokens might become unwieldy if we relied upon component tokens too much. However, naming semantic level tokens is difficult. Semantic level tokens need to be named in a way in which generalises their use, so they can be broadly applied, but nevertheless named in a way that users understand how to apply them. Hence, you need to show their intended use as precisely as possible (so they’re not miss-applied) but in a general way - it’s almost paradoxical. In the end, and after many, many trials, we managed to achieve this goal and added in dark theme support to boot.
Undertaking the Investec token naming project has been a highly valuable experience that has greatly enhanced my skills in creating subsequent naming taxonomies.
Section 2
Components
Component library
Audit and plan
To ensure a smoother process and define our scope, we began with a comprehensive product and component audit to understand the tasks and requirements ahead. We examined the stylistic elements and components already in use by Investec whilst looking for elements that were in use and whether they should be included. Moreover, as we proceeded with the design system creation, we embarked on the development of new features and experiences, many of which necessitated the creation of components and patterns that were non-existent before.
An audit helps make sense of where you are and where you need to go. It helps:
Identify inconsistencies, and discover those parts which do not follow brand guidelines.
Paves the way for better UX
Helps identify components that you need, and plan for that you don’t yet have
Let’s you roughly understand the scope of work ahead
After the audit we set in a plan to begin the building process. We created a set of tasks each with a ticket to track progress. Each contributor was assigned a set of components to build in accordance with a component checklist. Through daily stand-ups, we tracked components progress with the PMs from design through to dev.
Accessibility
At the onset, it was clear to us that accessibility was not just a desire, but a necessity. With this in mind, a dedicated UX member and I collaborated to develop comprehensive guidelines. We outlined the principles that would govern our component creation, ensuring they were inclusive and user-friendly.
Once the guidelines were in place, we presented them to the rest of the team, soliciting their input and feedback. The collective wisdom of our colleagues further enriched our guidelines, making them even more robust and effective.
These guidelines became an indispensable tool for our team. Whenever we faced challenges or needed guidance during component creation, we turned to this resource. Its clarity and comprehensiveness allowed us to maintain consistency and accessibility across our work. In the end, our commitment to accessibility was embedded in every aspect of our component development.
Component Building
After our component audit and planning process, we moved into the building phase. Each morning we would meet to discuss our previous days work. It provided a chance for us to provide feedback and insights into each others work. In addition, the design system team would collaborate with the UX and engineering department to validate our design decisions and to make sure that what we were designing actually met the needs of everyone. Additionally, but on a more adhoc basis, we would then show our work with a wider audience including heads of design, project managers to get additional feedback. Through this we realised that we needed to strike a balance between team collaboration and moving forward at a reasonable pace. On the one hand, too much input and opinions could drastically impede the pace. On the other hand, involving others was critical in socialising the design system and encouraging adoption. As such we would limit the amount of ‘noodling’ on each component to a reasonable amount. Any additional concerns would need to be added to a backlog and addressed later. Going forward, I have learned that if there are desired changes, to not only take that feeback and implement it, but actually encourage the person to partake in the updating process itself alongside us.
By the end of the initial phase, we had created global component libraries for both web and app, and additional supplementary libraries for particular products features and patterns. The system is now in a maintenance phase and continues to be developed and updated.
Example: Notifications
The notification component provides a good example of a component designed to meet a specific set of needs. While we could possibly have updated a list component to work for notifications, we thought it would best to create a specific notifications component that we could edit down-the line and wouldn’t affect other components, had we taken the approach of using a global component.
User needs / Component requirements
After auditing the current notification types that we would need to cater for, we also wanted to update the notification centre to be more user-centric. After some research we arrived at some specific criteria we wanted our notifications to have:
Status:
To indicate that a notification is new
Indicate a notification is read
Indicate a notification is unread
Each of these above types need interaction states
Timestamp: so the user understands how recent the notification is
Actionable:
Some notifications require actions. Allowing the action to be started on the notification will reduce the number of clicks.
Group Task
Ability to select multiple notifications and mark as read
Consistent experience
Alignment between web and app
Category (future state)
Requires a category Icon for added visual indication of the category the notification relates to
Filtering
Filter components, for example, by type or time
Notification component
The result was the component below. We were able to take all the requirements and build a relatively visually simple component that catered for all it’s needs.
Notification status
We didn’t want to stray too far from existing mental models users might have about notifications. As such we had a look at how, read, unread and new styles are shown on other existing products, whether it’s an email client or message centre.
We arrived at these 3 variants with different styling application.
Web and app consistency
Stress test
We put the component through a stress test to ensure it would be able to perform as required in all scenarios. Sometimes this required the notification type to be editied, rather than the component. The UX team provided essential support on this given their in-depth knowledge of notifications and the existing and future needs.
Refactoring components
During the component building process, Figma released an update which made component building more streamlined by introducing props. While this didn’t impact the engineers dramatically, it would affect the designers. Updating all our components would impact our deadlines, but in the interest of the integrity of the system and always trying to keep up with best practices, we decided to make the change and update the components. It did have the added bonus of reducing the variants and file size. We socialised the new updates and everyone adopted them without much trouble.
Documentation
In order to cater to an extensive range of users and facilitate collaboration across cross-functional teams, we developed comprehensive documentation. By prioritizing clarity, our aim was to empower consumers with an in-depth understanding of every aspect of the system.
By offering users a comprehensive understanding of the design system, we enabled users from different disciplines to align their efforts effectively. This cohesion promotes efficient teamwork and eliminates potential bottlenecks.
Conclusion
As time went by, our design system proved to be a triumph. It was (somewhat) smoothly adopted throughout the organization, covering multiple products and regions, and brought many expected benefits. Faster building and improved efficiency, consistent standards, and better teamwork and collaboration were just some of its strengths.
This project has been a significant learning experience for me. It served as a valuable basis for my design system skills. The lessons I learned have only become stronger and more diverse on the following 2 systems I worked on after this project.