Universal Design System
New York Life
A UX case study exploring the design of a robust foundational framework for an enterprise-level design system, resulting in 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 for internal stakeholders, prioritizing scalability, speed, and efficiency. 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 leading Design System Architecture (Toolkit Mapping) and Design-to-Dev Handoff Strategy, and contributed to Component Construction, and Branding
Project Duration
June 2023 to August 2023 (12 weeks)
Project Team
Program Manager// My-ha Moon
Principal Designer// Yuko Osawa
Design Leads// Matthias Dittrich, Michael Shea
Designers// Aditya Surendranath, Liza Comley, Lex Mensah, Ons Charrad
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 finance 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 design system for internal teams that ensures consistency, seamless scalability and efficient reusability of components across New York Life's diverse array of products & platforms, while prioritizing faster speed to market and maintaining team autonomy?
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
Identifying End Users
The primary end users of the design system fall into two categories.
Enablement teams, composed of designers and 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
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.
Steps taken to determine the most appropriate design system strategy can be summarized as:
-
Conducting desk research across 25+ 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 product teams.
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:
-
Component Parity and Atomic Builds: Discrepancies surfaced, where certain AEM components were missing in design toolkits, and vice versa. Authors circumvented this by atomically creating components using combinations, fostering inconsistencies.
-
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.
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.
Innovating Cascading Inheritance
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.com, 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)
I. 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.
II. Figma for UI Kit
The universal design system components will be in Figma, distributed across multiple libraries due to file size limitations.
This approach encourages a system-of-systems style governance, where designs flow into one another, forming a cascading design ecosystem.
The primary challenge in UI kit implementation was crafting its architecture. This involved implementing the cascading library concept, which included:
-
Preventing component duplication across different levels.
-
Minimizing the number of required UI kits.
-
Establishing relationships between kits matching the style guide's taxonomy.
Moreover, the year was 2023 - Figma introduced the 'variables' feature. Consequently, the architecture had to fully leverage this new feature to ensure future-proofing.
Planning out the UI Kits
Three models for UI kit structure.
In the first model, all universally used NYL tokens across all style guides would reside in the base library. Platform-specific tokens, on the other hand, were intended for the platform library. However, executing this model proved challenging.
In the second model, only common tokens were placed in the base library, which then cascaded down to lower levels. This was the ideal approach and more straightforward to implement.
However, a unique case arose with NYL, highlighting that independently managed platform libraries had distinct tokens not found in the base or channel libraries. This necessitated a specialized model to address the kit architecture.
Base does not need a library.
In this model, 'Base' represents the entire brand, and the common elements shared across all style guides are limited to as few as just two colors and two typefaces. This doesn't warrant a separate library, as each additional cascade would impose unnecessary memory overhead.
Ultimately, the UI kit architecture should include platform-specific libraries aligned with each platform documentation and a web resources library where all tokens are housed.
While a Web UI Kit Template could be beneficial for future platforms, it's not currently a top priority.
Exploring Cascading Structures in Figma
The UI kit model can manifest in several different ways, with the following models appearing to be the most optimal, but each with its own pros/cons.
Pros: Organized, Versionable
Cons: Complex cascade/updating process, kit file sizes
Pros: A la carte system, don’t have to worry about versioning
Cons: Not organized, limited version tracing, kit file sizes
Pros: A la carte core files, simpler cascade
Cons: Hard to version trace, What happens if/when Web kit comes online? Kit file size.
Pros: Simplest cascade and file structure
Cons: Versioning isn’t clean, Limited What happens if/when Web kit comes online?, kit file size
The Final UI Kit Architecture
The chosen architecture for the UI kit is a slight modification of Structure E, which was deemed the most simplified representation of the existing NYL ecosystem's relationships.
Prototyping & Stress Testing Figma Library
My current scope for developing the toolkit architecture concluded with the establishment of the library files within the Figma project folder.
The Web UI Kit was given lower priority in this scope. The only addition not previously discussed is the Utility file, an internal file housing design system housekeeping components.
Learning Outcomes
Scalability is Key
Designing a scalable system required thinking big and simplifying complex workflows. By ensuring flexibility while maintaining core consistency, I was able to invent and simplify a solution that could evolve with the business.
Cross-functional Collaboration is Essential
Taking ownership and earning the trust of diverse teams was crucial. Through close collaboration with developers, designers, and other stakeholders, we ensured smooth adoption and integration.
Adaptability Drives Success
Being agile was key to driving quick iterations and delivering results. By designing with adaptability in mind, we improved efficiency and ensured the system could evolve with new features and platforms, meeting both internal and external stakeholder needs.
UX Design / UX Research
How we addressed the issue of sustainability in the furniture industry by leveraging IKEA’s existing framework to offer sustainable and affordable furniture options.
IKEA Sustainability
an eco-friendly refurbished marketplace
Sustainable Strategy
Product Design
Usability Testing