Published on | Prototyping: From UX to Front End — Medium Rayana Verissimo

Started from the bottom now we’re here: How we are empowering product and design growth at Backbase with a Design System.

A transcript of my presentation for Ladies That UX Amsterdam

Illustrations by Abbey Lossing

Building software is damn complex. Being a designer in a development-centric company can be challenging — even maddening at times. We all have been there: no sharable design assets, fast-growing company and sudden increase in staff, designers working in isolation, poor communication cross-department… While very common in the software industry, those challenges provide a great opportunity to understand how to improve internal processes and collaborate to build better user experience.

Previously, I worked at Cesar as a UI Engineer building a component’s library for a Fortune 500 enterprise. I am familiar with the challenges of redesigning a complex system while building a design language to support product development. So to get started with the Backbase Design System was a no-brainer — but that doesn’t mean it was an easy task 💥.

Over the last year and a half, I have been focused on building a system that enables our designers to build better and faster, and also ensures we’re in the right path to grow our product with consistent, tested and reusable design solutions. This is the story of how we are getting there.

What is Backbase anyway?

People often ask me “what is Backbase?”. We are a fintech company with headquarters in Amsterdam, The Netherlands 🌧 — here’s the catch-phrase we often hear from our sales people:

Backbase is a fast growing fintech software provider that empowers financial institutions to accelerate their digital transformation and effectively compete in a digital-first world.

Ok. In other words, that means our customers, mostly small/medium banks from all around the world use our building blocks platform (Widget Collection) to build the online bank that their clients are asking for.

The Backbase Omni-Channel Digital Banking Platform

Why? Because banks are no longer the same institutions they were a decade ago. Banking is no longer a place you go, but something you do. Do you remember the last time you had to go to your branch to do a transaction? I do. It was on the 16th of January, 2016. The day I had to open a bank account in The Netherlands. Since then, I never stepped foot in a bank. I don’t even go to ATMs anymore, most of my payments are contactless. That shows the existing gap between customers and financial services. To better understand the changes financial services and payments are facing with the impact of the internet, I recommend the book BANK 3.0 by Brett King.

As designers at Backbase, our mission is to deliver great, seamless UX. Our product is modular and will change every time it is implemented by one of our customers. Banks in Europe do banking differently from banks in North America. We need to understand both the business and the user goals on a global scale in order to design a product that is flexible enough to work in every market.

Our (incomplete) group of product and consultant designers from Backbase ✨

Our design team is scattered across three departments, each with its priorities and goals:

Research & Development (R&D) — The research and development team, responsible for building and improving core Backbase products. As R&D designers, we need to be experts on our products and capable to understand user goals and needs, how they influence our design decisions.

Solutions Engineering (SE) — The sales team, responsible for growing our portfolio of clients. Designers at SE work in a workflow similar to Digital Agencies: fast processes, short deadlines and a lot of pressure to seal the deal.

Professional Services (PS) — The consultancy team. Designers work implementing our products on the client side, defining a custom look and feel to the product based on the Bank’s brand identity.

“If your company is not integrated, you are unable to innovate”

The lack of integration between departments contributes to people having an isolated view of each activity, not looking at the process from an end-to-end perspective. Without integration, a company stops innovating.

When I joined, our team of designers in R&D was… well, for a brief moment, myself only. Before establishing a design team, Product Owners often had designers from other departments coming in and working as consultants to deliver prototypes, but no one really stuck around to see the product grow.

In that scenario, most of the “consultant” designers did not possess the understanding of our software as a whole, what features were available by default, or the overall look and feel of our product. Add to this mix the lack of design assets, documented requirements, and user journeys. It was a huge headache for everyone.

In the SE department, each design was created afresh according to that designer’s eyes and tastes. These designs were then recycled, over and over, and became a line of bespoke mutations of the truth.

In PS, the designer’s only reference was proof of concepts from SE, previous implementations with other clients or technical documentation. It was really hard to know what was “real” as in “actually part of the product” and what was a customization specifically for a project.

And R&D had mostly designs from PS as a reference. It was a vicious cycle.

The vicious cycle of doom, where Professional Services provided our product vision🙅🏻‍♀️

This created all sorts of other problems like designing a custom version for a project that could not be updated in the future, costing our customer more money. And well, you can just imagine the world or re-work that we did. We reinvented the payment form 342 times. The design debt reflected not only in the lack of visual consistency in our product but also in technical debt. Developers would write lines and lines of code and CSS to build upon inconsistent designs and QA engineers had no reference to validate the UI against. Marco Suarez wrote an amazing article about how understanding the importance of a consistent design helped Etsy to build better products.

As designers, we don’t want to be repeating the same tasks over and over again. We want to be able to solve real user problems through innovation.

Same feature, multiple solutions implemented: which one is the official one? 🤔

Our teams were definitely convinced we needed something to improve our way of working and build system every designer inside our company could understand and contribute to. As our product and company grew, we had to find a way to scale and get out shit together.

What Design System means to us

I assume you are familiar with the concept of Design Systems. Well, for us at Backbase, a Design System is a modular accelerator to our Design and Product Development processes throughout the company. We are building a set of guidelines and deliverables for designers, developers, and business people.

The core modules of the Backbase Design System

One way we’ve enabled our design team is through UI Kits. In R&D, we first standardized the look and feel of the product to finally solve the problem of multiple visual styles available. No more “consultant” designers coming in to “help”: our Product Design team is responsible for projecting features and has full ownership of the product.

The low-hanging fruits (while looking at the high ones)

To help with the lack of visual consistency, I put together a Sketch Library with all existing UI components — as in, implemented and in use in our codebase. This made possible for designers to quickly create new visual product prototypes and proposals for clients.

The UI Kit also introduced a unified visual style for the product, which we call “White Label Theme”. We need our product to look generic because each client needs to be able to visualize its brand in it during a proof of concept, for example. Having a single theme allowed R&D developers to work on a CSS theme to be applied to all our functionalities. Our feature teams are responsible for styling the components using the UI Kit as the single source of truth. Cross-departments, front-end engineers could override the CSS in a semantic way during projects, log bugs and suggest enhancements.

Our first quick win was delivering a Design Kit with all existing UI components, allowing designers to quickly build prototypes

Initially, the UI Kit existing as an Invision prototype so that the whole company could see what components were available and also as a way to help R&D developers to quickly inspect CSS properties to build the White Label Theme. When matured, the theme was shipped as part of the product. In a future post, I will dive better into how our UI Kit had to be set-up in order to work with different stakeholders.

Example of documentation for Modal component describing generic criteria and requirements

I also had to spend a lot of effort documenting design and development guidelines: how to best write CSS, what are our accessibility standards, what UX patterns to use and when to use them…

People loved it! But we needed even more! We needed something global.

How to create so many things for everyone?

Being able to deliver something valuable turned out to be a huge effort that involves everyone in the company. After a couple of months, I realized that some similar initiatives existed over the years but none of them scaled. But why? A quick explanation is that design was not the driver to help solve our internal problems.

To be able to better design we had to take a step back. We choose to not copy-paste a solution from another company or jump into building state-of-the-art online style guide. We grew our design system organically looking at our problems and how we could solve them, tackling one thing at a time, building the system as a compass for our design process. I try to approach this process from an agile perspective to apply user-centered design practices.

“To deconstruct a large design into smaller pieces, it is essential to start with well-defined design goals and to understand the high-level design intent.”
Desirée Sy on Adopting Usability Investigation for Agile User-centered Design

The change, in reality, is not on what we deliver, but what paths we took to achieve it.

How we are doing it

This is not supposed to a be cookbook or best practices on building design systems. There are many different constraints when it comes to software development and our reality at Backbase is maybe unique. I recommend reading the basics: Brad Frost, Sales Force, iOS Human Interface Guidelines to get started. But here are the insights I can share:

Build a team of proactive, cross-functional people

Cross-functional teams provide multidisciplinary perspectives on all project ideas, which lead to better design solutions. To focus on Design Systems, we built a team of people who are curious about other disciplines, know the product and want to get things done!

A unicorn designer (🦄 me!) that can do both incredible UI and prototype in HTML on the fly. A front-end developer that would love to solve the issues of inconsistencies of the codebase. A UX designer that advocates for user research. A Product Owner that understands business, technology, and design. Put them together! The team should include everyone needed to get the project done.

Bring UX and UI Designers onto the feature team from the very beginning of the project

As designers, we analyze and understand the user and business goals and translate this into the user experience. UX Designers should work hand in hand with specialists and developers as they build a working version of our product. It was vital that our feature teams had a least one designer involved in the ideation and prototype phases so that we could ensure our product vision is being respected.

Slowly but surely: UX in the center of everything. Source

Take a collaborative, not a siloed approach to doing the work

This means “get your ass out of your chair”! We have introduced bi-weekly UI/UX syncs in R&D to look at upcoming features to identify an opportunity to build new components and patterns or enhance existing ones so that they can be built in a holistic way by our Design Systems team.

Define core goals and principles

Find the existing pain points, define your goals and principles. They are as important as having an action plan. Our goals are pretty simple and ensure we keep moving forward:

Accelerate the design and development workflow across the Company.
Deliver an extensive set of UI components that are easy to reuse, access and extend.
Provide comprehensive guidelines to support design and development teams.

During the Design Day we discuss each designer’s struggles, brainstorm solutions and prioritize them against the company’s goals.

Build a Design Kit to streamline work process and improve the design workflow

A single source of truth for the Design and Front-end building blocks: core visual styles such as colors, typography, iconography, mixins etc, are organized in an easy to customize Sketch library that lives in parallel with the Online Styleguide. Updated regularly and released as part of the product — because design is a core part of it 🚀!

Work in collaboration with your front-end developers

Own the interface from end-to-end. Get involved in reviewing pull requests, defining acceptance criteria of components, delivering accessibility requirements for the interface. Test things and validate it before anything is considered “done”. The UI is as important as any other part of the development process, so being able to collaborate with the front-end team to show the importance of consistent UI is a big thing.

Deliver the Design System as a tool

Our Design System is a collective effort and the result is a set of components, styles, guidelines, and patterns for Designers, Developers, Managers, and Clients, accessible via a web page and a dev platform that can be used on PS and SE projects. Developers can also clone it and customize a local version to sample the component’s library using client’s visual language. Everybody wins!

Understand that a Design System will always be an ongoing process

Rome wasn’t built in a day 🙂 Get management and developments teams on board: The Design System now an essential part of our product development. We needed a dedicated team of developers to speed things up, while in other companies this can be done in a more collaborative approach. I recommend Nathan Curtis’ post on “Team Models for Scaling a Design System” for you to get familiar with the possible approaches.

<a href="https://medium.com/media/bc8664469cd35371c9733ac78ac51c7b/href">https://medium.com/media/bc8664469cd35371c9733ac78ac51c7b/href</a>

Achievements

While still a work in progress, we can already see how the design system has benefited the organization:

Design Systems Team and R&D driving the product design vision
22 designers working with a single UI Kit!
Dedicated Design Systems team!
Faster design and implementation of projects
Universal guidelines
Increased alignment between designers and developers
Better communication cross-department
Reduced gaps between what’s designed and what’s coded
Happier designers and developers 🎉

The new workflow with the Design System as a driver for the product design and development 🎉

Continued challenges

That is obviously not the end. We still have some challenges to face in order to make our design system even more relevant for our company. A few points to mention:

Collaboration with the mobile team
Automate design consistency
Build new interactions and document “legacy” patterns
UI/UX discussions to be faster and more efficient

Lessons learned

There is no easy way to implement a design system. And although having a consistent product (design and code) might sound like an obvious thing to some, it can be seen as an “extra effort” to business people. We got the company leadership on-board and set-up a dedicated team of developers work on the design system only recently. Even so, we managed to achieve so many great milestones and released the second version of our UI Kit plus fully migrated components using the White Label Theme. Like any challenging project, there are some things we wish we have done differently.

Not every designer will want to get involved. Some people prefer doing usability research, other like to push pixels, and a few will use the system without wanting to get involved in the process. That is fine in the beginning. People tend to get more excited as they see positive results. My goal is to make everyone understand the value of having a design system and ultimately get all our designers contribute to our system, making it more adequate and robust.

Build a powerful Sketch Library from the start. Our initial UI Kit in Sketch consisted of only symbols without much explanation of what to do with them or how to use the components. I have collected feedback from our team of designers and am currently working on a Sketch Library that is tightly connected with the product prototypes provided by R&D and also can work as a “template” for other designers to do a show-and-tell to clients of how our product can be easily customized.

Document on the fly. Phew. Documentation. I love it, some people hate it or think technical writers should be the ones worrying about it. Being the only one responsible for documenting component’s criteria and UX patterns was overwhelming in the beginning and as a result, we still have a lot of gaps in our design docs. I have managed to make each product designer responsible for documenting initial criteria in a Sketch file, together with the component/pattern variations — as a definition of done for it to be adopted by the system. I am still the main contributor to our docs, but we see more and more people wanting to give their 2¢ about our product behavior and documenting it in our Confluence space.

Bridging the design/development gap is a constant work in progress. (Sadly) most front-end developers won’t care about matching their CSS to the high-fidelity prototype a designer delivered, and not all Product Owners see the interface issues as something critical. Creating a culture where devs CARE about how the product looks is a constant work in progress. That is why it’s so important having a UI Engineer in our team to be the CSS police and ensure the final product is high quality and works exactly as our team of designers intended.

Sketch is not your design system. Oh boy! How many times do I have to repeat that? Like Brad Frost pointed out, if you don’t have a functional component, then you have no component. Making our team of designers understand that something that is not coded cannot be in the UI Kit took some time. The UI Kit is an accelerator and only one of the important parts of the process of building an interface.

Conclusion

Building a design system is not a one-woman job 👩🏻‍💻. I found that engaging people into collaborating was the most challenging part of the process. A lot of pieces of the puzzle need to be aligned with different stakeholders, so advocating for overall UI and UX consistency and adherence is extremely important. We also had to spend more time thinking about the Design System as a product, so it was essential to involve business in the plan to update the system.

In retrospect, these are my top 5 tips that you can take as a learning and apply to your own reality:

🔍 Start small
👫 Get a team of enthusiasts
🗣 Advocate for design inside your company
🎁 Define goals, vision, and list existing pain points
👊🏼 Take ownership and get shit done!

Reception from our company has been exceptionally positive and we are excited to see the system grow and scale with our product. I hope to continue to iterate on the system using more data from our customers, and in addition focus on innovative UX solutions for our product.

🙌🏼 Big thanks to Celeste North and Lucie Angolini for the incredible help with preparing and co-presenting this talk. You girls rock!

👩🏻‍💻 Do you want to discuss more about design systems? Leave a comment below, connect with me on LinkedIn, or drop me an invite for a bite if you are in Amsterdam!

Empowering product growth with a Design System was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Empowering product growth with a Design System

Started from the bottom now we’re here: How we are empowering product and design growth at Backbase with a Design System.

Top Stories