Instructure UI Design System

Project overview

InstUI is the shared design system used across all Instructure products, including Canvas, Mastery Connect, and Impact. It serves around 30 designers and hundreds of developers. Over the past two years, we’ve been rebuilding it from the ground up to create a scalable, consistent, and modern system.

The team

1 Product Designer

1 Product Manager

2 Accessibility Engineers

2 Software Engineers

My contribution

Processing research data

Design & testing

Accessibility audit

Problem statement

The Challenge

Although InstUI already existed, it lacked foundational logic, consistency, and clear usage guidelines. Components were built without Figma features like Auto Layout or Variants, and foundations – like color and spacing – were used inconsistently across teams. This led to inefficiencies for designers and engineers, and a fragmented experience for users navigating between Instructure products.

The Goal

Our mission was to redefine InstUI with clear foundations, scalable token architecture, and a robust, accessible component library. From a company perspective, the priority was to create a seamless user experience across all products, while internally, we focused on giving product teams the tools and structure to build faster and more consistently.

Foundations

The existing system lacked meaningful foundations. Spacing was applied inconsistently, colors weren’t mapped semantically, and many design decisions were ad hoc. To move forward, we first had to define a solid foundation, one that could scale across products and teams.

I led the effort to define and structure our design tokens, starting with an architecture that would support both designers in Figma and developers in code. We worked closely with our engineering team to align on token naming, grouping, and potential implementation logic.

The foundations we established

Instead of using raw color values and fantasy names, we introduced a multi-layered token system that support WCAG accessibilty standards (AA 4.5:1, AAA 7:1).

Designers often used custom values or eyeballed alignment, which led to messy and unpredictable layouts. We introduced a spacing scale (based on a base unit of 4), with semantic tokens.

The typography system now uses a clear hierarchy-based scale. We introduced semantic styles for titles, body text, links. Each style uses adaptive tokens for size, weight and line height.

To create consistent structure across screens, we defined a set of layout primitives. This system made it easier to reason about spacing, while giving teams a framework for page composition.

We created standardized styles for all interactive states (default, active, hover, pressed, read-only, disabled) using tokens. Each state has clearly defined color, border, and background rules.

We defined a dedicated guideline set for background, icon, and text for statuses (success, warning, error, info) to bring uniformity to how messages and alerts appear across components.

Spacing

A consistent scale with rational increments, replacing arbitrary spacing values used across products.

Color

A structured palette with semantic names, for both UI and data visualization.

Typography

A type scale with use incorporated into the name to ensure hierarchy at first view.

Shadow & Elevations

A simplified set of shadow styles with consistent layering logic.

Breakpoints & Layouts

A defined set of responsive rules and grid behaviors to unify layout decisions across platforms.

Interaction states & Statuses

Accessible, consistent states for interaction (hover, active, focus, read-only, disabled) and clear rules for representing status (info, success, warning, error).

Component design

Research

We began by benchmarking patterns from established design systems like Material, Carbon, Tailwind, and Fluent. This helped us ensure that our components offered the right feature set and flexibility for complex, real-world use cases. We also compared these with our existing components to identify what needed to be rethought, refined, or rebuilt from scratch.

Feasibility check

Once we had a clear direction, we brought in our engineering and accessibility partners early to validate feasibility and flag any potential blockers. This step was key to avoiding surprises later in the process.

Building

When it came to building in Figma, our goal was to leverage every relevant feature to ensure the components were not just visually aligned, but also scalable and efficient for designers to use. Attention to detail was essential here: padding, alignment, sizing, interaction states, everything was taken into consideration.

Each component was built with

Auto Layout for structure and responsiveness
Variants to consolidate multiple use cases into a single, smart component
Variables for dynamic styling
Nesting for easier maintenance and to avoid breaking changes in the future
Clear naming to make the system intuitive

Documentation & Guidelines

Creating components was only half the challenge. Making sure they could be used correctly and consistently across dozens of designers and hundreds of developers required thorough, accessible documentation. We dedicated an entire Figma file to component documentation, covering everything from intended use cases to constraints.

Each component included

A clear description of what it is and when to use it
All available variants with explanation of how and when to use each
Behavioral guidance like interaction states and accessibility notes
Responsive considerations and how the component adapts across breakpoints
Do's and don'ts for clarity and visual consistency

Documentation wasn’t treated as an afterthought—it was part of the design process from the start. By thinking through edge cases and usage scenarios early, we helped our teammates avoid ambiguity.

Impact & Reflections

While the full system is still being rolled out, the early results have already made a noticeable difference. For the first time, teams across Instructure have access to a shared visual language.

The design token structure I created was especially well received. It brought structure to previously chaotic areas, and helped designers and developers speak a common language. We’re seeing significantly fewer inconsistencies across design files and code.

The process also introduced a new level of design maturity across the company. Teams now have not just components, but context: documentation, rationale, and the tools to make better design decisions.

As more components and usage patterns go live, I’m excited to see InstUI become not just a system of parts, but a product in its own right.