Design systems — Matthew Ellam

Building a design system

Simplifying our design and build process, through re-use of common components, patterns, documentation - all in one place.

Summary

As the team expanded, designs were project focused which created a mish-mash of experiences, styles and often lead to duplication of work as two people would design the same type of screen
Audited existing libraries, reviewed best in class design systems, re-designed components, created central documentation and signed off with key stakeholders across design and dev
The core sketch design libraries were kept up to date - but due to a lack of ownership the documentation became stale
When I moved into my new role as a design lead - I revisited the design system, setting up processes in place to make it central to th design process and incorporating all areas of design (UX, UI, Copy & Accessibility)

Multiple style guides
Inherited as the banks IT approach changed, plus specific components used for web, mobile and content management platforms
Lack of consistency
As new designers joined - they took different design approaches applying their own understanding of UX to individual projects, with no central reference point
Design and Dev out of sync
The different dev team built new components each time, meaning human error or nuances in behaviour
Siloed Design and build
Each designer and dev team created their journeys from scratch - not aware of other project using similar components and
Lack of ownership
Sign off at a specific project level meant new components designed to meet specific use cases
Restrictive components
Often built once and used once, which meant making whole platform changes very labour intensive and expensive

Approach

Audit
Understanding what components we already had, what was missing and how the existing code was built
Choosing a design tool to store documentation
Created in Invision, as it was our main dev hand over tool and allowed good user access and versioning
Baseline documentation
Starting to document the rules behind each components, when to use what and do’s and don’ts
Designing
Reviewing competitors styles, market leading components and patterns, running the components through user testing to ensure they performed well
Aligning with dev
Creating standard such as naming conventions, states, what’s needed for good handovers and versioning
Building in accessibility
Ensuring accessibility rules incorporated into designs, documentation and code
Workshops and approvals
Gathering key stakeholders feedback and collective agreement on the rules

The initial launch had mixed success

First started with Web and quickly followed up with App
The value of having one was clear when we were referring to it regularly and doing app along side really started to bring our platform identities together
Big help when working with 3rd parties
I worked with Salesforce, Adobe and a low-code supplier (Appzillion) to design and build some screens and it was super easy to share component specs, making those new those journeys inline with our core development teams
However, we largely used the component libraries and not the documents
This brought a level of consistency in UI, but didn’t address
We failed to give a clear owner and build into process
Once set up, the way the team was structured there wasn’t a clear owner. Which meant over time as the team changed, it wasn’t updated or referred to
The artefacts were to far removed from design process
Whilst Invision was used daily - the design system sat if a different section which wasn’t often referred to or easy to find and there was no prompt to review it

When I became the design lead

I took ownership of the design system
Setting up a small team of experienced designers to review what we had, and expanded it further to cover components, patterns and templates
Integrating with copy rules
Copy standards where created and added to the documentation - to give one central reference point between UX,UI, Accessibility and Copy
Aligning with latest approach to IT
A switch in code base meant rebuilding all the components and patterns again, so took the opportunity to realign design system to dev component library and enable themes such as dark mode
Embedded into the design process
Encouraged collective ownership & regular reviews, when new designs were showcased, they need to reference the design system and show what was new. If they wanted to add or change something then it went through a formal process and user testing to validate before a decision was made. The user testing and reasons behind decision where then added to the documentation for auditing and future reference
Created a design system strategy
Previously the design system was a repository but the goal was to make it a valuable asset, as creating new components comes at a cost. The ambition is to refine and align the different libraries and patterns into a single source, reducing complexity

The result

Sped up the design process
Picking up a ‘settings’ template and adjusting it was quicker then starting from scratch
Became a living and evolving ‘system’
The team reviewed the documentation regularly and when needed - challenged it to make it better. We followed the design process to evaluate if the changes proposed were valid, aiming to remove personal opinion from discussion
Ready to benefit from generative AI
With a set of well defined rules, pattern, components and patterns, we have the rule set to feed into AI to help us speed up the design process - when the technology is ready