Read the full article that contains 11 lessons on UXPin’s blog: 11 Powerful Lessons on Building and Scaling an Enterprise Design System.
1. On preparing for a design system
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.
2. On building 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.
3. On creating 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.
4. On tracking inconsistencies
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.
5. On building a case for a 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.
6. On getting buy-in and scaling
Reflecting on lessons learned, Amber offers six pieces of advice for getting buy-in for a design system. Check them out in the original article that appeared on UXPin’s blog: 11 Powerful Lessons on Building and Scaling an Enterprise Design System.
