Responsibilities

• User research

• Figma component design

• Implementation + iterations

Project context

• Role: UX Project Lead, Designer

• Team: Alexander Pan, James Hernandez, Lisa Montalvo, Monica Kawade

• This project took 8 months to complete the first version. It is still constantly iterating.

project Background

Who is Kibo?

Kibo is a global e-commerce SaaS company. It needed a cohesive and consistent design system to enhance the customer experience across its digital platforms and to speed up its development.

What is a Design System?

A Design System is a systematic approach to product development complete with guidelines, processes, components, and code. It is a single source of truth for teams that simplifies product creation, testing, and development, and ensures consistency across different pages and channels.

Who is the Target Audience?

• Developers need a better Design system to reference and to avoid wasting time on components used repeatedly.

• Designers need a Design system to keep the design consistent and accessible.

• Clients (Vendors) need the fast development and consistent design that a Design system offers to improve brand reputation and site SEO.

the why

Ineffective use of the current Design System slows down Kibo’s product development and hurts design consistency

The old Kibo design system is hardly being honored today because it’s not been well designed and maintained in the first place. As one of the two designers leading the design tool migration from Sketch to Figma, I saw it as a perfect timing to take the initiative of reorganizing the Design System.

Objectives & limitations

Main objectives

• ​Interview and research the current design system with stakeholders falling under the three main target audience groups.

• Research and design better design practices for the use of the Kibo Design System.

• Maintain and track the performance of the new Kibo Design System.

Limitations

• Have to be as not disruptive as possible (not affecting current clients).

• Don’t introduce new tools.

• Don’t add new colors, typefaces, or components.

Research

Design System Audit

I dove deep into the entire platform to spot as many inconsistencies as possible in the UIs against Design Principles (Visual Principles and Heuristics from the NN group)and Accessibility Principles (WCAG 2.1).

Results

We found a number of inconsistencies in the UIs and violations of UX best practices.

• Inconsistent color palette

• Inconsistent spacing (paddings, margins)

• Lack of help and documentation

Below is a visualization of all the different styling variations on our site at that time we derived by running CSS Stats, a free inventory tool that finds and analyses a site’s stylesheets.

As shown above, we had many different colors, font sizes, and spacing values. And that was only part of the problem.

By creating an updated centralized design system, we aimed to:

• Align our teams by giving them a more structured and guided way to build products.

• Speed up our design and development process: with a ready-made library and patterns teams can create and test layouts much faster.

• Improve brand perception and user trust through consistent experiences that work for everyone and allow users to accomplish their goals.

• Promote accessibility of our products by building accessibility and inclusion into our component libraries, both from a design and code repository perspective.

While it was clear that this project would require a lot of resources, planning, and time commitments, we knew that this work was a justified long-term investment in our company, brand standards, and our customers.

research

Stakeholder Interviews

Our main research was conducted through user interviews with existing Kibo design system users - Designers and Developers. We hoped to find out more about where the pain points and frustration of the current version lie.

General Insight

• Developers hardly look at the Design System because they rely primarily on Storybook.

• The current Design System’s lack of documentation keeps designers from using it effectively.

By getting other teams involved from the onset and as the project evolved, we strived to promote understanding of the project and inspire a sense of co-ownership throughout the entire process.

research

UI Inventory

To better understand the current state of our existing design ecosystem, we started with a UI Inventory of our main interface components. We used Brad Frost’s interface inventory guideline as inspiration to conduct a full-day audit that we ran as a team of 5 designers and 2 developers. We split into three groups and assigned each a set of components to go over on our site and build an inventory around. The plan was to screenshot unique instances of our main design assets such as typography, buttons, icons, input forms, drop downs, etc., and add them to our PowerPoint template we had prepared ahead of time. Then each group shared their findings with the team.

As a result of this exercise, we identified a lot of inconsistencies in our design assets, which only proved the need for a more systematic approach to documenting, communicating, and maintaining our design system.

Below are some examples of the components screenshots we came up with after this exercise:

design

Proposed Solution

We decided to focus first on the foundational elements (atoms) of our design system, such as color palettes, fonts, grids, spacing, buttons, etc., and then move on to more complex blocks and pieces (molecules, organisms, templates, pages). We created components from scratch since we switched from Sketch to Figma.

Activities at this stage involved:

• Researching other design systems and interfaces for components common practices and inspiration.

• Analyzing the instances and use cases captured during the audit and ideating on the solutions that serve our goals best.

• Unifying: we merged different variations of components to leave only the essentials. For example, we limited our color schemes to a maximum of 9 shades for each hue, and all the excessive variations were matched and merged with the decided-upon schemes based on proximity. Below is our final color palette:

Some principles we followed:

• We tried to make our components responsive with the auto-layout Figma feature, so we could reuse those components when designing for different devices or layouts.

• We designed to cover all scenarios, or “states” in the system: hover, focus, filled out, error, and disabled state.

After the Variants feature was introduced to Figma, we started using it to combine variants into component sets with custom properties and values. Using variants makes components easier to maintain, browse and swap through the sidebar menu.

Each component we designed with accessibility in mind. We strived to comply with WCAG AA accessibility standards. Below is an example of intentional choice of color on a warning alert to achieve sufficient text contrast (checked via Stark Figma plugin) so that users with low vision can see and use our component.

Feedback

Review

Review & Follow Up

Reviewing work is an important part of any design process to ensure we arrive at decisions collectively and align on details such as component design, documentation, and tools. For this project, we formed a multidisciplinary design system team that would meet every two weeks to discuss the direction and progress of work. We also set up a design-systems Slack channel, where we post the design system updates and requests for asynchronous feedback. These practices allow us to collect everyone’s perspective and bridge the gap between design and engineering.

Documentation

Documentation

High-quality component documentation is crucial to an effective library allowing everyone to quickly and efficiently make consistent decisions. We wanted to create detailed documentation that would support every single aspect of our design system, and also be organized, consistent, and easy to use. We referred to several design systems such as IBM’s Carbon, Material, Atlassian, Salesforce Lightning, and other design systems for some good practices, guidelines, and tools that we could apply in our design system.

We set out to produce design-led and development-led documentation that is integrated and synced to create one consolidated system.

Design-led Documentation 1 - Figma Component Library

Once the Figma components are approved, we move them to a Figma Atomic Components file, a shared library of assets that our team can use to drag and drop while working on their designs.

Design-led Documentation 2 - Zeroheight Documentation Site

We use Zeroheight, a collaboration platform that integrates with Figma and allows product teams to create and maintain web-based design system documentation. If Figma atomic library is a library of design components, Zeroheight is a collection of guidelines and rules for those components. At a high level, most of our component documentation in Zeroheight usually includes:

• Introduction with component description

• Component construction

• Component states

• Behavior

• Best practices

• Accessibility guidelines

• Examples of components in different contexts to demonstrate how design patterns would be applied in real products and specific use cases

Development-led Documentation 1 - Storybook Components Repository

Our old repository was dated and only addressed our design system in places where we use React, which is not everywhere on the Storyblocks. We decided to build out our new repository from scratch in Storybook. This tool allows us to create an interactive pattern library for code in isolation and supports all the popular frontend frameworks. It allows to document use cases as stories and easily find, share, and reuse them. Like Figma, it also integrates with Zeroheight, making it easy to sync and align documentation between development and design. We called our new repository “Storywind”. Our plan is to eventually migrate all components from the old library into one consolidated repository.

Progress Tracking

In order to track and communicate the progress of the different steps, we created a Jira board that can be viewed and updated both by design and development. We create tickets for specific components that link out to all the relevant documentation and move them to corresponding status columns (In Design, Needs Feedback, In Development, etc.) throughout the process.

Next Step

The design system is an ongoing project. We iterate, change, and learn a lot in the process. So far, we have a set of basic components ready, which has been game-changing for our team in terms of efficiency, as well as consistency, and standardization.

Some of our team’s next steps include:

• Continuing to grow our component library and supplement it with more complex components.

• Adding sections on brand, illustrations and animation.

• Cultivating processes and best practices for maintaining the documentation to ensure that our library stays up to date and perfectly in sync both on the design and code side.

• Raising awareness across the teams and promote adoption and contribution to the documentation.

• Building processes for testing the components on compliance with guidelines and accessibility standards.

Thank you for reading! 🧠

Scroll To Top

More Projects: