CommBank’s Design System Journey 

The presenter: Gordana Gorgiojski, Senior Product Owner for the Design System at CBA

The talk: Figma webinar on CBA’s journey to create a robust and scalable design system using Figma and design tokens. 

The team: Gordana, who began at CBA as a UI designer and later a chapter lead, now leads a 15-person design system team, including a BA, a QA, an engineering lead, 3 web engineers, 2 iOS, 2 android engineers, a design lead and 3 DS designers.

This team supports a vast network of 140 designers and over 400 engineers.

The case for change

Two years ago, coinciding with a brand evolution, CBA reached a tipping point. Their existing design system, “Honeycomb,” faced challenges:

• Design and code were misaligned. Designers used styles in Figma, while engineers used manually mapped tokens in Confluence, leading to inconsistencies and inefficiencies. Parity between design and code were needed as the effort to document design specifications had become unwieldy.
• While component adoption was high, similar patterns proliferated across code as the design system team couldn’t keep up with requests. This created duplication of similar patterns across code and maintenance headaches.
• Designers needed guidance one to one support was unsustainable. 
• CBA’s move to Swift UI meant their existing Honeycomb components needed a complete refactor.

CBA Design System 2.0 

To address these challenges, CBA embarked on building “Lumen,” a new design system that would:

• Refactor components for Swift UI.
• Implement design tokens for consistency and scalability.
• Apply the new visual language from the brand evolution.
• Expand to include complex components and templates to accelerate design and development.
• Provide a comprehensive, self-service guide for designers and engineers to scale what previously required one to one support.

To help manage the change from Honeycomb Design System to Lumen the team shared their approach, timelines, and granular outcomes with the wider CBA design community. They showcased the benefits of Lumen through showcases and recruited “champions” to share their experiences and results including the capability uplift and outcomes.

The approach to rebuilding the design system included: 

• Breaking down a massive undertaking into quarterly goals
• Prioritising frequently used components starting with a base set of components to provide immediate value.
• Collaboration and iteration with pilot teams. This helped define a hybrid operating model (think “open source software”) so any team could contribute to the design system with the support of the central Design System team and fast track its ongoing evolution.
• Defined quality standards for components with design and engineering acceptance criteria, and accessibility requirements (see process diagram and the handshake checkpoints :).
• A token structure that worked for everyone that they arrived at through research, testing, and dialogue.
• Showcases to communicate what to expect and create hype around launching of libraries 
• Managing Lumen the Design System as a product itself, with dedicated support channels, front door “request form”, office hours, and self-guided training. The “Lumen guide” was created as a self-service one stop shop which included guidance on how to get started, contribute,  dos and don’ts for use of components, and self guided training files with challenges that could be done in people’s own time without fearing they would break anything.

Measuring satisfaction to guide development 

CBA measures Lumen’s success through customer (DS user) satisfaction scores, adoption rates, and component usage statistics. These insights inform their priorities and guide the development of masterclasses and support resources.

Things to think about

• The concept of thinking about a design system as a product isn’t new but the CBA team showed that products need product support channels.
• Prioritisation was informed by component adoption and a practical approach to start with the basic building blocks.
• They had a theory of change that covered the rebuild, its launches and beyond with communication of rollouts, feedback for improvement and education. 
• While a design system needs a team of custodians they can quickly become a bottleneck and run out of capacity to keep up with requests. An open source operating model invites contributions and makes the sustainability and continued evolution of a design system possible and viable. 

Want to learn more from the good folks at CBA – check out this excellent talk at quality at scale: https://www.youtube.com/watch?v=XCglPTbMpUM&ab_channel=Figma