top of page

VK

Cover.png

OCAS Design System 1.0

Context:

The OCAS Design System was built to streamline the user experience across multiple educational services under Ontario Colleges. We aimed to standardize UI components, establish visual consistency, improve design-to-dev handoff, and reduce redundant work across products.

My Role:

Senior Product Designer - End-to-end design system lead - research, structure, design, documentation, and developer collaboration.

The Problem:

The OCAS product suite lacked a consistent visual and interaction standard:

  • Multiple teams designing independently led to:

    • Duplicate components

    • Inconsistent typography, colors, spacing, button states

    • Accessibility gaps

  • Engineering teams were recreating components manually without consistency.

  • Lack of shared guidelines slowed design-to-dev handoff.

  • New hires struggled with onboarding due to UI inconsistencies.

Core Team:

  • Myself

  • Product Designer

  • Branding Team

  • Developers

Duration:

6 Months

Goals & Strategy:

  • Establish a single source of truth for all design decisions.

  • Create scalable, reusable components following atomic design principles.

  • Ensure WCAG accessibility compliance.

  • Simplify onboarding for designers and developers.

  • Improve speed and consistency in design and development.

Discovery and UI Audit

I performed a detailed UI inventory audit across multiple platforms:

  • Reviewed all unique interface patterns in OCAS Products

  • Identified:

    • Different button styles

    • Inconsistent spacing

    • Different fonts and typography hierarchies

    • Multiple conflicting color palettes

    • Variations in icon usage (different icon styles, sizes, or sources)

    • Inconsistent imagery or illustration styles

    • Multiple versions of buttons, forms, modals, cards, etc

    • Missing states (hover, active, disabled, error, success, etc.)

    • Multiple grid systems being used

    • Inconsistent terminology (e.g. "Sign Up" vs "Register")

    • Tone and voice differences across interfaces

    • Labeling inconsistencies on buttons, headers, forms

    • Different code implementations for similar UI elements (Different teams were handling different projects)

    • ​Inconsistencies with brand guidelines (colors, logos, iconography)

A Glimpse at OCAS Products (Website Screenshots) - Inconsistent Components We Aimed to Unify Through a Design System

Token Setup

I introduced a token-based approach using Figma Variables. Such as:

  • Color Tokens

  • Typography Tokens

  • Spacing Tokens

image.png
image.png
image.png
image.png

Component Design

Components were built using Atomic Design Principles. Tap the image below to enlarge.

Documentation

Each component in the design system has

  • Usage guidelines

  • Edge case rules

  • Accessibility notes

  • Visual “Do and Don’t” examples

Below is an example of documentation for Button Component (Documentation is WIP): 

Guidelines 1.png
Guidelines 2.png

Collaboration with Development

  • A core pillar of the OCAS Design System’s success was tight integration between design and development, especially as developers were simultaneously building Storybook components while I was constructing the design system in Figma.​​

  • While I built tokens, components, and documentation in Figma, our frontend developer began constructing the coded component library in Storybook, using design system as the foundation.​​

  • We made sure that each Figma component had a 1:1 match in Storybook​​

  • We scheduled a weekly 30-minute design-dev sync.

    • Key discussions:

      • Reviewing Figma updates or token changes

      • Aligning new Storybook components with design specs

      • Addressing accessibility concerns or naming mismatches​​​

  • The developer actively contributed to component documentation in Storybook and Confluence:

    • Added performance tips (e.g. which components are heavier)

    • Noted limitations for edge cases (e.g., word-wrapping issues in mobile buttons)

    • Integrated accessibility best practices using ARIA and keyboard navigation​

  • Outcomes:

    • Faster Handoff: Figma → Storybook → Production was smoother, with 80% less back-and-forth.

    • Shared Language: Tokens became the universal truth across design and code.

    • Visual Parity: Components looked and behaved exactly as designed.

Impact

  • The OCAS Design System significantly reduced UI inconsistencies across products by consolidating most of the misaligned components into a unified, token-based system.

  • By introducing semantic design tokens and a standardized grid, we improved visual harmony and made updates scalable across platforms.

  • Developer handoff became faster and clearer, reducing back-and-forth iterations by more than 80% through Figma DevMode and token syncing.

  • Collaboration with developers improved dramatically, as the parallel Storybook build allowed design and code to stay aligned in real time.

  • Accessibility compliance increased, with all new components meeting WCAG AA standards through clear contrast, focus states, and ARIA tagging.

  • The design system cut screen design time in half by providing ready-to-use components and documented design logic.

  • Our developer reported a 30–40% improvement in sprint efficiency due to reusable, documented, and tested UI components.

  • Designers and developers now share a consistent naming system, eliminating confusion and reducing onboarding time for new team members.

  • The system created a solid foundation for future scalability, including plans for dark mode, interaction tokens, and Storybook integration.

  • Most importantly, it established a shared design language and culture of consistency across the organization, improving quality and speed across every team.

bottom of page