Concordia Design
System

Building a shared language for digital products across the university

Design systemsUX/UI DesignDesign ops

Overview

Client

Concordia University

My Role

Design system designer & front-end

Team

Michael Cardillo

Timeline

2025 – 2026

Concordia’s digital footprint spans dozens of sites, tools, and teams — each shipping interfaces with slightly different patterns, typography, and interaction models.

Without a shared system, teams duplicated effort, accessibility drifted, and students encountered inconsistent experiences as they moved between services.

The live product is the Concordia Design System on concordia.ca/brand: a component catalogue authors actually use, a token layer compiled into every AEM page, and brand standards that used to live in PDFs. Tokens are the foundation — they only matter because of the patterns, guidance, and contribution paths built on top of them.

Outcomes at a glance The system is in production — not a Figma-only kit. A brand decision can change in one place instead of a hundred files, and authors get a catalogue instead of a PDF.

Authors pick components in AEM

53 documented blocks in the catalogue — not a PDF, and not primitives only.

Hardcoded visual values fell by half

Colour, type, space, and elevation — not just hex. Colour uses dropped 83% in a 100-file sweep.

Body type moved from Arial to Inter

Size, weight, and line-height now come from 51 tokens instead of one-off px.

The system

Three surfaces, one living product.

Before the process, here’s what shipped — and is still evolving. Tokens encode the decisions. The catalogue is how teams consume them. Brand standards and tone of voice used to be PDFs; they’re now pages in the same system.

The public home is concordia.ca/brand — design, development, and content guidance in one place, not a slide deck.

Tokens

Colour, type, space, and the rest of the scale — named once, compiled into every AEM page. Live at /brand/web-ui-foundations/tokens.

Tokens

Colour, type, space, and the rest of the scale — named once, compiled into every AEM page. Live at /brand/web-ui-foundations/tokens.

Components catalogue

53 documented AEM components with usage guidance — forms, content, layout, navigation, status, overlays. Live at /brand/components.

Brand standards and tone of voice

Print-era standards digitized into searchable, maintainable pages — voice, identity, and web UI in one system. Live at /brand/brand-standards.

Problem

Consistency shouldn’t depend on who built the page.

Digital work was spread across decentralised teams, each with local standards:

Product teams

Shipping features on independent timelines.

Brand & communications

Owning visual identity and editorial voice.

Each group had good reasons for how they worked. For students and staff moving between tools, the result was friction — unfamiliar buttons, mismatched forms, and uneven accessibility. The harder part wasn’t agreeing that a system would help. It was the environment the system had to ship into. Building here meant working through constraints that never went away:

Thousands of CSS embeds, not a clean stylesheet.

Pages and components had pulled in local CSS for years. The compiled sheet wasn’t something you could restyle — only tokenise, file by file.

Brand guidance lived as historical knowledge.

Standards sat in PDFs and in the heads of people who’d been there when they were written. New teams couldn’t look it up; they asked around, or invented a local version.

Hardcoded values everywhere.

The same grey, the same burgundy, decided again in every file. A brand change meant a hundred-file hunt, not a token update.

No spacing scale for our own components.

Bootstrap 5 gutters handled page structure out of the box. Inside custom components, padding was whatever looked right that day — 10px here, 15px there. Nothing locked those decisions to a grid.

If the system documented decisions we’ve already made, we could focus on the hard problems instead of re-litigating padding.

Alex

Product designer

The landscape

9,200 CSS rules. 16,800 style declarations. Years of small decisions compounding into a stylesheet you couldn’t change in one place.

Product vision & solution

One system, many products

We framed the work around a single question:

What foundation lets teams ship faster while keeping experiences recognizable and accessible?

The work concentrated on three things:

Name colour, type, and space once.

Tokens replace the hex values, type sizes, and spacing steps that had been decided per file. A brand change is one update.

Document how components get used.

Each catalogue entry covers usage, states, and accessibility — the context authors need when they pick a block in AEM. Brand standards live as pages in the same system.

Ship it in the master clientlib.

Authors and product teams inherit the token layer without opting in. It compiles with every page.

Process

Working through the landscape we actually had

We inventoried existing interfaces across high-traffic properties — cataloguing components, variants, and accessibility gaps. A pass through the compiled CSS made the fragmentation visible: colour, type, and space had been decided per file for years.

That audit informed a prioritised component roadmap and the first token set aligned with Concordia brand. Tokens started as LESS custom properties, then moved to a JSON source so the same file generates CSS and a catalogue authors can search. Production sweeps followed in the files AEM actually compiles: hex to colour tokens, then on-scale margin, padding, and gap onto the 4px spacing scale. Bootstrap’s layout utilities stayed for page structure; off-scale 5, 10, and 15px values were left as pixels so the grid didn’t invent alignments the old CSS never had.

Final design & solution

A system teams can ship with

The v1 release focused on foundations and high-traffic components — buttons, forms, navigation, and feedback patterns — with accessibility baked in and examples tied to real Concordia products.

Placeholder — describe adoption path, release cadence, and how teams consume Figma and code packages.

The system is a product — it needs roadmap, owners, and feedback loops. Documentation site, Figma library, and code distribution give teams a single place to adopt and extend patterns.

Shared tokens across design and code

Single naming scheme for colour, type, spacing, and elevation.

Shared tokens across design and code

Single naming scheme for colour, type, spacing, and elevation.

Documented component states and anatomy

Specs cover default, hover, focus, error, and disabled — not just the happy path.

Accessibility requirements per pattern

Keyboard, contrast, and ARIA guidance included in each component entry.

Clear contribution and review model

Teams know how to propose changes and what “done” means for a release.

Room to grow without breaking consumers

Versioning and deprecation notes so adopters can plan upgrades.

Feature 1 – Tokens

Foundations that scale across products.

Brand colour, type, and space are named once — with semantic roles on top of the palette so a component never has to pick a hex. Page layout still uses Bootstrap 5 spacing. Custom component padding used to be one-off pixels; it now has to pick from a 4px token scale. Type uses a named size, weight, and line-height scale. The same JSON generates the CSS custom properties AEM compiles and a catalogue authors can search.

Token structure

Semantic mapping