Building Dream, a shared design language

ii. The Process

None of us had built a design system before, so we leaned on research to inform how each component was built, documented, and used. Once research concluded, the component would then be designed in Figma and handed off to development for implementation. Throughout the process, designers and developers were always collaborating and communicating with each other. Designers would look at visual outputs from development, and developers would review Figma for property and layout specs.

Governance ran on majority vote rather than one person calling the shots, making sure everyone was aligned and everyone's voice was heard. Even with that structure in place, we knew we couldn't anticipate every use case ourselves, so we built a contribute and commit model, letting any designer or developer propose changes so the system evolved with real feedback rather than our assumptions.

My contributions:

I standardized the team's research process, designed several components, launched a 1-year satisfaction survey, ran observability sessions, reviewed and consulted on designs that the design team requested, and hosted training sessions.

iii. The Results

UI Library

A component library in Figma + Storybook, full component documentation on guidelines and patterns, shared design tokens, and two themes.

Adoption & scale

Since launching with 50 components, Dream has grown to 85 components across 56 active projects, with 55% adoption today. Greenfield projects are largely required to use Dream; legacy systems are migrating over gradually. The system has shipped 4 major releases to date.

Community engagement

The contribute & commit model has driven 179 pieces of consumer feedback implemented (tracked via Airtable), turning outside input into real system changes rather than requests that go unanswered. Separately, the team has conducted 21 design consultations — an offered service where designers can check their work against Dream standards, though not yet an embedded step in project workflows, as the UX team is still refining how review gets built into the process.

One-year benchmark survey

Around Dream's one-year mark, I surveyed designers and developers to benchmark satisfaction and surface gaps. Designers were 100% satisfied or somewhat satisfied; developers were 83%. Top praise: team support and documentation. Top pain point: more flexibility to match mockups one-to-one.

That same flexibility gap showed up independently in observability sessions, where designers repeatedly detached complex components likes data grid, for example, from its Figma instance — confirming the pattern was real, not a one-off issue.

iv. What's next

Auditing every component for flexibility, building an MCP server so AI-generated work stays on-standard, migrating legacy systems, and rearchitecting the system to be more agentic friendly.

v. Reflection

The hardest part was the uncertainty — none of us had done this before, and not everyone welcomed an enforced standard. But working on Dream taught me to think beyond, since a design system is itself an experience after all. That shift made me a more confident, systems-minded designer.

I would have liked more time in building the system, since its first launch rode on the back of a major project, taking the opportunity to prove the system's value. This did cause some quick decisions and compromises to deliver on time, but it was still the system's best opportunity to prove itself.