Acorn Design System

TL;DR

• Founded and led an enterprise design system for roughly two years, covering both the Figma library designers pull from and the Angular library plus CDN distribution that applications consume.
• Sequenced the design library first, because a code library built over unsettled design decisions just encodes the inconsistency in TypeScript.
• Shipped the standards layer that actually changed behavior: stylelint property ordering, on-save formatting, pre-commit hooks. Styling nits left code review entirely.
• Reached adoption outside the founding team, which was the bar for calling it a system rather than a component library.

Overview

Acorn is the design system I founded and led for roughly two years at a Fortune-500 financial services company. It covers both halves of the problem: a Figma UI library that designers pull from, and an Angular component library plus CDN distribution that legacy and net-new applications consume. Underneath both sits a standards layer — stylelint property ordering, SCSS guidelines, on-save formatting, pre-commit hooks — that made the system the path of least resistance rather than an extra thing to remember.

The organization had no shared frontend system when I started. Frontend expertise was thin across the org, and designers and engineers were each re-inventing the same patterns per application. Two teams solving the same date-picker problem in two different ways is not a component problem. It is an organizational one.

Goals

• Give designers a single Figma source to pull from, so a pattern gets decided once rather than per project.
• Make the same decisions consumable in code by applications that could not all be upgraded on the same schedule.
• Remove styling and formatting from code review entirely, by automating the rules instead of policing them.
• Get adoption outside the team that built it. A design system used by its authors is a component library.

Approach

The Figma library came first

The code library is downstream of the design library. If designers are still deciding padding per screen, the components are just going to encode that inconsistency in TypeScript.

So the first deliverable was the Figma UI library: the foundational styles, the component set, and the structure designers navigate to find them. That last part matters more than it sounds. A library nobody can find a component in gets bypassed, and a bypassed library drifts within a quarter. Getting the information architecture of the library right — how components are named, grouped, and surfaced — is what makes designers reach for it instead of drawing a new one.

This is the same work I had done a few years earlier at CoreLogic, where I redesigned the enterprise design system’s Sketch library to improve its information architecture, symbol efficiency, and consistency. Different tool, same problem: the library’s usability determines its adoption.

The artifacts themselves are proprietary and stay with the employer, so this case study is the reasoning rather than the screenshots. The Bock design system is the equivalent work I own outright and can show in full.

Distribution had to fit the applications that existed

The application portfolio was not uniform, and waiting for every app to modernize before shipping a system would have meant shipping nothing for two years.

The code library shipped as an Angular component library with CDN-delivered assets, so an older application could consume the system’s styles and assets without first being rebuilt. Net-new applications consumed the component library directly. One system, two adoption paths, sequenced to the reality of the portfolio rather than to an ideal migration plan.

The standards layer is what actually stuck

The components were not the deliverable that changed behavior. The automation was.

I authored a documented standards library covering semantic HTML, modern CSS architecture, JavaScript practices, Angular patterns, and project organization. Then I made the parts that could be mechanical, mechanical:

• Stylelint property ordering, in a fixed sequence: positioning, box model, border, visual, typography, then everything else. Vendor prefixes carry explicit exemptions.
• On-save formatting configured in the editor, so the rule applies before anyone thinks about it.
• Pre-commit hooks, so the rule holds even when the editor config does not.

The measurable result was that code-review time spent on styling effectively went to zero. Reviewers stopped writing “nit: property order” and started reviewing behavior. That is a small thing that compounds across every pull request an organization opens.

The principle underneath: documentation tells people the rule, automation makes the rule the path of least resistance, and guidance explains why when someone is confused. All three layers, or it does not stick.

Adoption was the project

I ran weekly stakeholder syncs for the life of the system. Not status meetings. The point was to keep design, engineering, and the consuming teams aligned on what was landing next and what they needed that did not exist yet.

The system also shipped as a deployed application with a stable URL, navigation, and documentation, so “where do I find the button spec” had one answer for both designers and engineers.

Extending the standards into AI tooling

Toward the end, I prototyped a frontend-standards MCP server so that AI assistants working in the editor could evaluate code against the documented standards in real time. The idea was to close the last gap in the three-layer model: documentation and automation both tell you what, and an assistant with the standards loaded can tell you why at the moment you are confused.

It validated on sample components and got feedback from another developer. I would call it a working prototype rather than a shipped product, and I am including it here because the approach turned out to matter more than the artifact — it is the same pattern I later built on more thoroughly outside work.

Outcomes

• Founded and led for roughly two years, from nothing to a system with a Figma library, a code library, CDN distribution, documentation, and a governance cadence.
• Deployed documentation application with a stable URL and navigation, serving designers and engineers from the same source.
• Adoption outside the founding team. At least one team beyond UX engineering consumed Acorn assets, which was the bar I set for calling it a system rather than a library.
• Styling nits eliminated from code review, through the stylelint ordering rules plus on-save formatting and pre-commit enforcement.

Reflection

Design systems are organizational change projects wearing engineering clothes. The components are the easy part and the part everyone wants to talk about. Adoption is the actual work, and adoption is mostly documentation, cadence, and making compliance cheaper than non-compliance.

If I were starting Acorn again, I would build the automation layer earlier. I sequenced it after the component work because components felt like the product. In hindsight the stylelint configuration and the on-save formatting bought more behavior change per hour invested than any individual component did, and they would have made every component that came after them land more cleanly.