LendInvest Design System
Building and maintaining a new design system for use across all design and development projects to drive consistency and efficiency across the brand.
My Role(s):
Design System Designer, Hybrid Product designer/Product Manager
Responsibilities:
Strategising with stakeholders | Collaboration with Designers, Product Managers and Developers | User research including interviews, understanding the problem and gathering insights | Component auditing | Design system management, contribution and upkeep | Component design and documentation | Design QA | Design system governance
🙍🏻♂️ Business problem
A slow product delivery to market
The design team at LendInvest was created around 5 years ago and has always been fairly small, and split across multiple projects. The first Product Designer in the design team set up the design system alone, until new designers were brought in to grow the team. As a result, the design system - named 'LDS' (LendInvest Design System) - has always been in a state of development and improvement. As the design team became more established and the legacy design system began to show its age, the need for an updated and consistent design system became more apparent.
Alongside my other responsibilities, I became a champion for the LDS, deciding on colours, type scales, a spacing system, designing and documenting components along with developing a new process with my team, and a roadmap for planning new components and deciding which legacy components to deprecate.
8px scale
One of the results of the legacy design system was that the spacing scales didn't follow any kind of pattern. This created odd paddings and margins, inconsistent font sizes and design patterns that were difficult to convey to new designers in the team. Shortly after joining the company, I set about researching an 8pt scale system, as is seen in many design systems today. This meant setting up spacing scales that increased in numbers divisible by 8 (and on a smaller scale, by 4). The new spacing scale became 4px, 8px, 16px, 24px, 32px, 48px and 64px.
We also wanted the spacing scale to be modular. This meant that if there was a size needed that wasn't on our scale, we could combine two existing sizes together to create a new one. However, we soon realised that we were using 12px and 20px in our spacings, and the developers had to keep combining two spacers together. We decided to add 12px and 20px to our spacing scale as a recognised spacer.
Designs now appear slicker, and grouped items have better relationships as a result of the new scaling system. This also makes it easier for developers to build our designs with fewer opportunities for ambiguity when those pesky sub-pixels slip through the net and into our designs!
Icons
Our design system uses the Material UI icon set. However, it was obvious from the outset that we didn't need access to every icon in the set. Further, in its infancy, the design team relied heavily on the webfont version of icons, rather than SVGs or components. This posed a problem as the team matured in that they were difficult to implement in our designs, not very scalable and inaccurate when trying to group elements together.
When joining the company, I quickly set out to implement a working design system, which involved reducing 950+ icons down to around 60 core icons. The design system now has quick access to the most used icons, which has sped up our designs, ensured consistency across projects and has also helped the development team understand our intentions and designs better through the inclusion of bounding areas around each icon.
Components
One of the core strengths of building the LDS in Figma is the use of Auto-layout and more recently, variants. These two powerful features have allowed us to create multiple component states that provide loads of flexibility, without the clutter and nuisance of having to sift through hundreds of component states to find the one we need.
Now, with the toggle of a switch, or the selection of a dropdown option, we can design for all states that a user might experience when using our tools, all while being able to dynamically adapt our components to fit the context in which they're being used in. Pages grow and shrink as content is added or removed, buttons grow to fit the text inside, fields can be made mandatory or optional and icons can be switched out on the fly.
It's like magic!
Designing for accessibility
One of the questions the design team always asks is, "Is it accessible?". Designing for as many people has long been a concern for us and ensuring our components are accessible has been just one of the many challenges we've had to overcome.
Aiming for a minimum score of 4.5 on the Web Content Accessibility Guidelines (WCAG), I helped to decide on the colour palette the business should use throughout internal tools, our website and even in internal documents, such as presentations, and datasets.
Documentation
Documenting our design system not only provides instructions on how components should look and behave, it also provides context, instructions, dos and don'ts, usability notes and concerns and accessibility comments to designers and developers alike. The aim of documenting each component is that anyone should be able to pick up a component and have as few doubts as possible on how and when it should be used, without the input from a designer or developer.