How I think about design — and why systems work is the most interesting problem in the field right now.

Most design work optimizes for the single artifact — the screen, the flow, the prototype. That's useful, but it doesn't compound. A single well-designed component that hundreds of engineers can reach for without asking a designer? That compounds. Design systems are the rare design problem where the leverage is genuinely multiplicative, not additive — a true force multiplier for cross-functional velocity.

I came to systems work gradually, through friction. Working in large organizations at Macy's and Wells Fargo, I kept running into the same pattern: designers reinventing the same components slightly differently, engineers making judgment calls that were really design calls in disguise, and documentation that was always one sprint behind reality. The solution wasn't to design faster — it was to design once, establish federated governance, and make that once count across the entire technical infrastructure.

The practical version of that belief is: components should be so well-documented that a designer who didn't build them can use them confidently, and an engineer who's never talked to a designer can implement them correctly. That bar requires thinking carefully about semantic taxonomy, component API design, constraint surfaces, and the edge cases that only reveal themselves in production. Framework-agnostic systems that prioritize system interoperability age better and reduce total cost of ownership over time.

At the organizational level, design system maturity directly affects time-to-market acceleration. When the operating model is right — when there's a strategic roadmap, clear design advocacy at the leadership level, and genuine organizational alignment around what the system is for — teams ship faster, with fewer inconsistencies, and with lower institutional knowledge risk. I've seen the difference firsthand. Scalable governance isn't bureaucracy; it's what makes high-leverage tooling sustainable.

AI has changed what's achievable here. I've spent the past year building Claude-powered design-to-code pipelines and workflows that automate the structural parts of spec writing — extracting anatomy, generating audience-segmented documentation, surfacing constraint violations. The goal isn't to replace judgment. It's to eliminate the work that doesn't require it, so designers can spend their time on architecture strategy and the parts that actually move the needle on revenue attribution.

Visual craft still matters inside systems work. The spec sheet, the documentation page, the Figma annotation — these are artifacts that real teams read and rely on. If they're poorly typeset, hard to scan, or visually inconsistent with the product they're describing, they erode trust. Good systems work looks like the thing it's documenting.

The through-line in everything I care about: reduce the distance between a good design decision and the shipped product. Documentation, tooling, governance, AI augmentation — these are all just different levers on the same problem. Mentorship and sponsorship of other designers, preservation of institutional knowledge, and building a culture where design systems are treated as a product — not a tax — is what separates a Principal-level operator from a senior individual contributor.