Design System for Fin Tech Product Family

Creating a highly scalable and collaborative design system in Figma.

 
 
Multidevice-Setup.jpg

 

Context

Equals Money is a Fin-tech company with expertise in international money transfer and business banking. Their family of products is focused on money management for international TV and film production clients like HBO and Netflix.

I joined the Equals design team at a time of a significant transition for the business. The FinTech company, launched several new products and doubled the number of product teams. They needed to move and scale fast.

The company’s individual products were complimentary to each other and increasingly sold as a package. But they were conceived and developed at different times, by different teams, with little consideration for unified experience. It became clear the product family needed a shared UX framework. The new framework could be then used to speed up product design & development, iterate and launch faster.

The challenge

The main challenge was to find out if and how a shared design system for all products could address the following problems:

  • Fragmented user experience across different product

  • Design and build debt

  • Duplication of design and build effort for new products

  • Slow product iterations and launch to market

  • Inefficient on-boarding of new starters in design and development

Our approach

The team decided to approach the conception and building of the design system as stand alone design project. Looking at a design system as tool and means to an end made it easier not to be distracted by the industry hype. We followed a familiar double diamond design process - discover, define, create and implement - and utilised tools such as 5 Ws, journey mapping, jobs-to-be-done, co-creation workshops and design principles.

 
 
Process-diagram.jpg
 
 
 

What I did

The first phase of the project was a highly collaborative effort. Togther with my design team colleagues we conducted a series of sessions with different stakeholders to capture their perspectives, intentions and expectations. Next the design and development teams worked together in mapping out common issues and desired outcomes. Eventually the teams were able to formulate a set of guiding principles for the project and get a sign off from our stakeholders.

In second phase the ownership of the system was distributed across the design and development team. I was responsible for creating the design system library structure, building and refining library of foundational styles shared across all products and building and refining component library for responsive web apps.

 

Discover

  • Conduct existing product interface audit

  • Map current design and development process

  • Jobs-To-Be-Done analysts

  • Interview stakeholders

  • Find common ground in design and development workshops

  • Research and share industry best practices

Define

  • Design system principles workshop

  • Agree ownership model

  • New design and development process

  • Sell the benefits to the stakeholders

Create

  • System architecture

  • Figma file structure

  • Extend original icon set

  • Unify UI styles, type, colour

  • Set up component variants

  • Unify common interaction patterns

  • High-fidelity micro-interactions prototypes

Refine & Implement

  • Test interaction prototypes

  • Trial proposed solutions on a small scale

  • Make adjustments based on team feedback

Evolve

  • Manage new additions

  • Maintain Figma libraries

 

 
 

Outcome

We used refactoring of current product as an opportunity to set up and test the system infrastructure. We ended up with a solid system fundation and a good deal of learnings. We were ready to utilise these across other products. When the pandemic hit, the parent company shifted design and development resources away from the Equals product suite. The system fundation was repurposed and used to redesign and launch products under Fair FX brand to target different segment of the market.

www.fairfx.com/

 

Tool-Diagram.jpg
 
 
 

Designing the right system

 

Finding common ground

We initially conducted a series of sessions with different stakeholders, aiming to capture wide spectrum of believes, motives, intentions and expectations. We assessed the overall all state of the product and how it responded to users’ needs and expectations as well as business short term and long term goals.

At the same time we involved designers and developers from across the product teams in collaborative workshops. This allowed us to identify mental models and expectations and every product team a voice.

Using Jobs-To-Be-Done framework we deconstructed the whole product design process to distinct stages. Next we identified pain-point in the current approach. Then we looked for ways how design system might drive improvements at every stage.

 
Workshop.jpg
 
 

Defining our priorities

By identifying common themes and collaboratively consolidating discrepancies, we were able to formulate a set of goals for the project. These goals captured shared criteria for quality and success that worked not only for the design and engineering teams, but rather the whole business.

Unified

The system connects all products and all platforms under one unified whole with consistent look, interactions and design patterns. Each element should contribute positively to the system at scale. There should be no isolated treatments or outliers.

Collaborative

The system is a shared language and for this to work everyone has to be able to participate.

Efficient

Using the system should be the easiest and least effort requiring option for both designers and developers. This way we prevent reinvention of solutions that already exist and boost teams productivity.

Scalable

This system must be able to welcome incoming innovations without disrupting the existing experiences that feel familiar to our users.

Feasible

The creation of the system has to fit in our already busy roadmap and should not slow progress of any product development. The effort to create and maintain need to be sustainable over long term.

All proposed solutions and subsequent decisions would be benchmarked against these goals.

 
 

 
 

Deciding system ownership model

It was important all product teams are well represented in the design system project. We chose to adopt so called “federated model” of ownership as coined by design systems veteran Nathan Curtis.

It meant that designated representatives from various product teams assembled to create and manage the system. This ensured fast input and feedback loop from across the teams while keeping governance responsibilities clearly defined .

 
Ownership Model.jpg
 
 

 

Considering system architecture

I proposed the architecture of the design system was split in to three different levels - brand level, platform level and product level. The split levels would ensure better visibility of the shared parts and simplify file management.

Brand Level

At the brand level were assets such as colours, icons, illustrations and graphics. A single Figma file would be used to distribute and mange brand assets for all products.

Platform Level

The platform level was split between two Figma libraries. One for responsive web app components and the other dedicated to shared native mobile components. Keeping platform level components separate from individual product flow aided visibility and management of the shared assets.

Product Level

The individual product screens and flows lived on the third level. Using Figma linked libraries we were able to synchronise the three levels seamlessly.

 
System Architectue.png

 
 
 

Designing the system right 

Mapping component families

Before starting the design of individual components I used finding from conducting the interface inventory. I carefully considered how components fit in to a larger component family. I mapped out interaction states such as click, hover, loading and error. I also included different levels of prominence and hierarchy. This ensured component flexibility for different context and placement while preserving familiarity and intuitiveness for the user.

 
Component Family.jpg
 
 
 

Setting effective visual hierarchy

Having a font family with 4 distinctive weights was important for creating effective visual hierarchy across a variety of interaction patterns.

By using a 4pt baseline grid in the type system we were able to easily implement a modular layout that later helped me to organise components like a stack of Lego bricks. The 4pt typographic grid is finer than the 8pt grid used of components. This helps us to fine tune alignment and spacing of small text and icons.

 
 
Typography.png
 
Typescale.png
 
 
 

Unifying style and meaning

Icon libraries and icon styles had historically been different across each of the products. Originally this seem to make sense, given that most users of the different products have all entirely different contexts. But we realise that a common set of transaction icons with consistent signalling of funds movement would work across every single one of our products. I unified the icon set and extended the original one weight to match our type styles with bold, semibold, regular and light weighs. This would allow us to use icons more effectively as complementary elements to the type system.

 
 
Icons1.png
 
Icons2.png
 
 
 

Accessibility guidance build in

I organised our colour pallet by specific area of use such as text, backgrounds, interaction, brand graphics ensured the right colour are applied in the right place. This helped us implementing accessibility best practices at the very start of any interface design.

 
 
 
 
 

Flexible modules

For the construction of the components I recommended use of 8pt base unit to get every part fit well in to the system. Divisions and multiples of 8 are used in typestyles, icons, spacing and component containers. This is the glue that binds every single element of the system in to a bigger whole. The simplicity and regularity makes it easy to remember and easy to apply correctly


Modular design with Autolayout 

Components made stackable


Reusable interaction patterns and


Our ambition was also to unify frequently occurring interaction patterns such as transaction confirmations, loading states, empty states and error states.


I started compiling reusable patterns as components in platform specific library ready to be adapted and customised. This was an ongoing effort refining the interaction patterns as we went to make sure they were truly universal and worked in different products.


Standardised naming conventions

Any design systems gets quickly disorienting without clear naming conventions. We agreed and maintained standardised naming convention right from the start to keep things in working order. Even more important was to align naming in design files and code. This streamlined our handover and avoided valuable effort being lost or duplicated.


Prototyping micro interactions

I prototyped the more complex component interactions and states in high-fidelity using Principle. Sharing these with the design and development teams helped refined our system and test usability of the components. The high fidelity prototypes became part of handover documentation so no information is lost



Documentation

Shared styles, components and libraries are valuable as long as people are familiar with them. That is why documentation has always been important. The streamline our documentation process, the development team set up internal website referencing live code assets. The design team wrote annotations in to the Figma files. Using Figma live embed feature the files could be then embed in to the internal website.


Testing and refining


Improving collaboration


The teams maintained weekly peer review meetings to evaluate performance and propose improvements. Sort of community meetings with everyone who uses the design system. To share knowledge and make proposals to improve the system