Carbon Cover Image

I am currently working on Carbon, the design system for IBM Cloud. Carbon is a central repository of coded and designed UI components that enable designers and developers to rapidly build consistent product interfaces. Our initial challenge in building Carbon was to reunite a product that had scaled faster than expected, by creating a framework to address the growing needs of Bluemix while still staying true to the IBM Design Language, our parent design brand.

Highlights

Below are a few select areas of Carbon that I have had the pleasure of working on.

History

Bluemix is a cloud platform that enables customers to build, run, deploy, and manage applications. Over the span of two years, it grew from a basic app development platform to hosting over 130 different IBM and third-party service offerings. As the product expanded so did the Bluemix team—with over 145 individual teams contributing designs to the UI. Most units operated independently of one another, contributing their own UI screens to their part of the platform with little collaboration between groups. Although the various interfaces had some similarities, they lacked a cohesive semblance and user experience across the product. An additional challenge was that, with so many different teams of designers and engineers, it was nearly impossible to insure that all teams across Bluemix were implementing the updates and design changes in a timely fashion.

USER NEEDS

During the creation of Carbon, we considered three key user groups: designers, front end developers, and service providers. In order to create an effective system that would be adopted by all three, we first needed to understand the challenges of their current workflow.

Designers

When Bluemix started, the only reference-point for designers was a two page PDF style guide with basic color and typography specs. By interviewing our fellow design teams, we were able to outline the following issues:

  1. 01 Painpoint

    Each design team owned different parts of the product, and assets were not being shared among teams. Each designer was constantly having to rebuild assets.

  2. 02 Painpoint

    No detailed specs for iconography, basic components, layout, or user experience.

  3. 03 Painpoint

    Minimal, vague, design guidelines were not enough to give designers confidence when making important design decisions.

Service Providers

A service provider is another IBM product that wants to have their product available for use and purchase on Bluemix. Through Bluemix, users can add these services to their application. After conducting interviews with the service teams, and team members whose job it was to help 'onboard' new services, we identified the following issues:

  1. 01 Painpoint

    There were no published guidelines or requirements stating how to become a service provider on Bluemix.

  2. 02 Painpoint

    Bluemix did not provide detailed guidance for service teams to implement a service offering.

  3. 03 Painpoint

    Service teams did not have access to design resources and were crafting designs based on their interpretation of other service page designs.

Front End Developers

Just as the case with Service Providers, there were no published guidelines or requirements for Deveopers outlining component code, best practices, or which language to build pages in.

  1. 01 Painpoint

    Developers from different teams were rewriting the same UI components, often times with different interactions.

  2. 02 Painpoint

    Each development team decided what language to use, so any coded components had to be universal across several frameworks.

  3. 03 Painpoint

    Accessibility wasn't appropriately prioritized and was difficult to implement correctly.

Outcomes

Based on our interviews it was clear that the system needed three distinct parts: a design system website, a coded component library, and a design kit. The site and components are built to meet the WCAG AA requirements for accessibility, so that individual teams do not have to worry about complying with those standards when using our assets.

Design system website: A central repository that all users could reference as a one stop shop for anything related to the design system. The site houses all our guidelines, style and component documentation, and kit resources.

Component Library: A coded library of all universal components used across product. The components are built in vanilla JavaScript and React. Each component is modular, and can be striped down or dressed up as necessary to fit each team’s needs.

Design Kit: A sketch file with all of the carbon components, templates, and basic style elements (color, typography, grids) outlined for quick use and consumption.

While we have three parts up and running, we understand that this work is never done. Carbon is a living, breathing product that grows and updates weekly; it adapts with the product as needed and any new IBM Cloud products that may adopt it in the future.