Carbon design system: My necessary innovation

Did you ever wonder how a design system is created? It starts with a big problem.

Today's version of Carbon wasn't always this slick. It started as an idea.

The problem: UI design is inconsistent and takes too long

As the design leader of a portfolio of 27 products of 7 different acquisitions at IBM, I faced a problem at a very large scale that a lot of products have to face - we needed to create product interfaces that bring consistency for disparate products, and we needed to make development of the UI happen faster.

The idea: Bigger lego blocks My big idea was simple, and came from my engineering background: we needed to create a library of common building blocks, like lego pieces, that can be standardized and reused again and again to build a user interface. Having standardized interface pieces would also provide consistency and reduce error that comes with creating bespoke interface elements individually.

Luckily, I was at IBM. The year was 2012. I knew we needed bigger lego blocks to be better. And IBM could do things at a big scale. I didn't know it then, but this would soon be known as: A design system. (Footnote: Google first used the term "design system" for their Material Design in 2014.)

Like many large companies at that time, IBM had a "design system" of sorts (it had a different name then), but it had a few problems:

• Components were built using an old, increasingly outdated language. UI languages were being released constantly and engineers were forced to make a choice: use an outdated UI language, or build it yourself. Idea: Make the components language specific, but build a structure that could span languages over time.

• Components were too detailed, and too specific. We had a lot of products that needed to have specific options - one product may require a simple data table, and another product may require a data table that incorporated complex objects like graphics and buttons. We needed to have common components, but we also needed to have options for those components. Idea: Create "core components" with options/states that could be enabled/disabled, and grow over time.

• Components were built and controlled by a single group within IBM. Getting anything done required requesting a change, which took months, sometimes years, to happen. Innovation happened at a glacial pace. Idea: Operate the design system like an open source project and allow anyone to contribute, both within IBM and outside IBM.

Idea 2: Enable it across IBM

I wanted to build bigger lego blocks, but I also realized that if we were having this problem, probably all of IBM was having this problem as well. Talking to various business units within IBM (some business units are the size of large corporations), I realized that my hunch was true: everyone was experiencing this problem, and we needed to revolutionize the existing system and promote it to all IBM business units, business partners, and perhaps even customers.

Get buy-in from IBM Leadership

Since IBM was such a large company (it had 430,000 employees in 2012), deploying a design system like this, even if we were to fund it and build it for ourselves initially, would require adoption from the top. To have it adopted across business units, I needed the idea to be promoted by the CEO. I went through the process of presenting my idea to the CEO, which is akin to presenting in front of a world leader.

I decided to be myself. Also: OMG, I dropped an F-bomb As I presented the idea to the CEO, she looked up at me and said "is this a big deal?"

This is the CEO of IBM, standing 3 feet in front of me, along with 100 other leaders across IBM, VERY PUBLICLY QUESTIONING MY BIG IDEA. In that moment, I decided to go with my gut and really champion this thing I knew was important to the future of this very large organization. I stepped forward and said "yeah. it's a BIG deal. A big f***ing deal." I glanced over to my boss who was watching me from the sidelines, obviously scared for me, but also simultaneously somewhat impressed. He knew this was my baby, my passion. And he encouraged me to be myself, so I was going with it.

And voila, The Carbon design system was born. (Full disclosure: We had a different name for it then. Carbon is a much, much better name). My team spent a few years building it (thank you, Sophia et al) - and we were able to create interfaces in a much better, more standardized way... much, much faster.

Big Idea 1: Support the latest language My team of designers built the components on react in 2013 (a newly open source UI language at the time), but we realized something important: front-end languages are ephemeral, and the design system would need to support the latest design language, whatever that becomes over time.

Big Idea 2: Make components generic and extensible

Using the latest front end technologies, the designers on my team created components that are similar to what we all use now - drop-downs, lists, tables, etc. But over time, these components got bigger and bigger, and incorporated the most important elements, like the ability to support many languages, and accessible. And while these components were quite generic from our point of view, they still had a point of view - let's make these generic, but yet simple. Don't let designers modify the components to the point where they are no longer usable.

Big Idea 3: Contributions should be open-source

Even though my team was creating these components to start, I realized that many teams within IBM had the same problem. As a business unit within IBM, we had a very large development organization. But as IBM, we had access to tens of thousands of developers that we could leverage to create these components, so I wanted to make sure that we leveraged them effectively.

Many, many versions later, Carbon came into existence. It continues to evolve every day. But the idea came from a simple need - to build better, faster.