Carbon: Designing inside Big Blue
Carbon is the design system for my product team at IBM Bluemix. A design system contains components that can be combined and reused to build user interfaces. It enables teams to focus on how a user interacts and converses with a piece of software, rather than arguing over what color a button should be.
At IBM, we’re in a unique situation of size. IBM as a company has over 2,000 products, and different experiences should look and feel like IBM across the board — scale is our primary challenge. At the corporate level, the IBM Design Language provides guidance on how to communicate IBM’s brand promise and creates a basic framework for how all IBM products should look and feel (with assets like a sweeping color palette and iconography), but doesn’t dive deep into how that translates into product interface itself. The challenge for my team was taking that framework, and crafting a system for Bluemix itself that fit with the parent IBM brand, but could also scale across many Bluemix sub-products as well.
Growing pains
When IBM Bluemix debuted in June 2014, it launched with only basic functionality — essentially, it was an easy way to host an application on the web. Two and a half years later, Bluemix is now comprised of over a 130 different services that users can use and integrate to power their applications. Bluemix now also lets users spin up different infrastructure elements, such as Containers and Virtual Machines.
While the feature set grew in leaps and bounds, the UI didn’t age as well. Until February 2016, the original interface only went through minor iterations and consequently looked old, tired, and inconsistent. To exacerbate the consistency issue, large swathes of the UI are owned and designed by the individual services themselves. These service teams range from a fully functional cross-discipline team, to just a few developers and a project manager. Over 50 designers were working on the product, and yet only a two page style guide existed as a single source of truth.
In short, we needed a design system.
Building out the system
Our first step was formalizing a Design System team. From the very beginning, we set out with two main goals — one, the system should work for both designers and engineers, and two, the system must be easily adoptable by teams.
Creating trust
A key facet to accomplish these core goals was establishing trust with our different service teams. Engineers and designers can rely on the fact that any component within the Design System is backed by research, visual consideration, accessibility, and UX guidance. For engineers, there were two main things we did to build trust: first, we semantically versioned the Design System. Engineers knew that we treated the system like a product, and would not haphazardly push breaking changes. And second, we distributed the codebase through industry standard channels (npm and bower) — we wanted to create an environment where developers already felt comfortable working in. There was a large emphasis on blanketing our codebase with tests — as if it were a product itself — to ensure that anything we shipped was production-ready. For designers, we finally had a single source of truth for UI patterns, so there were fewer questions about correct color usage or sizing.
Accessibility
Accessibility was and is a top priority within the Design System. Each component and element was built following the Web Content Accessibility Guidelines (WCAG) and met the AA standard. Our patterns are perceivable, operable, and understandable to users, even when using a screen reader or other assistive technology. An example of this is running color contrast tests on our UI patterns to ensure they are accessible to low-vision users, or testing keyboard navigation to verify the tab index is presented in a logical order. These are just a few measures we take to design with accessibility in mind.
Documentation
We couldn’t make assumptions about our users level of knowledge, so our documentation covers everything from getting started to detailed usage guidelines. Our hope is to enable individuals with no design background to understand when and how to use the patterns in our system. A developer or project manager, for example, should be able to learn when to use a checkbox versus a radio button. Good documentation allows us to properly communicate with our service teams, which has been crucial for adoption.
Introducing, Carbon
We gave the design system the name Carbon, because in nature it builds complex structures from simpler compounds. This motif mimics how our individual styles and components can combine to make beautifully complex, natural, and intuitive designs.
Initially, it was challenging to deploy Carbon across Bluemix, due to the amount of legacy code in the product coupled with development teams’ unfamiliarity with sharing a UI library versus just creating a component themselves.
Much of the success of the system lies in the hands of those who adopt and use it. Although Bluemix has a team dedicated to building and maintaining Carbon, we have many others that contribute code, design patterns, and provide general feedback.
A new era
It’s very common for the Carbon team to hear the need for additional patterns or components. And that’s where the beauty lies within a system — in its ability to scale and grow to accommodate the needs of those using it. Running on a continuous delivery model, the system will never be “done” or “finished.” The Carbon Design System surely isn’t perfect, but we didn’t build it to be. I have confidence in knowing what we’re building will be an essential piece to our design and development process, and the growth of the platform. It’s an exciting time for IBM and for Bluemix, and I’m lucky enough to be a part of it.
Check out the Carbon Design System and let us know your thoughts!
Bethany Sonefeld is a Design Lead and UX Designer at IBM Design based in Austin. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
