It’s time for a spring clean! Lexoo has experienced intense growth over the last few years and we’ve outgrown our existing user interfaces (UIs). In this series, we’ll explain why we decided to build a design system, how we built it and how we’ll be rolling it out across our site.
Why we decided to create the Lexoo Design System
Our online platform was originally designed to help individuals, startups and SMEs find and hire the best lawyers. We’ve had tremendous success over the last 18 months, so much so that we’ve now outgrown our existing experience:
Expanding audience: we’ve attracted bigger and more established enterprise clients such as Stripe, Vodafone, Monzo, and WorldRemit, and we now find ourselves designing for a different group of customers.
Increasing number of features: we’ve recently shipped a number of new features, including an interim placements product, a KYC repository and a new payments processing flow. Without a standardised approach to design, we found ourselves duplicating design work and our UI was becoming increasingly fragmented.
Doubling our headcount: the product and development teams have doubled in size over the last year. With every new hire comes new, fantastic ideas on how to improve our UI. This has created further inconsistencies and increased maintenance costs across the website.
We felt that it was time to strengthen our foundations and pay back some technical and design debts before we continue to add more to our offering.
What is a design system?
A design system is a set of patterns and principles for design and code that define the overall design of a product. A design system enables products to be created in a scalable and repeatable way. The patterns are the modular, reusable building blocks that we use to create an interface, e.g. typography, buttons, banners and colours. The principles are the instruction manual for using those patterns, particularly within a team.
Some of our favourite design systems come from Atlassian, Mailchimp and MongoDB.
Slowing down to speed up
Lexoo designs, builds, and ships products through “Missions” – ad hoc, autonomous, cross-functional teams assembled to deliver product efficiently. We set up an initial Mission to build the actual design system; subsequent Missions were assembled to code up the components in isolation and then to roll out the design changes across the Lexoo site.
We enlisted team members across Product, Development and Marketing to help us on this Mission. Without in-house designers, we decided to hire a contract designer to give us a hand in actually creating the Lexoo Design System consisting of a component library and a UI layout system.
The design system will allow:
Improved user experience – with an official design language tailored to our core users, they will be able to experience a coherent Lexoo brand and customer experience.
Greater consistency – users will be able to experience the same quality and consistency of design across all UIs, which is especially important given the number of new products we plan to roll out.
Greater efficiency – product managers can focus on solving problems rather than getting bogged down in pixel-level UI design; engineers can create usable, beautiful UI without the need to continuously write new code. By front-loading the creative work to the building of the design system, we would give ourselves the building blocks to make solid interfaces by default.
While building the design system, we made the decision that this was not meant to be rebrand or a re-design – that would have been a much bigger project, and we wanted to remain agile and look for small changes with the biggest impact. The refresh was instead based on Lexoo’s existing core brand guidelines and it was important to us that we maintained continuity in users’ overall product experience.
Before we started working with a contract designer, we audited the existing styles and components across our site to understand the current state of our design and development ecosystem. We used Figma to map out every single page of the Lexoo platform. Laying the flows and interfaces side by side allowed us to pinpoint where and how the experiences were breaking and where we could tighten the design.
Based on this, we created a shopping list of must-have components, from key features such as navigation bars to minor elements such as radio buttons.
An inventory of our site
We also completed a colours inventory and discovered that we had over 150 colour variables on our site!
A sample of the colours used across our website
Armed with our findings and list of requirements, the next step was to work with our contract designer to actually design the components.
We’ll cover how we did this in the next post!