Juvo Design System
Juvo app solutions offer micro-loan to pre-paid mobile customers when they are short on data or minutes. Those users can borrow small amounts of money, which allows them to stay connected for longer periods of time. It also gives the unbanked a financial identity and the ability to build up credit over time.
How can we introduce and build a system/documentation that will be the source of truth, and help Juvo's product team better collaborate, share work and communicate?
When I joined Juvo I noticed communication problems across the design and development teams. I took it upon myself to solve this problem. Throughout this project, my role was to build a system to document our style and usage guidelines for our core product solution — I created a UI library, wrote documentation, redesigned components, and improved their accessibility and visual design.
To continue to improve the design system we have a weekly Design System group discussion with cross-functional team members, from design to engineering, product, QA, and copywriter.
First, we have to understand why we need a design system. What is the company's context? As a team, what challenges could be solved by a design system?
What challenges are we facing?
One of the primary issues I discovered is our lack of central documentation for our core product. Although, most of the information can be found in various places like Zeplin, Confluence, JIRA, and Google Docs, the lack of an easily navigable, complete repository for documentation led to a constant flood of questions from the engineering team. Engineering was often confused by product/design team choices but did not have an efficient approach for information discovery. This meant a lack of documentation slowed down the implementation! The engineers spend more time trying to understand how things should be built than actually developing.
Having a shared source of truth that defines our product standards will remove the subjectivity that creates friction within teams. It will also help familiarize new employees with existing product specifications, and increase the quality of communication between teams. We will have a place to reference official patterns and styles and will all speak the same language!
The second core issue is, how do we build a design system that supports different brand styles? Juvo’s core product is a customizable white-label solution adapted to each of our partners’ brands. This means for every deployment, the design team must create a picture-perfect mockup for each partner screen. You can imagine this causing significant delays for engineers expecting delivery of these assets.
The final issue is our partners didn’t fully understand how our solution works. They asked questions regarding the scope of what can be customized for their brand.
How did we build the system?
We began with an audit of every screen and component to identify inconsistencies. Eliminating inconsistent patterns consolidates our design framework into one cohesive entity.
The audit helped us uncover irregularities like:
The color palette didn’t integrate accessibility. This means our previous color palette didn’t pass the minimum color contrast ratio requirement from the industry standard (Web Content Accessibility Guidelines, aka WCAG, which defines how to make web content more accessible to people with disabilities). Some color values were missing or undefined. There was no naming convention.
There was no spacing system. Various spacing values cause inconsistency across the entire layout. Even similar components and content looked different across the product.
Our onboarding screen flow didn’t follow the industry standard for Android and iOS.
We lacked defined design principles.
After identifying irregularities, we created solutions. To begin, we focused on the foundations of each component i.e. the color, typography, spacing. These are the elements we are confident will not change for a while.
We began with color. The first step was to clearly define the purpose of each color in the product. Our solution is white-label, which means we have to rebrand/re-skin our generic branded product with a partner brand identity. Naming is crucial to automate the process. We kept this change simple by naming the colors according to their intended use. This meant we titled colors as primary, secondary, accent, success, error, and disabled.
Monica (Product Designer)
Nancy (Design Manager)
Satindar (iOS Engineer)
Jojo (Android Engineer)
Youssef (Web Engineer)
Nimisha (Technical Content)
Celine (Product Manager)
Kevin (Technical Designer Intern)
MVP July 2018 - Nov 2018
Without a unified grid system in place to define the spacing relationships between elements, it’s difficult to create consistency. When working on a project that required multiple designers, having a defined layout and spacing system keeps pages consistent. We found using an 8pt grid system to size and space elements on a page allows for device screen size adaptability.
Why 8pt? Because the majority of screen sizes are divisible by 8.
We updated our onboarding/login experience to align with the industry standard (Material Design for Android and Human Interface Guidelines for iOS).
One of our design principles is consistency. We refer to the native OS design guidelines for maximum quality.
Consistency allows users to learn how to use the app faster and eliminates confusion. From the developer’s point of view, it reduces the time required to establish a new UI layout.
Our documentation establishes the four design principles we keep in mind as we design a product. This allows our design team to design from a solid foundation. This is the expression and philosophy of Juvo’s Design Culture:
Common UI sheets (Multi-product theming)
We created a common UI stylesheet for our reference product. Here you can find reusable elements like color, fonts, icons, and buttons that are now easy to re-skin with our partner brands. Engineers can use our reference implementation as a base and customize visual elements to align with partner brands.
Design and Engineering have transitioned to a more efficient process of collaboration. Rather than creating & maintaining mockups for every screen across all deployments, design now only maintains comprehensive mockups for the core reference implementation.
JuvoUP Mobile iOS library tool
Our iOS engineers contributed to our design system by building an interactive visual library app. This tool catalogs every element, screen, and state found in the core product.
We identified 3 types of design systems for Juvo.
For each type, we use a different tone/language to adapt to the purpose and audience of the documentation.
Internal Design System
The internal design system should be exhaustively detailed because it is used by the product, engineering, and design team as the primary source of truth
Partner Design Guide for Stand-alone app
The stand-alone app partner documentation should be bolder in terms of Juvo’s design choice. There will be more restrictions/constraints in terms of customization for the partner brand.
Partner Design Guide for Embedded app
The embedded app partner documentation should use a collaborative tone since we fit our solution in a pre-existing app. Here, we allow the partners' brand more customization. We make sure the partner understands our solution will integrate/fit their entire app.
Juvo’s design system decreases engineering time spent on implementation. The design team also spends less time repeating and recreating screens for every deployment. The QA team has a reference to exactly how elements should appear. New hires learn the established design patterns on day one from the documentation.
Lesson learn and next steps
What I've learned?
After attending a conference, and doing my own research, I realized how much a design system could improve our processes at Juvo across teams. I knew in order to implement this I would need buy-in from leadership. So I presented an audit of the existing product screens to the company to highlight inconsistencies and demonstrate the positive impact of a unified UI library. Once key stakeholders were onboard I worked with engineering to put our design system online. This allows anyone to access the latest version at any time, and for updates to be made in real-time.
What’s the next step?
Once a design system is created, the next steps are continued adoption and maintenance.
After the initial creation of the design system, we want to step back and reflect on how the design system is best serving Juvo’s teams. The design team has run a series of interviews to better understand stakeholder needs. We want to make the process more inclusive and create a sense of shared ownership.
To solve the pain points and issues that we identify, we created a dedicated working, co-creation design system group. The primary goal of the product design system is to improve collaboration between engineering and design.
For the future, the design system will continue to evolve through team members' contributions. We need to ensure the system stays aligned with our product so it continues to evolve and grow.
Scaling the system
Themes are used to modify existing components to fit a specific visual style. By using JuvoUP’s tokens, developers can easily customize all components by changing a set of universal variables, eliminating the need to modify individual components.
We’ve created a common UI stylesheet of our core product. In this file, you can find the most reusable element like color, font, icon, button… that is easy to re-brand with our partner style. So engineers will use our reference implementation (JuvoUP) as a base and will customize the visual elements to fit the partner brand.
On the side is our map process, on the top, you have our Juvo’s Design System documentation with our guidelines and design principles. To support the guidelines we have the master common UI Library of our reference product (JuvoUP) that’s we theme/customize with our partner’s brand.
This process makes our work fast and efficient. This is how a systematic approach to design makes the scale possible.
Juvo's design system map
A look inside