Universal Design System
New York Life
A UX case study encapsulating the formative phases of an enterprise-level design system, leading to the creation of a comprehensive toolkit architecture, component construction practices, and design-to-dev hand-off strategy.
A fast-paced project that taught me the process of building a robust and scalable enterprise-level design system. It revealed the transformative potential of systems thinking in crafting a future-ready design system that thrives in complex constraints.
Roles & Responsibilities
Designer responsible for Design System Architecture (Toolkit Mapping), Component Construction, Design-to-Dev Handoff Strategy & Branding
Project Duration
June 2023 to August 2023 (12 weeks)
Project Team
Principal Designer// Yuko Osawa
Program Manager// My-ha Moon
Design Leads// Matthias Dittrich, Michael Shea, Anna Belotti
Designers// Liza Comley, Lex Mensah, Ons Charrad, Aditya Surendranath
argodesign (Team spread across 3 studios - Austin, New York & Amsterdam)
Tools
Figma (including Dev Mode), Zeroheight, Zeplin, Adobe Experience Manager, Jira
01. Context
New York Life is a distinguished Fortune 100 company with 175+ years of history in financial services backed by a network of 12000 agents.
NYL has a complex digital ecosystem with products that serve different needs and end-users, implemented across a range of technical architecture scenarios (AEM, SaaS, apps, etc.) by independent product teams.
Teams have been encouraged to remain autonomous to prioritize speed to market, which has resulted in multiple design systems and even more one-off design artifacts that fall short of serving as a mature and scalable system.
The technical architecture is implemented on diverse platforms.
Each platform brings its unique set of native components and construction limitations into the mix, leading to a noticeable lack of design consistency.
02. Problem Statement
How might we craft an enterprise-level universal design system that ensures consistency and seamless scalability across NYL's diverse array of products and platforms, effectively addressing the complex business challenges, within the unique constraints faced by the enterprise?
03. Scope
The immediate scope of my direct involvement in the project includes:
-
Establishing a future-proofed design system framework capable of seamless scalability across the extensive range of current and future NYL products.
-
Developing a comprehensive design system, housed within this framework, specifically tailored for NYL.com, the enterprise's flagship product implemented in AEM platform.
04. Design System Strategy
A design system is a toolkit. But it isn't just a toolkit.
It encompasses processes and tools that foster collaboration among its users. Governance, contribution, and adoption emerge as pivotal processes in making a design system operational.
End Users
The primary end users of the design system fall into two categories.
Enablement teams, composed of developers, are responsible for implementing and maintaining the design system components, ensuring its technical infrastructure and documentation are robust and accessible.
Authoring teams, mainly consisting of content specialists, are primary users of a design system, utilizing its components and patterns to construct final web pages, apps, or content with consistency and efficiency.
Research
Steps taken to determine the most appropriate design system strategy can be summarized as:
-
Conducting desk research across 100+ publicly available design systems.
-
Synthesizing learnings into key insights, which were validated with key stakeholders.
-
Conducting research with 17 NYL stakeholders (using CMS & and SaaS platforms) across a sample of design systems.
Initial Challenges
The initial set of challenges in framing a cascading design system was threefold:
i. Integrating legacy systems
Cascading inheritance can be implemented seamlessly in cases of ground-up redesign of the entire design system, which is rarely feasible in real-world projects that come with legacy systems.
ii. Adapting legacy systems to meet 4-tier needs
AEM had an extensive set of existing components that the client was reluctant to modify due to longer approval processes as observed in enterprises. Therefore, We needed to adapt our design system architecture to align with the legacy system while transforming it into the 4-tier structure.
iii. Findings from AEM Component Audits
An audit of the AEM components (30, of which I did 5) revealed more issues:
-
Mismatched Information Architecture: AEM's default taxonomy (e.g., Core, Integrations) may be perplexing to the average user. However, these terms are familiar to enablement and authoring teams – AEM's key end users – emphasizing the need for alignment.
-
Custom Components and Scalability: Custom components outside core categories (e.g., NYL.com-specific calculators, forms) might be useful beyond the product context. Placing them at the AEM level, not product-specific, could enhance cross-product usability.
-
Component Parity and Atomic Builds: Discrepancies surfaced, where certain AEM components were missing in DLS, and vice versa. Authors circumvented this by atomically creating components using combinations, fostering inconsistencies.
These challenges could only be effectively addressed at an architectural level, an area where I could contribute significantly!
The winner: "System of Systems"
A one-size-fits-all approach has been shown to fail in some large companies such as IBM & and Spotify, by creating bottlenecks to speed and innovation.
To be successful, NYL’s universal design system should adopt a System of Systems (SoS) approach. This flexible model allows design variations to co-exist with efficiency.
SoS requires sophisticated governance and contribution but research showed that it aligns with NYL's culture and can drive adoption.
The superpower of "System of Systems" is flexibility.
Cascading Inheritance Model
The SoS design system approach needs layers in which the children design systems inherit from their parent systems.
As the technical architecture becomes more specific, so does the design system.
For NYL, the cascading would look like:
Base
Channel
Platform
Local
05. Design System Architecture
Toolkit Mapping
Leveraging my strength in systems thinking and information architecture, I was tasked with the responsibility of identifying and structuring the toolkits that would constitute the final design system.
This involved defining the taxonomy (hierarchy and constitution) and ontology (interrelationships) of the toolkits from a holistic perspective, which required several rounds of huddles and feedback to conceive and perfect.
To simplify the process, I divided the toolkits into its two basic constituents:
1. Style Guide (Zeroheight)
2. UI Kit (Figma)
Zeroheight for Style Guide
Zeroheight was chosen for hosting the style guide due to its centralized, collaborative, and user-friendly platform that supports version control, integrates with other tools, and promotes accessibility and customization.
However, a deeper exploration of Zeroheight revealed an additional layer of complexity; Zeroheight supports only
4 levels of navigational hierarchy.
The levels are annotated in the Zeroheight screenshot of Decathlon's design system.
Nav bar item
Category
Page
In-page tab
An attempt to map down the cascading approach into the Zeroheight structure brought further clarity to the issue.
Ideally, each component to have its own page with tabs for guidelines, specs, and more.
Iterating Hierarchy on Zeroheight
I made a few iterations in Zeroheight, attempting to bring this to fruition by backtracking navigation paths starting with dedicated component pages as the endpoint.
1. Platform as the first level.
Pro: Ideal for daily usage since most users typically work within a single platform.
Con: Less user-friendly for onboarding members due to the prerequisite of prior knowledge.
2. Platform as the last level.
Pro: This hierarchy is good for first-time users to get a holistic understanding of the design system.
Con: Available components are not consistent across platforms, may have different names based on usage
The limitations of these iterations led us to recognize the necessity for multiple style guides to meet the needs of this extensive design system.
Shifting from Exploration to a Decision-making
The findings strongly support the use of multiple style guides in Zeroheight, as the platform allows for up to 10 style guides per account.
This posed a revised challenge:
Designing an efficient hierarchy that accommodates all future add-ons within the limit of these 10 style guides.
Decision 01: Base needs its own style guide.
Given the presence of multiple style guides, we determined that the 'base' should be hosted as an independent style guide since it serves as the foundation for everything else in the design system.
This leaves us with 9 style guides.
Decision 02: Channels get their own style guide.
With hundreds of products and more than nine platforms, the feasibility of platform or local-level style guides is eliminated. The most viable option left is to implement channel-level style guides, especially considering the current count of four channels, leaving room for future expansion, including wearables and more, among the remaining five.
Style Guide Hierarchy
With a clear understanding of the highest and lowest levels of the style guide architecture, we adopted a stepped approach to identify the relationships between the intermediate levels.
Step 1: Categories
Base, functioning as an independent style guide, would reside as a synchronized page within the Web Responsive Style Guide.
This arrangement enables the coexistence of Base, Web (a template for future platforms), and AEM within the global navigation. It effectively and logically addresses the issue of limited bandwidth in Zeroheight.
Additionally, each platform can have its own set of guidelines and components showcased in the left rail panel, with a dedicated page for each component.
Similarly, each new product within a platform can have its own category with components listed as pages.
Step 2: Pages
Step 3: In-tab Pages
Learnings from Stress Testing on Zeroheight
As with any design, the planned hierarchy had to undergo rigorous testing for robustness through prototyping and stress testing to account for edge cases.
Observable issues provided valuable insights into ways to enhance and refine the platform's construction.
A common landing page.
Multiple styleguides prompted a debate on where to begin the design system.
However, we found that Zeroheight's homepage option allows for a common introduction page for both first-time and expert users.
Foundation as a synced-paged.
Using the synced-page function treats the foundation page as a component that can be placed in various channel-specific style guides, saving the need to update it separately in each guide.
Hence, this falls outside the scope of web style guide set-up.
Web-responsive Style Guide as a local home page.
Although originally conceived as a template for future platforms, the web tab was repurposed as a channel-level home page listing principles and resources relevant to the channel.
Platform-level Style Guide as the functional space.
This page enlists all components along with an overview page that can graphically represent all components.
The 'Products' category links to product-specific pages housing local components.
These insights, together with the architecture, continued to provide invaluable guidance in shaping the future direction of the Style Guide development.
UX Design / UX Research
How we approached the common problem of feeling overwhelmed and unsure about what to cook for meals, especially for those with limited time and experience in the kitchen.
Cook Easy
an inventory-based pantry management app
Information Architecture
UI Design
Personalization