Canvas

‍

Frame

Canvas was GD&A's first official design system, and the organization wasn't yet convinced it needed one. At the time a design system still had to prove it would pay for itself before a team would build on it, so this work was as much about earning adoption as designing components.

A small team was formed to test the value. The engagement ran about seven months, from mid-2020 into early 2021; by the time I rolled off, Canvas was versioned, released, and in use.

‍

The Problem

GD&A had no design system. The components that existed were scattered across files, undocumented and inconsistent, and designers rebuilt the same patterns from scratch on every project.

The harder problem was that the organization wasn't sure it wanted one. In 2020, design systems were new enough that many teams questioned whether they were worth the overhead, and GD&A was no exception. The fear was that a system would be too rigid and constrain the work, breaking existing products as it changed. Engineering wouldn't follow it, and other teams wouldn't adopt it. Leadership needed convincing the system was worth building at all. A system would only succeed here if it was built to answer those fears directly and earn its way into use.

‍

The Approach

Because the system had to be justified before it could be built, the work started with the case for it. I researched how design systems pay off, pulling together the adoption, consistency, and engineering-time arguments and the cost math behind them. That research fed the case made to leadership. Alongside it, the team ran a hopes and fears workshop to put the skepticism on the table. The point was to design against the concerns people actually held rather than assumed ones, and the fears clustered: flexibility, breakage, adoption.

‍

‍

The team divided the work. I took four of the foundations and the form, input, and table components — the parts of the library teams use to enter and read data.

Components alone don't make a system, so my work also included the process to keep them maintainable: an intake workflow for bringing new contributions in, and a sunsetting workflow for retiring old patterns without breaking the designs that used them. This was governance in the working sense (the contribution model and the deprecation discipline).

Adoption was the part most likely to fail, so it couldn't rest on documentation alone. We built a workshop program, in which I ran multiple sessions focused on training team members on configuring component props and using auto-layout in their designs. I structured it around hands-on practice tied to each release, so support tracked the system as it changed.

‍

Key Decisions

Foundations. Grids, typography, icons, and logos. Grids and type scale responsive across desktop, tablet, and mobile. Icons organized into categories with usage rules and a fixed layout grid for net new icons.

Form, input, and data components. Text fields, text areas, checkboxes, radio buttons, the forms that compose them, and the data tables that carry the analytics surfaces. Each is built atomically, with full state and variant coverage.

‍

‍

Form templates. Full-page, half-page, slideout, and modal forms, composed from the components so a team could assemble a working form without rebuilding it each time.

Intake workflow. A defined contribution process for net new work into the system, with a holding area for ready-to-publish assets ahead of release.

Sunsetting workflow. A documented process for retiring and archiving outdated patterns without breaking existing designs downstream.

Component testing gate. Before anything published, every component ran a staged library test: built in R&D, validated locally and in working files, then promoted to the shared library and re-tested in place.

Component documentation. Detailed usage guidelines and specs for each authored component category in a consistent structure: anatomy, types, hierarchy, sizes, states, best practices, and resources.

Workshop curriculum. A hands-on program (agenda, timed build exercises, walkthroughs), recurring office hours tied to releases, and a quarterly survey to track how the program was landing.

‍

Outcomes

In about five months, the team took GD&A from no system to a released, versioned one in active use across the org.

The foundations and the form, input, and table components were released into the library and documented, giving the analytics products a consistent base they'd never had. Within a library that grew to two dozen component sets with fully fluid templates, my forms, inputs, and tables were rebuilt to flex across the dashboard contexts they served.

The intake and sunsetting workflows let a static library become one that could take in new work and retire old work on a cadence, shipping versioned releases on a schedule rather than as one-off drops.

Adoption was actively driven. The workshop program and the office hours gave a thirty-person org that had never used a system a way to pick this one up, and the hands-on sessions meant designers left having built something from the library, not just having seen a demo of it.

‍

What's Outstanding

The system was young when I left. Five months in, the foundations, components, and workflows were in place and the org was using them, but a system that new is still early in its life. Whether the adoption I'd seen would hold once the founding contributors rolled off was an open question. The workshops and office hours had started the habit, but a habit that new is fragile.

And some of the system's reach was still ahead of it. The data-visualization layer and the move into the org's analytics tooling were in flight when I left, owned by others on the team. The system I contributed to was the foundation they would build on, not the finished article.

‍

What Made It Stick

A design system's first version is easy to mistake for the work itself. The components are the visible part. But a library only becomes a system when an organization builds on it with trust and consistency.

The leverage was never in the components alone. It was in the layer around them: the forms and tables people reached for every day, the intake and sunsetting paths that let the system change without stranding anyone, the workshops that turned a library into a habit.

This was my first design systems engagement, and it set the pattern for the ones that came after. The durable work in a system is rarely the components themselves. It's everything that keeps them in use.