Design System for Global Beverage Company
(6 months)
Summary
A global beverage and brewing company partnered with Insight to build a design system from the ground up. The client has hundreds of brands across many countries and its teams are geographically dispersed, with project work often outsourced to third-party vendors. Without a cohesive design language, the client started experiencing the following pain points:
Inconsistent end user experiences. Many applications crossed platforms (web, iOS, Android) which added complexity, and had inconsistent UI elements with varying functionality leading to usability problems.
Increased deployment and development overhead. The lack of global design language and standards led to duplicative efforts across teams, reduced start-up velocity, and reliance on “tribal knowledge”.
Scalability. As new business needs and user needs emerged, teams struggled to scale quickly, leading to inconsistent project and design approaches.
Insight worked closely with the client during the early stages to understand their current state environment and pain points. This ensured that everyone was in alignment on the solution - to build not only a design system, but also include a governance strategy for adoption and maintenance of the design system, and provide design best practices and resources to the client's diverse project teams.
Project Details
What is a Design System?
A design system helps make design more reusable. It is a collection of reusable components (like buttons, drop downs, text fields, etc,) plus guidelines and standards for use of those components. Components are the building blocks of design. The benefits of a design system are:
Single source of truth. The central place for design guidelines, a library of components, detailed specifications for components, code, UX/UI best practices, and more.
Scalable. Can be easily adapted and applied to many applications, products, or brands.
Consistency. End users benefit from cohesive & consistent experiences across different products/applications
Teams stay in sync. Helps team members get onboarded quickly. Ensures that developers, product managers, QA, designers are using a shared design language.
Project Scope
As the lead designer on the project, I was responsible for:
Design System. Providing guidance and support to the design team as they coordinated creating 30+ components across platforms (web, iOS, Android), including UX and development guidelines.
Design Thinking Resources. Creating design and delivery project guidelines, including best practices and downloadable templates for use by the client’s diverse project teams.
Governance Strategy. Creating the governance strategy for the design system, including support, adoption, communication, release management, and recommended team structure.
Design System (called MALT)
The team partnered closely with the client during the early stages of the project, aligning on scope and reaching a shared understanding of the philosophy and principles behind the design system. The design system, called “MALT”, was broken down into the following sections:
Get Started resources, including,
Design Thinking Resources. Some of the client’s pain points stemmed from the lack of a cohesive, consistent approach to scaling up projects and not starting with a user-centered mindset. The Design Thinking Resources section fills this gap, providing an overview of the design thinking framework, its phases, and the activities that should be done in each phase. The MALT design system is intended to be used in tandem with these design-centric best practices.
Designer Toolkit. Includes information for designers on how to use MALT, a downloadable Sketch library of components, and an introduction to the Abstract versioning & collaboration tool.
Developer Toolkit. Includes information for developers to get setup across platforms (web, iOS, and Android), and information on the component library, Syncfusion.
Foundations section, which combines existing guidelines and standards from the client into one central source. The team filled in gaps where needed.
Includes guidelines on Brand, Color, Typography, Iconography, Photography, Accessibility, Globalization.
Layouts & Patterns section, which covers guidelines for things like responsive layouts, grid systems, menu and navigation functionality and placement, modal usage, etc.
Components section, which includes 30+ components across web, iOS, and Android.
Each component page has an overview, an example of the component in context, guidelines for color usage, states, sizing, spacing, do’s & don’ts, and sample code for developers.
Click through sample screenshots from the MALT Design System below.
Design Thinking Resources
As mentioned, many of the client’s pain points arose because project teams did not follow a user-centered approach. Teams also lacked guidelines for how to consistently start projects and ensure they were solving the right problems for their end users.
The Design Thinking Resources section of MALT addresses this pain point, providing an overview of design thinking, why it’s important, the phases and activities that should be followed, plus resources and examples to help teams get started. The Design Thinking Resources are intended to kick-start projects and be used alongside the design system itself.
I led the creation of the Design Thinking Resources section. Additional screenshots shown below.
Governance Strategy
A question often overlooked when building design systems, is what happens after it launches? Our client understood the importance of governance and maintenance of the new design system. I was responsible for creating governance recommendations for the MALT design system, including:
MALT Team Structure
Adoption Strategy
Communication Strategy
Release Management
Review & Approval Process
Click through the final governance recommendations below.
Project Challenges & Learnings
Overall organization of components and naming conventions for components between web, iOS, and Android proved challenging. Many conversations were had about how to reconcile the same component that was called three different things across the various platforms. The team ultimately decided to add a “Disambiguation” section to those components where naming caused confusion.
The team constantly balanced the natural tension that arose between the need for flexibility and the need for standards. We strove to allow flexibility & autonomy while also providing usable guidelines, frameworks, and standards that weren’t overly prescriptive. This held true for both the design system itself and the governance recommendations.
Towards the close of the project, the team recognized the pitfalls of designing in a vacuum - designing the system without real sample applications to evaluate. As part of the governance strategy, we recommended that the client address this gap by beta-testing MALT with an existing project. This will allow the MALT team to capture and prioritize feedback and implement fixes before launching more widely.
Finally, close collaboration between technical counterparts, designers, and the geographically dispersed client team led to a better product. This took some time to get right, but had a huge impact on velocity and quality of the final solution.