Increasing product consistency and team velocity using a Design System
As we are finishing the first phase of our Design System, we thought it would be a good time to share some learnings and talk about the pitfalls we met.
Qonto grew at a fast pace over the last four years, and so did our Tech team, as well as the number of new features we ship every quarter.
A year ago, we decided with the Product and Design teams that we needed to share a common language to develop new features. We indeed wanted to focus on extending our feature set instead of wasting time on basic components. We also faced certain product inconsistencies.
To address these issues, we started working on an innovative Design System.
While kickstarting the project, we kept the following idea in mind: sharing code across applications can be a big gain but can also end up slowing everyone down.
Before the Design System
Here at Qonto, we work in cross-functional teams, also known as CFTs — each CFT owning a part of the Qonto product. This means that the Frontend team is spread across different CFTs, for instance the Card CFT or the Transfer CFT.
If we take a step back and imagine Qonto as a car manufacturer. This means each CFT is responsible for a dedicated car model, aiming to bring the best car possible to the end-customer and focusing on creating the best wheels, windows, and dashboard for this specific car.
But if all CFTs are siloed, they don’t communicate and focus solely on creating the same components over and over again, without synchronizing with other CFTs to learn from them. This in turn ends up in a lack of consistency in our application.
In the past, we were trying to build the best features possible while sometimes forgetting to focus on building the best banking application: consistent and user-friendly.
As a result, this complexified the way our developers worked. By forcing them to produce additional work on existing components and adding lead time to feature development, we created frustration within the team
As you can see in the example below, all the close buttons are different, as these were created for different features, and therefore within different CFTs.
Another good example of this inconsistency is the modal screens in our application. They all look all different, with various buttons, spacing, and display of information.
How we can ship more value faster
We like to ask ourselves how we can improve the way we work.
In the car manufacturer example, you don’t want to waste your time creating car components that already exist. Instead, you could share them across all car models and add to them when needed. This will significantly decrease the time allocated to a feature, as almost all components are already available.
Coming back to Qonto, this means better communication and collaboration across CFTs. But how can we achieve this at company scale? Thanks to new standards, patterns, and a set of principles, to avoid wasting time one existing components/behaviours (hello Design System!). This will allow more time to work on bringing quality to the end-user.
We also want each CFT to invest a bit of their time improving the existing design system, using enhanced design and documentation.
What we achieved
Here are the three main actions we carried out to get one step closer to perfection.
Design tokens
Design tokens are indivisible pieces of an interface like colors, font-sizes, spaces, animations, shadows, z-indexes, breakpoints, etc.
We added some design tokens, which aim to only allow defined values (sizes, colors, shadows..) within a feature, and therefore increase consistency in our codebase and avoid errors. As a design system cannot live without any documentation, we made sure to create some to support our new method.
Below is our new font system, primary color palette and shadows used for elevations effect.
New tools
These improvements were made possible thanks to two main tools.
Storybook, a UI component library for frontend developers where we added all our component documentation. From available parameters to supporting developer documentation, Storybook is owned by the Front-end team.
On the designer side, we added a new tool named ZeroHeight, which gathers the components and good practices we use from a design point of view.
Both tools work together, so a component from Storybook can be embedded into an iframe on Zeroheight, allowing us to compare it with the guidelines previously defined, and confirm its consistency. The objective is for Storybook and Zeroheight to reflect the same truth.
Below, side-by-side, Zeroheight (on the left) and Storybook (on the right), both documenting the Button component.
Making the Design System available and used by everyone
This is certainly one of the most important parts: it’s useless to make tools available if no one uses them!
One way to do this is by making the Design System belong to all CFTs rather than a single owner. We involve them into the improvement of outdated components — by making these match our new Design System requirements.
Thanks to all the actions listed below, we did manage to increase our consistency in our codebase.
Here’s an example of the modal today:
Everything is now aligned on the left ; titles, content and buttons are the same size and look the same. Cherry on top: they all use one close button 😜.
Last but not least
This is also a great benefit to our developers, as we went from using more than 70 lines of code to add a modal to only 21 lines! And as a bonus, we ended up saving some bytes on our application size, since there are less lines of code!
As a result, we successfully created a common language between our teams, and our front end UI library is now aligned with our designers’ Figma library.
This allowed us to focus on improving existing patterns and therefore upgrade the entire codebase application. It also reduced a lot of the noise between different teams, making it easier and smoother to find information.
This is the reason our team work is now clearer and decisions are easier to share and understand.
About Qonto
Qonto is a neobank for SMEs and freelancers founded in 2016 by Steve Anavi and Alexandre Prot. Since the launch in July 2017, Qonto has made business banking easy for more than 120,000 companies. Thanks to Qonto, business owners save time (streamlined account opening before a day-to-day user experience with unlimited history, accounting exports, expense management feature), have more control while giving their teams autonomy (real-time notifications, user right management system) and have improved visibility on cash-flows (smart dashboards, transactions auto-tagging, and cash-flow monitoring). They also enjoy stellar customer support, at a fair and transparent price.
Interested in joining a challenging and game changer company? Consult our job offers!
