Snowball Design System

Product: Telus Health Virtual Care

Modernizing a scalable, accessible design system for web and mobile platforms.

I owned the Snowball Design System end-to-end, from system audit and research through architecture, token strategy, component standards, and documentation. I set the quality bar, defined system structure, and guided how teams adopted and scaled the system.

This case study covers the architected Snowball Design System infrastructure that scales craft, speed, and quality across TELUS Health virtual care products on web and mobile platforms. I led the restructuring of the system’s architecture, token strategy, and component library to reduce duplication, improve accessibility, and enable scalable reuse across teams. By introducing clear information architecture, token-driven styling, and governance guidelines, the system became easier to adopt, faster to use, and more reliable as a single source of truth for designers and developers.

My Role

Senior UX/UI Designer and Design System Lead

I owned the Snowball design system end-to-end, from system audit and research through architecture, component standards, and documentation. I was responsible for setting quality bars, defining system structure, and guiding how teams adopted the system, including:

Leading the audit and consolidation of existing components and variants
Creating a scalable token architecture with color, typography, spacing, and radii variables
Redesigning components for accessibility, consistency, and performance
Establishing naming conventions and organizational structure for components and tokens
Partnering with fellow designers to align patterns
Facilitating workshops to gather feedback and drive cross-team adoption
Documenting component usage guidelines and decision trees
Ensuring parity across Web, iOS, and Android
Collaborating with development to validate feasibility and hand-off accuracy
Creating a roadmap for future enhancements and governance processes

Problem Statement

What wasn't working, and why it mattered

Snowball had grown over time without a clear system foundation. Components were added as needed, but there was no consistent structure, naming, or token strategy tying everything together.

Designers often recreated components or avoided the system because it was hard to know what was approved, how patterns should be used, or how designs would scale across web and mobile. Accessibility was not built into components, and guidance was missing, which meant issues were often discovered late.

Developers faced similar challenges. Incomplete documentation, missing semantic tokens, and unclear ownership made implementation inconsistent across platforms. Teams spent more time fixing and adapting components than building new product features.

As adoption grew, these gaps increased design debt, slowed delivery, and reduced trust in the system, creating a clear need for a more structured, scalable foundation.

Current State: Where the System Was Breaking Down

SYSTEM ISSUES

Fragmented components
Confusing and inconsistent names
Design values (colors, spacing, fonts) not reused properly
Limited token usage
Limited variable usage
Documentation was incomplete or hard to find
Governance needs: No clear ownership or rules for maintaining the system

DAY-TO-DAY PROBLEMS

Designers had to rebuild components again and again
Teams weren’t sure which design pattern to use
Platform inconsistencies
Designs looked and behaved differently across platforms
Accessibility was often fixed at the end instead of built in

RISK & OPPORTUNITY

The system became harder to maintain over time
Work took longer than it should have
Teams lost confidence in using the design system
There was a clear need to build a stronger, scalable foundation

Design Goals and Success Criteria

What success looked like before I started to revamp the system

Establish a clear system architecture that scales across web, iOS, and Android
Reduce component duplication and unclear pattern usage
Introduce a token-based foundation to support theming and accessibility
Make components easier to find, understand, and reuse
Improve accessibility consistency across components
Create documentation that designers and developers could trust and follow
Enable faster iteration without sacrificing quality or consistency

Research & Insights

What I learned by studying Snowball and other leading design systems

To understand where Snowball was breaking down and where it could scale, I reviewed the existing design system, analyzed usage patterns, and compared it with well-established systems such as Google Material, Microsoft, Apple HIG, Shopify Polaris, and Atlassian. The findings below highlight recurring structural issues that impacted speed, consistency, and trust in the system.

Key Research Findings

1. Documentation and usage guidance were hard to follow

In mature design systems, documentation clearly explains:

What a component is for
When to use it
When not to use it

In old Snowball design system:

Usage guidance was limited
Designers had to rely on guesswork
There were no clear do’s and don’ts components

This made it harder for new designers to adopt the system confidently.

2. Sidebar and page organization caused navigation friction

When reviewing other design systems, a common pattern emerged:

Each component has a clear, predictable place
Navigation feels intentional and easy to scan

In the old Snowball design system:

Components were grouped together across pages
Finding a specific component required prior knowledge

This slowed down everyday work and increased cognitive load.

3. Canvas content was dense and difficult to scan

Leading systems organize component pages so that:

Variants, states, and examples are easy to compare
Content is visually structured and readable

In old Snowball design system:

Canvases were crowded
Related information was spread across large areas
It was difficult to quickly understand how a component behaved

This made learning and reusing components harder than necessary.

4. Components lacked clear usage boundaries

From the research, it was clear that strong systems:

Explain when to choose one component over another
Provide guidance for common scenarios

In old Snowball design system:

Multiple components existed for similar use cases
There was no clear guidance on which option to choose
Designers often created custom solutions instead of reusing patterns

This led to inconsistency across products.

5. No clear process for component updates and changes

System Architecture

How the Snowball Design System was structured to scale

The Snowball Design System was re-architected as a layered system, where each layer has a clear purpose and responsibility. This structure makes the system easier to understand, adopt, and scale across teams, platforms, and products.

Rather than treating components as isolated assets, the system was designed as an ecosystem, built on shared foundations, powered by tokens, and governed by clear usage and update rules.

1. Foundations

The foundation layer establishes the base design decisions that everything else builds on. This included:

Clear typography structures created separately for Web, iOS, and Android
Standardized spacing, sizing, and layout principles
Platform-specific considerations to respect native behaviors and conventions

Separating foundations by platform reduced ambiguity and ensured designs felt native while remaining consistent.

2. Token architecture

A multi-layer token strategy was introduced to enable consistency, flexibility, and scalability. The system now uses:

Primitive tokens for raw values (color, spacing, typography)
Semantic tokens to express meaning (e.g., success, error, surface, text)
Component-specific tokens to control behavior and appearance at the component level
Mapped tokens to connect design decisions across themes and platforms

This structure allows global changes (such as theming or accessibility updates) without redesigning individual components.

3. Component structure

Components were reorganized so that:

Each component lives on its own dedicated page
Variants, states, and behaviors are grouped logically
Related components follow consistent naming and structure patterns

This made components easier to find, compare, and reuse, reducing duplication and guesswork.

4. Patterns and usage guidance

Beyond individual components, the system documents:

When to use one component over another
Common scenarios and edge cases
Do’s and don’ts for consistent application

Decision trees and examples were added to guide designers toward the right choices, especially in complex or ambiguous situations.

5. Documentation and governance

To support long-term adoption, the system introduced:

Clear documentation standards
Guidance on component changes and updates
Shared understanding of what is approved, experimental, or deprecated

This helped rebuild trust in the system and made ongoing evolution more predictable for both designers and developers.

Component Changes & Examples

Once the core structure of the design system was in place, the next step was to update the main components so they all followed the same rules. Each component was reviewed and cleaned up to remove duplicates, make its purpose clearer, and ensure it worked consistently across Web, iOS, and Android.

The updates focused on making components easier to understand, easier to find, and easier to reuse. This included improving names, organizing states more clearly, and adding better documentation. Instead of fixing components one by one, changes were made in a way that strengthened the entire system, helping teams build more consistent, accessible, and scalable designs over time

NEW DESIGN

1. Token Architecture

Introduced a complete variable token system, including:
- Primitive tokens
- Semantic tokens
- Component-specific tokens
- Mapped tokens
Tokens are reusable, scalable, and ready for theming and platform parity.
This helped remove guesswork from design decisions. Instead of designers manually choosing colours, spacing, or typography, the system encoded intent into tokens, making consistency the default rather than an extra step.

2. Platform-Specific Typography Structure

Created separate typography structures for:
- Web
- Android
- iOS
Font styles are clearly defined, scalable, and aligned to platform guidelines.
This respected platform conventions while keeping visual consistency at the system level.

3. Clear Component-Per-Page Structure

Each component lives on its own dedicated page
- Example: Buttons, Cards, Inputs, etc.
Pages are easier to find, scan, and maintain.
Improves discoverability for both designers and developers.

4. Structured Component Documentation

Components are organized with:
- Clear variants and states
- Visual hierarchy
- Inline guidance and callouts
Easier to understand expected usage and behavior.

5. Scalability & Maintenance

Designed with scale in mind:
- Tokens support future themes and updates
- Clear structure supports long-term maintenance
- Reduced need for component duplication

OLD DESIGN

1. No Token Strategy

- - No semantic token layer existed
  - Token usage was inconsistent and incomplete
  - Styling decisions were often hard-coded at the component level

2. Flat Styles

Typography styles were mixed together
No clear separation between Web, Android, and iOS
Difficult to scale or update typography consistently across platforms

3. Grouped Pages

Multiple components were grouped together across shared pages
Harder to locate a specific component
Increased cognitive load and maintenance effort

4. Scattered Information

Component information was scattered across large canvases
Variants and states were harder to compare
Documentation depth varied significantly

5. Growing Design Debt

Structure did not support growth
Teams spent time fixing components
Increased risk of design drift over time

Tools Used

Figma (Variables, Components, Tokens, Libraries, Auto Layout 5)
FigJam (Workshops, IA mapping, system flows)
Notion (Documentation, guidelines, audit trackers)
Slack (Team collaboration & async reviews)

Outcome and Impact

What changed as a result of this work

1. Improved clarity and adoption

Designers could more easily:

Find the right component
Understand when and how to use it
Trust that patterns were intentional and up to date

This reduced time spent recreating components or making ad-hoc decisions.

2. Stronger consistency across platforms

By separating foundations and respecting platform conventions:

Web, iOS, and Android designs felt more native
Visual and interaction inconsistencies were reduced
Cross-platform scaling became more predictable

3. Better scalability and flexibility

The new token architecture:

Enabled faster theming and updates
Reduced the impact of design changes
Made accessibility improvements easier to apply consistently

4. Increased system trust

Clear documentation, usage guidance, and structure helped:

Reduce uncertainty around approved components
Align designers and developers
Position Snowball as a reliable source of truth rather than a reference library

5. Foundation for future growth

While the system uplift was ongoing, the architectural changes laid the groundwork for:

Easier onboarding of new designers
More efficient collaboration with engineering
Sustainable system growth without sacrificing quality

European Luxury Train

This is a conceptual case study created to explore how a mobile app could support luxury train attendants in delivering high-touch, personalized service. While the product is fictional, the research methods, design decisions, and workflows reflect real-world UX practice.

Overview

This project explores how a mobile app could help luxury train attendants manage passenger needs, loyalty benefits, and in-train services more efficiently. The goal was to design a clear, reliable tool that reduces manual work and helps attendants deliver more personalized service during a fast-moving journey.

Platform: Mobile (iOS-first)
Users: Luxury train attendants
Scope: Concept > UX > UI

My Role

I led this concept end-to-end, from understanding the service problem to designing flows, wireframes, and final UI. I focused on simplifying real-time service work, reducing cognitive load, and designing for motion, time pressure, and human interaction.

Context & Constraints

This concept explores a real-world service environment where speed, accuracy, and human interaction matter more than visual polish. Train attendants work in motion, often with one hand free, limited time per passenger, and high expectations from premium customers.

The app needed to work reliably in narrow aisles, under time pressure, and without disrupting the personal service experience that defines luxury rail travel.

The Problem

Train attendants rely on paper, memory, and disconnected systems to serve passengers. Loyalty benefits are hard to track, information is often outdated, and attendants struggle to quickly answer customer questions while moving through the train. This leads to slower service, missed opportunities, and frustrated staff.

Process & Approach

Although this was a conceptual project, the approach reflects how I have led real-world enterprise design engagements at IBM, including client work for Apple.

To ground the concept in realistic constraints, I followed a structured design process commonly used in large-scale, operational products. In a real implementation, this would begin with understanding business goals, operational workflows, and service constraints through workshops and requirement gathering with stakeholders and subject matter experts.

Using design thinking methods, I mapped out the key “golden threads” of the experience, the most critical tasks train attendants would need to complete during live journeys. These flows were informed by operational realities such as time pressure, passenger variability, and the need for quick access to accurate information.

From there, I explored and iterated on interface concepts, validating assumptions through internal critique and refinement. Designs were developed with an agile mindset, assuming close collaboration with engineering and continuous feedback to ensure feasibility, scalability, and clarity before moving toward implementation.

This approach ensured the concept was not just visually polished, but grounded in how complex service tools are actually designed, built, and used in production environments.

What I Learned

These challenges created friction during live journeys. I found that attendants often had the right intent but did not always have the right information at the right moment. This led to slower service, missed loyalty benefits, and inconsistent experiences for passengers across different parts of the journey.

Through this exercise, I learned that:

Attendants struggle to quickly identify loyalty passengers
Important service information is often scattered or outdated
Communication between attendants is inefficient
Paper-based workflows slow down service and increase the chance of errors

Empathy mapping helped me understand the real frustrations attendants face during live journeys, especially when tools fail under pressure.

Primary User: Luxury Train Attendant

Train attendants are responsible for multiple cabins, frequent passenger interactions, and real-time service decisions. They must remember loyalty details, manage upgrades, coordinate with other staff, and answer destination-related questions, all while moving through the train.

The app needed to support quick decisions, reduce memory load, and stay out of the way of human interaction.

Design Goals

Help attendants find passenger information quickly
Make loyalty benefits visible and easy to apply
Reduce paperwork and manual tracking
Support fast decisions during live train journeys

Success was defined by how quickly attendants could move from identifying a passenger to completing an action, with minimal taps, minimal reading, and minimal cognitive effort.

The Solution

I designed a mobile app that gives train attendants a real-time view of passengers, loyalty status, available upgrades, and onboard services. The app acts as a single source of truth, replacing paper workflows and helping attendants focus on customer experience instead of administration.

Initial Sketches

Core Attendant Flow

IDENTIFY PASSENGER

I designed the flow so attendants can quickly identify passengers by seat map or list view. This reduces time spent searching and helps attendants immediately understand who they are serving, even while moving through narrow train aisles.

VIEW LOYALTY STATUS

Loyalty status is shown early and clearly, so attendants can recognize high-value passengers without needing to remember details or check separate systems. This prevents missed benefits and creates a more consistent premium experience.

OFFER SERVICE

Based on passenger type and journey context, attendants can quickly offer food, drinks, Wi-Fi, upgrades, or local experiences. The app keeps choices simple so attendants can focus on conversation, not menus.

COMPLETE ACTION

Orders and upgrades can be completed in a few taps. Clear confirmation helps avoid errors and reduces the need for follow-up or corrections later in the journey.

Design Execution

I focused on speed, clarity, and one-handed use. The interface prioritizes the most important information first and avoids unnecessary interactions. Screens were designed to work in varied lighting conditions and while walking, where attention is limited and mistakes are costly.

a) Wireframes

Wireframes focused on speed, clarity, and one-handed use. Screens were designed to surface the most important information first, reduce scrolling, and support fast decisions while walking through the train.

b) Moodboarding

The visual direction balanced elegance with restraint. The goal was to feel premium without distracting attendants from their task. Typography, spacing, and contrast were chosen for readability in varied lighting conditions.

C) Final Screens

Passenger Overview

This screen prioritizes passenger identity and loyalty status, allowing attendants to immediately recognize high-value customers and tailor service without searching through menus.

Loyalty Identification

Loyalty information is surfaced early to prevent missed benefits and ensure consistent recognition across the journey.

Ordering & Upgrades

Upgrade and ordering flows are designed to complete actions quickly while keeping attendants in control of availability and passenger expectations.

Attendants

This screen helps attendants quickly see who else is working on the train and communicate when needed. It supports coordination during busy moments and reduces the need for verbal handoffs or searching for colleagues.

Outcome & Impact

This concept demonstrates how a single, well-designed mobile tool can simplify complex service workflows into clear, repeatable actions. By replacing paper processes and fragmented systems, the app enables attendants to focus on passengers rather than administration.

While fictional, the design reflects real-world service constraints and shows how thoughtful UX can improve speed, consistency, and confidence in high-touch environments.

Reflection

This project reinforced that designing for service roles is less about visual complexity and more about clarity, speed, and trust. In real-time environments, fewer decisions lead to better outcomes. Clear hierarchy and predictable flows matter more than advanced interactions.

Why This Concept Matters

Although this product does not exist, the service problem is very real. Many service industries still rely on paper, memory, and disconnected tools. This case study demonstrates how UX principles can be applied to simplify complex, real-time service environments.