Carbon for AI: Scaling New Ways of Working
As technology evolves, the pace and scale at which designers and developers are expected to work increases with each passing cycle. Those in the UX industry, especially product managers, rise to meet this challenge by constantly retooling processes around product development and delivery. IBM is no exception.
Design systems like Carbon at IBM, provide one way for organizations to streamline design decisions at scale across millions of software screens. For those unfamiliar, Carbon is IBM’s open source design system for web and software; it’s the chassis for IBM’s entire software portfolio, with over 100 reusable components and patterns. However, even with a robust design system, teams still face challenges. When new, urgent demands come along and rock the industry, subject matter experts become enormously reactive and often revert into their silos to devise bespoke solutions.
As leaders on the Carbon team, it’s our job to get ahead of this siloing, to avoid millions of dollars’ worth of duplicated effort — not to mention the increased cognitive load for our users due to visual and functional dissonance.
Design wonks, I’m going to stop you here. This is primarily a process article (though I’ll throw you a few bones). Below, I’m going to detail a cross-team lean, agile process that our design system team spun up to meet the unique needs of AI. To level set, you’ll often hear the term “Lean” and “Agile” or “Agile Scrum” lumped together under the agile umbrella. Lean focuses on reducing waste and delivering maximum value (which we’re maniacal about on Carbon) and agile emphasizes flexibility, collaboration, and iterative development. It’s easy to see how these two methodologies complement each other by focusing on the quickest path to value for both users and the business.
The Initiative
Now let’s talk about how the Carbon team helped IBM’s AI experts deliver and operationalize a distinct point of view on AI design.
In summer of 2023, IBM released watsonx, a cloud-based generative AI and scientific data platform that includes a studio, data store, and governance toolkit. As part of an overarching effort to drive watsonx adoption across software, IBM executives tasked their AI subject matter experts to integrate generative AI into the product portfolio, through Carbon.
Note: Writing about AI is hard, because there’s no shared history and people either tend to know a lot about it, or very little. To be clear, we did not build assets WITH AI, we designed an AI theme (with old-fashioned elbow grease), to indicate to users that they were interfacing with AI suggestions or AI results. I’ll talk more about the specifics of what we delivered below.
Discovery
Initially, the Carbon team was only tangentially involved in the discovery phase. AI leadership assembled a cohort of 8 sponsor-user product teams, and a dedicated, highly-empowered team of UX designers and researchers from across the business. The team was backed by executive stakeholders who were ready to trust them and clear their path.
Upon kick off, the AI sponsor users joined weekly syncs to share their product needs in the AI space with the team. With so much skin in the game across software, the team quickly identified areas of mutual benefit, allowing them to stress test and drive impact much faster.
A Carbon Design System stakeholder was present on these early calls and realized that Carbon needed deeper representation in this discovery phase to ensure consistent system logic. We immediately diverted one of our most experienced Carbon Design Principals to embed with the AI workgroup. Our designer ensured that the new AI team both understood the design system and flexed within it as much as possible. Her expertise in tokens and component theming, helped them lay a solid foundation for implementation.
Our primary driver was reuse. We had to help our product teams integrate AI without reinventing the wheel 10 times over. To do this, we honed in on efficiency in our own process. Figma helped us move fast together (without hours of cumbersome playbacks and blind hand-offs) by providing a forum for asynchronous feedback and discussion. Even those not involved in the work could easily follow along with the team’s progress.
As our designer joined the fold, the team built out an AI Essentials Figma kit; the kit offered inline UX and UI guidance, along with the beginnings of a unified perspective on the visual expression and behavioral building blocks of the new Carbon for AI design language.
Extending the system
Designing for AI poses completely new challenges for digital designers; it requires us to take note of new contexts and to change the nature of our design considerations. The fact that users can interact and effectively, collaborate with AI at any level of an experience, further complicates things.
As IBM software designers, it’s our job to ensure that users know when they’re interfacing with AI and understand its limitations, to prevent a breach of trust. Clear and accessible visual cues are crucial to help users distinguish AI-generated content, and some degree of explainability must be offered in every scenario. Recent AI guidance from the Biden administration and the EU’s pending AI Act, highlight the need for transparent and accountable AI systems.
At the same time, the AI components still inherit the same fundamental principles as the current Carbon components, while standing apart from them stylistically. This way users can immediately recognize AI-generated or AI-recommended content, while benefitting from the best practices already established by the Carbon library. The Carbon for AI designers played with gradients to simulate light, as a metaphor for illuminating users. They also used depth and radial edges to accomplish this visual separation. We began calling the initiative Carbon for AI.
Mere months after the initiative kicked off, the team released the Carbon for AI Essentials Figma kit internally to all of IBM software. The kit characterized the Carbon for AI styling, or theme, as two primary elements: the AI label and the AI layer. When combined, these elements distinguish AI content in a consistent, accessible, and explainable way.
- The AI label
The AI label component reinforces transparency and identification of AI by explicitly labeling any instances of AI and providing an interactive, consistent path to explainability across modalities.
- The AI layer
The AI layer is the foundation of the unique visual and behavioral characteristics that distinguishes AI elements from non-AI elements. It is designed to coexist alongside baseline Carbon components.
Delivery
Though the kit was effective as a source of truth for product teams to rally around, there wasn’t a lot of front-end development representation on the AI cohort calls. Not including developers early on, often has costly ramifications on the delivery phase — erasing any gains made during a lean discovery.
As Carbon leads met with AI cohort engineers, we realized that several sponsor-user products were either not running the latest major release of Carbon, or not building with React — Carbon’s officially supported framework. This challenge posed an opportunity for the Carbon team to expand adoption of our newly launched Carbon Web Components library. Web Components provided an immediate solution for these teams, allowing them to embed the new AI components directly into their products regardless of version or framework.
Once we settled on this implementation strategy, the Carbon leads stood up a lean-but-mighty Carbon for AI tiger team that consisted of a few of the UX designers from the discovery phase, flanked by a product manager, and several front-end developers (versed in both React and Web Components).
Again, we commingled resources from various product teams to join designers and developers from Carbon’s own long-standing squads to make up the tiger team. Leaning on an “away mission” model that we’d used in the past, Carbon wrote up a clear scope of work (SOW) for the contributors on loan from other teams. We also aligned on deliverables and a timeframe to protect against scope creep. The SOW stated that AI styling would be enabled (as React and Web Components code) in 15 prioritized Carbon components by the end of 2023.
The developers began with the AI label, the first and most crucial component added to the Carbon code libraries from this effort. Then they created tokens for every new color or attribute that the AI layer introduced into the system. Once the tokens were made, the developers used Sass mix-ins to output the style attributes that appear in the AI-layer enabled components. Now whenever a developer passes the AI label prop into a component, the prop will call a mix-in to apply the AI specific styling (e.g. the linear-gradient background).
With the token and mix-in scaffolding in place, our AI designers could incorporate feedback and continuously refine values like opacity and color, without causing a major code refactor. In anticipation of integrating these tweaks into the development release cycle, the AI label and AI layer-enabled components were added to the Carbon React and Web Components storybooks under a feature flag. This flexibility allowed us the time to test and get it right.
The Product Development Lifecycle (PDLC)
The Carbon for AI work sparked a change in the way we collaborate across teams. Although this article is more about our process than the particulars of the work — the pervasive nature of AI absolutely demanded continuous learning while we built.
As we retooled our process intuitively to accommodate Carbon for AI — leaning heavily on agile scrum practices — IBM debuted a new process framework called the Product Development Lifecycle (PDLC). IBM defines the PDLC as the process of taking a product capability from an idea through its development and release to market, and beyond. Since product development takes place in a continuously evolving market, the framework creates room for validation in every phase of the lifecycle.
The PDLC is organized into three phases: discovery, delivery, and launch and scale. Once a product is in market, agile product teams do all these types of work concurrently, in parallel work streams, with feedback from in-market learnings shaping the priorities of both discovery and delivery.
As we began to map what we were doing with AI onto this new framework, we realized we really had something solid. Ironically, the Carbon team was working neatly within IBM’s Product Development Lifecycle (PDLC) — without knowing it — but adding its own cross-team flare.
Carbon leads know our team is especially good at organizing the delivery and launch and scale parts of this framework. We run agile scrum like a product team and Carbon’s cross-functional leadership ensures that we prioritize and execute work through the lenses of Product Management, Design, and Engineering simultaneously. This gives us credibility across IBM Software.
However, we know our weaknesses too. We need to pair with UX Researchers and subject matter experts from product teams to truly accelerate the discovery phase — like we did with the AI work. We also nail down asset ownership BEFORE we spin up a delivery team, provided it’s not us. For instance, the Carbon team is not equipped to maintain assets that aren’t sufficiently abstracted or would better be classified as applications.
Scaling new ways of working
Although its still early days (this work just debuted at THINK 2024), Carbon’s collaboration with product subject matter experts was widely considered a triumph of process. Everyone involved felt an incredible synergy due to the shared accountability and transparency throughout the discovery and delivery phases. This approach has become Carbon’s go-to for high-priority projects with short timelines, which speaks volumes about its effectiveness and adaptability.
Meanwhile, as IBM’s generative AI initiative continues to unfold, both the nature of our jobs, and the way users experience our products, are slowly but steadily changing in ways that no one in the industry can fully anticipate. These advances in technology will reshape not only the tooling and our output, but our processes as well. Continuous learning extends beyond just the final product — it encompasses the ever-changing dynamics of the design process itself. I hope this article provides valuable perspectives for those navigating similar terrain.
