As a designer, I know that design systems are a fundamental part of digital design. They allow us to build out new pages or flows, iterate ideas, create new products and much more whilst sticking within the core design principles and guidelines we set out for our clients. So when I joined Wise in January of 2024 as a designer working across wise.com, I was a little surprised to find out that a system didn’t exist. Sure, we had systems for other things like our brand and our core products, but not for our logged-out experience.
I soon found out that I wasn’t the only one who found this strange. In fact, a project had been underway for the better half of a year (shout out Rebecca Werres) to start working on a new Editorial Design System to help unify our design for Wise’s shop window, our website. Although it wasn’t so straightforward. Creating a system like this takes a lot of time. That time costs a lot of money and like all businesses, especially a business like Wise, we have to watch where the Pounds, Euros, Rupees, Dollars, Krona, Yen and Franc go.
Ultimately, creating and maintaining a system like this means more efficient and better work. Which means a better user experience. Which means happier customers — both end users and internal employees. That’s the goal anyway and this article will outline not only how we created the system, but more importantly why.
Consistency for 7 million pages and counting
We know that for many of our users, wise.com is often their first interaction with our brand and our products. And first impressions matter. However, with over 7,000,000 (no, that’s not a typo) live pages across all territories and languages, there were many inconsistencies in how we were presenting ourselves to our users. Spacing was a mess, typography wasn’t consistent and at one point we had 12 different types of comparison tables. All of this amounted to an experience which was far from good enough, especially on mobile devices which is roughly 60% of our monthly traffic.
Not only was it an issue for our users, but also our internal teams. Time would be spent designing new pages only to find out that the components didn’t exist in our CMS and therefore couldn’t be built the way it was intended. The problem was that each team was using their own rendition of components with slightly different variations. We needed a single source of truth which could be used company wide.
Rome wasn’t built in a day
With any big project like this, we always start with a company wide audit. We collected everything we had so far to better understand what was being used and where, as well as highlighting any potential gaps both current and in the future. We also wanted to start organising these components into categories, seeing where we could streamline the experience and make it simple for non-designers to find what they’re looking for.
Before creating the individual components we needed to start work on our foundations for the system to be built upon. Things like the grid across different breakpoints, a typography scale, radii, and spacing. Getting these correct would be essential to the system working properly down the line.
But this was a challenge in itself which took a lot of back and forth, stress testing, re-designing and planning before things started to click. Just when I thought I had a component working correctly, with the right size typography and spacing across all breakpoints, it would be translated into German and throw my designs out the window (“Schicesse”). Eventually though, the team and I collaborated our way through these issues and created foundations that gave us that goldilocks level of flexibility.
Across all of these foundations, we created both a desktop and mobile scale to ensure the best possible experience on all screen sizes. We then converted this scale into tokens which could be applied to the component automatically from a top level perspective, both in Figma and in build ensuring that our foundations were consistent across all viewports.
Maximum flexibility. Minimum fuss.
The system within Figma can be broken down into 6 sections that all components have to allow for maximum flexibility whilst staying consistent and true to our design language. These are;
Categories: When we initially started creating components separately, we quickly realised that it was confusing to use and find the exact component you were looking for. The naming conventions weren’t logical and created unnecessary load on the system.
Instead we started to categorise components into buckets. 18 to be exact. With individual instances being variants of the main component. Take ‘Hero’ as an example. Within this category we have ‘Hero Simple’, ‘Hero Small’ and ‘Hero Large’. The same component, but with different variants to display different visual media (video or images).
Breakpoints: As I mentioned earlier, around 60% of our monthly traffic is on mobile, but our current designs and components weren’t particularly mobile-first. With the new system we wanted to make sure the experience was the best it could be across all screen sizes. All components now come in three different sizes. Desktop at 1440px, Tablet at 768px and Mobile at 390px. This allows us to create designs for different screen sizes super fast and super easily whilst ensuring the same great experience.
Themes: Across the Wise design systems we have three distinct themes. Light, Bright Green and Forest Green. Where applicable, components come in these themes as well as Neutral (which is the same as Light, but with a grey background). There are certain components that we wouldn’t use all three themes for, simply because it wouldn’t look good, or it would cause accessibility issues with the content we are displaying to the user.
Layouts: Some components have embedded variants for different layout options such as an image and text swapping sides, or different content types being displayed in the same format. This allows for maximum flexibility and variation within our page designs, without breaking away from the system.
Responsive: All components respond to whatever content is added. Meaning that no manual resizing has to be done and the components spacing and padding remains consistent. Of course, we have guidelines around how much or how little content should be added to each component so help our teams to keep a consistent tone of voice across all pages.
The system in practice
At the time of writing, the Figma library is fully complete and we’ve started using it when updating designs or creating new pages. We’ve completed the documentation for each component on wise.design which delves deeper into each component and gives advice on how to use them in the future.
You can even see some of the system live on new pages such as Send Large Amounts or even on our new landing page for Wise Platform. Using the WMS meant that these pages would be designed, built and shipped in a matter of weeks. Our aim is to complete the build of all components by the end of the quarter 2024, and place them into our internal CMS for others to use.
We’ve already seen a great response to the system online within the design community but the real test will be how it affects efficiency within our internal teams. And even then the work is far from done. The system should evolve and change just as the company, our products and our users do.
Appreciations
As with everything we do at Wise, this work wouldn’t have been possible without contributions from the whole team, including Rebecca Werres, Rosie Isbell, Nick Plummer, Ness Grixti, Henrique Gusso, Kim Nanna Lehult, Naiara Abora, Jon Stieglitz and many more.