11 Powerful Lessons on Building and Scaling an Enterprise Design System

In May 2022, UXPin had the pleasure of hosting the lovely Amber Jabeen, DesignOps Director at Delivery Hero MENA (talabat), for a webinar titled: Enterprise Design System – How to Build and Scale.

This article summarizes part of Amber’s talk where she discusses her team’s challenges with getting design system buy-in and what she would have done differently.

Amber is a co-author of UXPin’s free eBook DesignOps 101: Guide to Design Operations. The book covers six chapters and provides an introduction to DesignOps and how to implement the practice.

Build, scale, share, and mature your design system in UXPin.

What Most Teams do to Win Design System Buy-In

In 2019, Delivery Hero was undergoing the all too familiar growing pains that many startups experience. Delivery Hero had nine teams working on the product with no UI library or design system. The startup had developed silos, and there was lots of duplication, making it difficult to scale, resulting in a “highly fragmented user experience.” 

Amber and her team decided a design system was the best solution to their problems. So, they set about creating a case to get buy-in from stakeholders.

Run a Design Audit

Delivery Hero’s product team started with a design audit. The audit report revealed many user interface inconsistencies, including:

• Several different CTAs
• No typography styling standards
• Multiple icon styles

Amber notes in her talk, “…our design language was all over the place. This was a big moment of realization.”

The team used the audit report to build a business case and presented it to Delivery Hero’s leadership, resulting in buy-in to redesign the app.

The product team started by redesigning key screens and user flows. The new design was more consistent, cleaner, better aligned with the brand, and improved the user experience.

Build a UI Library With UI patterns

The product team used the redesign to create a UI kit and style guide, including colors, typography, elevation, UI patterns, and components.

Delivery Hero’s product department scaled, onboarding new designers. Amber notes that even with this growth, consistency improved across Delivery Hero’s design projects, and they were able to scale design.

First Attempts at Building a Component Library

Having successfully designed a source of truth for designers, Delivery Hero’s product team wanted to do the same for engineering. Amber and her team put together another business case for a component library.

The business case outlined the core benefits of a Delivery Hero design system:

• A single source of truth between design and development
• Better user experience
• Strengthened brand affinity
• Faster experimentation, prototyping, and testing

Delivery Hero’s leadership liked the presentation and saw value in the product team’s proposal, but the answer to building a code component library was no! There was no money or resources for a design system.

Rethinking the Approach

Amber’s team went back to the drawing board. They decided to ship their new designs using the style guide to the entire app. The project took three months and was a huge success for the product development team.

Over the next six months, Delivery Hero shipped lots of new features and experiments. The product team’s new designs were fresh and consistent. The problem was, without a source of truth for engineers, Delivery Hero’s final releases lacked cohesion and consistency.

The product team decided to do another series of audits. They took screenshots of design handoff vs. production, which revealed many inconsistencies, including missing content and UI elements. These audits showed that Delivery Hero was collecting debt with every release.

Building a Convincing Case for Delivery Hero’s Design System

Delivery Hero’s design system team didn’t have any engineers, so they had to partner with a developer to build and test a component for their new pitch to leadership.

Amber’s team built a component for Delivery Hero’s ‘No results’ screen and experimented with vs. without a design system:

• Building without a design system – total time: 7.5 hours
• Building as a reusable component – total time: 3.25 hours

The product team only recorded front-end development time. The experiment demonstrated a 57% time reduction in front-end effort and zero percent debt with a reusable component.

Amber’s team used this new data to present another case for building a component library. Delivery Hero’s leadership was impressed by the results and gave the go-ahead to develop a design system.

Today, Delivery Hero’s design system, Marshmallow, has 30+ components in its UI kit and code UI library managed by a dedicated design system team–unifying design and development with a single source of truth.

Marshmallow includes:

• A design system website
• A dedicated Slack channel
• Guidelines (brand, code, design, copy, etc.)
• Design language
• Protocols for working and communicating
• A code component library
• An icon template
• A UI kit
• UI examples
• Design system governance procedures

Learn how to create a design system from scratch here: Design Systems: Step-by-Step Guide to Creating Your Own.

Getting Buy-In and Scaling for Building an Enterprise Design System

Reflecting on lessons learned, Amber offers six pieces of advice for getting buy-in for an enterprise design system.

Start with a real pain point

Identifying a pain point that’s adversely impacting the product, users, and business is a crucial first step. Amber and her team used an auditing system to identify a significant drift between design and development.

Build the value proposition

Use the pain point(s) to build a value proposition for your business case. Your solution must solve the problem and deliver a return on investment for stakeholders.

Identify your biggest supporters and sponsor

Amber recommends finding support from other departments to back your design system pitch. These advocates will support your claim that 1, “this is a real problem for the company,” and 2, “this is the best solution.”

Show before you tell

Amber says the mistake she made in her first pitch was telling a story without proof. When the team showed stakeholders what a component library could do, their story became more compelling, and the business case was convincing.

Talk business metrics

“If we don’t tie the business case of the narrative with KPIs or the metrics that impact business, then the story is not complete.” Amber Jabeen

Amber says your business case must include design system metrics to demonstrate how the problem costs the company resources and what the solution will do to help.

Don’t go alone – build your network

Pitch your business case as a network of cross-functional partners, including tech, design, product, marketing, customer services, etc., to demonstrate that your design system is a solution for the organization and not just something to make the design team’s life easier.

Watch Amber’s entire one-hour webinar on YouTube.

Code-Based Design Systems With UXPin

Sync your design system’s component library with UXPin’s editor to create a single source of truth between design and development using our proprietary Merge technology.