Design Systems
My Experience Top
Since 2014, I've worked on design systems for companies big and small, and in various capacities. Some brands you know. Some you may not.
I've worn many hats over the years, including design lead, interface engineer, and technical writer. I like to work end-to-end. I enjoy partnering across disciplines to define the visual language and strategic direction of a system. Other core strengths include designing and engineering tokens, components, patterns, guidelines, and tooling.
Meeting Consumers Where They're At Top
While working at Microsoft, I designed a Figma plugin called Autopilot, powered by Microsoft's AI assistant Copilot. With Autopilot, designers are able to find and consume what they need without leaving Figma.
No context switching. No browser tabs. No laundry lists of components or guidelines to scroll through.
Autopilot shortcuts the Figma assets panel by allowing designers to include design tokens and components directly from the plugin UI. This means that designers can go from zero-to-full adoption with a few keystrokes and the push of a button.
Foundations Top
Principles Top
For the Apollo design system, I leveraged design principles to help guide decisions for core systems, and I included them at the top of each document to help consumers understand the rationale behind my decisions. This really shined on the more opinionated documents I wrote, such as our motion guidelines.
At Microsoft, I went even deeper by creating design principles to guide my initial exploration around foundational elements such as our system's tooling strategy and grid model. This helped me stay focused on the needs of the system and its tenants while I determined the best approach. The principles also served as an explainer for the rationale behind my decisions.
Processes Top
For Apollo, I partnered with product managers and engineering leads across five different product work streams to workshop models for system contribution and governance. The team was concerned with flexibility, and wanted to understand how we might enable contributions from anywhere. They also wanted to provide a consistent path for system governance, which I solved by defining models for auditing components and inventorying the product over time.
Over the year and a half that I was design lead for the system, I conducted several audits which successfully identified and led to a total reduction in component count and complexity by 13%. Fewer and simpler components means a leaner and more performant library, which means fewer bugs, less maintenance, and greater adoption.
Practices Top
At Microsoft, I was able to partner with dedicated a11y designers and engineers on every component that I delivered. They kept me honest against our accessibility values, which I found to be an invaluable practice. I've applied many of the lessons that I learned to this portfolio site, and continue to prioritize this approach in my work.
But accessibility isn't just for product users. On Apollo, I established practices to ensure that we were always accessible for our co-workers too, and I published them to our accessibility guidelines. This meant a system that more people would be able to contribute to over time, since they wouldn't be excluded by default.
User Interface Elements Top
Design Tokens Top
For Apollo, I organized design tokens down to the Semantic level, to provide consumers with reusable style primitives. Semantic tier design tokens offered sufficiently usable specificity while easing governance efforts as compared against a larger library of component level design tokens (dozens of tokens are more manageable over time than hundreds or thousands of tokens).
At Microsoft, I was able to take full advantage of Figma's newly released typography variables to represent both base and semantic level design tokens.
As a source of truth, I typically default to JSON, though each system's needs are different. JSON usually makes the most sense as the source of truth because it is (mostly) human readable, it easily translates to other languages, it's accessible for both designers and developers, and it is a web standard which will outlive and scale better than any design software available today.
For Apollo, I implemented a build process using Amazon Style Dictionary to transpile design tokens from JSON to the languages that the front end development team used in product; CSS, SCSS, and JavaScript.
Components Top
I designed a full catalog of components for Apollo, to help designers stay consistent and prototype their ideas more rapidly. In many cases, ideas could be prototyped in high fidelity as quickly as they could be in low fidelity, thanks to component-based infrastructure. That often translated to reductions in communication and confusion at the point of handoff between design and development.
The Apollo library consisted of over 26 different components, used across every work stream of the flagship product. Components were categorized as
- General
- Data Entry
- Data Render
- Feedback
- Navigation
The result was a highly coherent and scalable design language throughout the product.
Standing up a component library is the easy part. The challenge comes in maintaining and growing it over time. During my time as design lead for Apollo, I grew adoption from zero to all five product workstreams by partnering closely with product designers, engineers and stakeholders. My efforts prioritized meeting consumers where they were at and reducing the effort required for adoption. The Button component alone was instantiated more than 3,600 times across 84 different files.
Patterns Top
Pattern is a nebulous term that is defined differently from system to system. My approach for taxonomy is to lean on definitions that provide the most meaning for the team and system's consumers.
At DreamHost, back in 2016, we used the terms "component" and "pattern" interchangeably, which made sense for our team at the time; though it did lead to some eventual confusion.
For Apollo, I defined "components" as being UI elements of any size, while configurations of those elements that revolved around specific experience needs were called "patterns".
At Microsoft, I partnered with another system designer, and by workshopping with the rest of our team, we landed on "pattern" as being any UI element that was dependent upon other smaller UI elements. Although not typically my first choice, that was what worked best for our team and tenants.
At PennyMac, we didn't use the term pattern in our system at all.
Though each of these systems defined the same term differently, I always advocated for the definition that made the most sense to me at the time, while offering my full support behind whichever definition was most meaningful to the folks that consumed from the system.
Measuring Adoption Top
I measure adoption by unpacking the concept of a perfect adoption and modeling for the dimensions of time, space, and anxiety. From there, I can derive adequate signals and metrics for tracking them.
Here's how I did that for the PennyMac Design System called Home.
| Goal | Signal | Metric |
| Intended usage occurred | Component inclusion, token inclusion, principle violations, style violations | Component inclusion rate, token inclusion rate, principle violation rate, style violation rate |
| Usage was effortless | Anxiety and stress, satisfaction | Designer NPS, designer satisfaction, engineer NPS, engineer satisfaction |
| Communication was effortless | Comms overhead, channel usage | Mean contact duration, contact rate, multi-contact rate, channel usage rates |
Turning Adoption Into Value Top
Transforming a design system from cost center to value driver can be modeled and tracked by comparing operational cost, operational value, frequency, velocity, and time.
Cost is a measure of human costs and the cost of tooling. Frequency is a measure of how often various components of the system are used, which includes actual components (a la; Web or React Components), practices, processes, principles, and patterns. This is "adoption." Velocity measures how long it takes for system consumers to accomplish tasks.
Savings is a measure of design costs, frequency, and velocity over time. This translates directly to operational value.
Scaling Past One Top
Advocacy Top
Advocacy can easy account for 50% of my job. At Microsoft, I partnered with two design peers to lead communication and education efforts for our system. As a part of this initiative, I created reference modules within Figma that provided designers with quick and digestible tutorials on key features of the system, without requiring them to launch new browser tabs. Here's an example of a module that I made to explain our implementation of design tokens using Figma Variables.
On Apollo, I implemented a recurring bi-weekly office hours meeting where all designers, engineers, and product stakeholders could openly ask questions and provide feedback. I also created digestible five-minute Loom videos to explain features and updates to the system.
The other side of advocacy comes in the form of governance. I view this as a necessary evil, and it's something that I have strong feelings about. I believe that governance should be automated as much as possible to remove bias, and that the manual parts should be flexible enough for consumers to be able to explore both within and outside of the system, while maintaining its overall integrity.
Automation Top
I design and develop custom tooling to automate as much system maintenance and governance as possible. In addition to the Autopilot plugin, here are some example of other tools I've designed.
Scaffold
Scaffold is a Figma plugin that enables designers to enter information into a simple form, which then automatically builds out all of the pages within a Figma working file using the information provided. The result is a set of clean, consistent files that are well organized and easy to navigate.
Theme Magic
Theme Magic is a Figma plugin for translating designs between light and dark modes. With Theme Magic, designers can select one or more Frames in Figma, and then run the plugin with zero input required to automatically generate a copy of that frame in the oppose theme. Theme Magic is able to detect the theme of the original composition by looking at the color tokens within the composition.
Change Log
The Change Log widget is a simple tool that the Apollo design team uses for tracking changes at the component level. It automatically logs the name of the recorder, and is instrumental for consumability and collaboration with stakeholders.
