arrow_back

Back

arrow_back

Back

arrow_back

Back

BlueSky Design System

Bell, 2023

Overview

Bell and Virgin Mobile's app teams were operating without a shared foundation — designers worked from scattered files, UI was inconsistent across the experience, and every feature built for Bell had to be rebuilt from scratch for Virgin. With a major app redesign underway, the cost of that fragmentation was no longer sustainable.

BlueSky was our answer — a unified, multi-brand design system that gave design and development a single source of truth for the first time, supporting both brands across iOS, Android, light and dark themes.

My Role

Sr. Designer — Token Architecture, Design, Documentation.

The Team

2 lead designers working closely with 1 product owner and 6+ engineers.

Timeline

~ 6 months for first implementation of tokens and foundational components.

Overview

Bell and Virgin Mobile's app teams were operating without a shared foundation — designers worked from scattered files, UI was inconsistent across the experience, and every feature built for Bell had to be rebuilt from scratch for Virgin. With a major app redesign underway, the cost of that fragmentation was no longer sustainable.

BlueSky was our answer — a unified, multi-brand design system that gave design and development a single source of truth for the first time, supporting both brands across iOS, Android, light and dark themes.

My Role

Sr. Designer — Token Architecture, Design, Documentation.

The Team

2 lead designers working closely with 1 product owner and 6+ engineers.

Timeline

~ 6 months for first implementation of tokens and foundational components.

Overview

Bell and Virgin Mobile's app teams were operating without a shared foundation — designers worked from scattered files, UI was inconsistent across the experience, and every feature built for Bell had to be rebuilt from scratch for Virgin. With a major app redesign underway, the cost of that fragmentation was no longer sustainable.

BlueSky was our answer — a unified, multi-brand design system that gave design and development a single source of truth for the first time, supporting both brands across iOS, Android, light and dark themes.

My Role

Sr. Designer — Token Architecture, Design, Documentation.

The Team

2 lead designers working closely with 1 product owner and 6+ engineers.

Timeline

~ 6 months for first implementation of tokens and foundational components.

help

Guiding question

How might we reduce design decisions and build quality products faster?

assignment

Context

Bell was getting a new look. Virgin needed one too.

The MyBell app was undergoing a full redesign. Pushing towards a more modern, airy UI with improved usability. The Virgin Mobile app would follow. Both apps shared largely the same UX, which made the opportunity clear: rather than designing and building each experience separately, we could build one system that supported both brands.

But before we could do that, we needed a foundation. No shared component library. No token structure. No documentation process. We were starting from the ground up.

wb_sunny

Highlights

One system, two brands, endless possibilities.

Multi-brand support to fast track shared flows across brands

Semantic colour tokens can enable light and dark themes

Primary Button background colour and it's token references

token

Tokens

A token structure built to flex without breaking

Tokens were the backbone of everything BlueSky could do — multi-brand support, light and dark themes, platform differences, and breakpoints all lived here. The challenge wasn't just building a token structure, it was building one that could scale as the system grew without becoming impossible to maintain.

We organized our tokens into distinct layers, each with a clear responsibility.

A diagram of the BlueSky token set structure

token

Core

unfold_less

All raw values — hex codes, spacing values, sizing, radii, and more. No semantic meaning at this level, just a wide palette of values drawn from our design audit.

brand_family

Brand

unfold_less

Where semantic naming begins and brand switching happens. This set covers anything that could differ between brands — colour, typography, radii, spacing, opacities, and more. We cast a wide net intentionally to stay flexible as the system grew.

ios

Platform

unfold_less

Bell's iOS and Android apps used different default body fonts — iOS defaulted to SF Pro, Android to Roboto. This collection handled those platform-specific differences cleanly.

responsive_layout

Breakpoint

unfold_less

Added later when tablet support became a requirement. Having a dedicated collection made it straightforward to introduce without disrupting the rest of the structure.

contrast

Theme

unfold_less

Mirrors the Brand set's naming, but exclusively for colour. This is what enables light and dark mode switching.

widgets

Component

unfold_less

Every element of every component had its own token. This made updates powerful — a designer could change a token reference and push it to GitLab, and dev would simply accept the change, no code required. The tradeoff was a token file that grew very large and became increasingly difficult to maintain over time.

globe

Global

unfold_less

Shared with consuming designers and developers — the tokens they actually reach for day-to-day that aren't tied to a specific component. Semantic naming only.

Tooling

We started with Token Studio before Figma Variables existed.

When Variables launched, we upgraded to the pro version which let us sync our tokens directly with Figma Variables — giving designers the ability to switch between brands, themes, platforms and breakpoints right in their files. Devs benefited too, inspecting designs and seeing variable names that matched our token names 1:1.

From Token Studio, our tokens were exported to GitLab and transformed for iOS (SwiftUI) and Android (Jetpack Compose).

Designers needed guidance for spacing as much as colour

We also created semantic spacing tokens to reduce guesswork around common layout patterns.

Our spacing scale was built on a 4px base — spacing.x1 = 4px, spacing.x2 = 8px, and so on. This gave designers a consistent set of values to work from, and semantic tokens like spacing.semantic.vertical.betweenFields mapped directly to that scale for specific use cases.

Without them, designers were making independent spacing decisions for the same patterns. A dedicated token meant everyone was working from the same value, every time.

Semantic spacing tokens common patterns like gaps between field elements

lightbulb

Key takeaways

  1. Component tokens for everything bloated our token file fast. Use them sparingly, only for values that genuinely vary between brands and themes. Semantic tokens handle the rest.

  2. Naming inconsistencies are easy to miss early and painful to fix later. By the time we caught ours, other teams were already consuming those tokens, turning a cleanup into a breaking change.

  3. Once other teams are consuming your tokens, changes become a product decision. Deprecations need communication, migration guides, and lead time, not just an internal update.

grid_guides

Iconography

Giving designers the tools to grow the icon library

As the app evolved, so did our need for new icons. Rather than bottlenecking all icon creation through the design system team, we established clear guidelines so other designers could contribute while keeping the library consistent.

Guidelines covered key shapes, grid structure, stroke width, vector construction, and stroke end treatment, everything needed to create icons that felt like they belonged together.

Key shapes: Square, Circle, Tall Rectangle, Long Rectangle.

Stroke width, shapes and vectors

Stroke ends are squared

flowchart

Intake

Filtering and prioritizing updates to the system

Requests for new components and updates came in from all directions, each with their own sense of urgency. Without a clear process, it was hard to prioritize and even harder to manage expectations across feature teams.

We built a repeatable intake process to fix that. Design, our product owner, and dev worked collaboratively to assess and prioritize requests, making sure the most impactful work always moved first.

The end-to-end process showing how component requests moved from intake and prioritization through design, development, testing, and out to consuming teams.

Decomposition process — looking at all new component requests and updates and breaking them down to better understand it's structure, usage and highlight any questions for devs.

docs

documentation

Sweating the details for a smooth handoff

All of the work we had done up to this point was meaningless if we didn’t have a detailed documentation to handoff to engineers.

This documentation served as a vital resource for both design and development, ensuring smooth handoffs and adherence to the system’s standards.

Each component doc included:

  • Anatomy: elements, what is optional, what is configurable

  • Variants & states: configurations and interaction states

  • Specs: spacing, sizing, typography, color, plus a token table (most-used by engineering)

  • Behaviors: interaction rules and touch targets

  • Guidelines: do’s and don’ts, usage context

  • Accessibility: screen reader guidance, focus order, keyboard behavior

Documentation for our Selector Button component. Showing some of the key sections — anatomy, specs, and behaviours

fast_forward

Impact & Next steps

A unified experience across app and web

We've seen the impact of BlueSky on our mobile apps, and it got stakeholders thinking bigger. A consistent experience across Bell and Virgin Mobile, less duplicate work between brands, and smoother handoffs between design and dev all pointed to what a well-built system could do.

Bell's web products were next. Inconsistent, disconnected from the app, and overdue for a refresh, the web was the next challenge. The other BlueSky lead and I were asked to help kick off that initiative, bringing everything we'd learned to a much larger surface.

That work is ongoing. But it started here.

That's all folks!