Design systems fail in predictable ways. Tokens drift from what's actually in production. The same component gets built three times because nobody could find the first one. Documentation describes a version that shipped two quarters ago, which is worse than no documentation because people still trust it. The cost lands as engineering rework, product surfaces that don't match each other, and designers who quietly stop using the library.

I work on that gap. Over the past decade I've done this at eBay, Microsoft, Nike, Venmo, and Verizon — building the foundations, the sync tooling, and the documentation that keep a system honest as the number of teams depending on it grows.

You can see the work, writing, and projects at darianrosebrook.com.

I'm not actively job seeking, but I'm glad to talk with anyone working on design infrastructure, interaction tooling, or the org problems that come with scaling a system across teams.

• Cross-platform foundations (Web, iOS, Android) Without shared foundations, three platform teams solve the same problem three different ways, and every future change has to be negotiated three times. I build foundations where platform differences are deliberate choices rather than accidents of who implemented what first.

• Design-to-code pipelines and token synchronization Every manual translation between design and code is a place for drift to enter, and drift is only found later, by a customer or a QA pass. Token sync and implementation-ready components remove the translation step instead of asking people to be more careful.

• Tooling that removes friction at the point of use Teams rarely skip the design system because they disagree with it. They skip it because using it is slower than not using it. Plugins and internal tools are how I make the supported path the fast path.

• Documentation that stays close to the code Static specs are stale the day they're written, and the people who need them most are the least equipped to spot the parts that are wrong. I build documentation that lives next to the implementation so the two can't diverge silently.

• Accessibility, color contrast, and type fidelity Accessibility retrofitted at the end of a project is expensive, and usually incomplete. Encoding it into the foundations — APCA contrast, variable font handling, type metrics — makes the compliant option the default one rather than a later cleanup task.

• Typographic and visual inspection tooling Type decisions get made by eye and then argued from opinion, because the underlying metrics aren't visible to anyone. Canvas-based inspection and font metric analyzers turn those arguments into something measurable.

• Making the reasoning legible A system holds only as long as the people using it understand why it's shaped the way it is. Otherwise every edge case becomes an escalation to whoever wrote it. I put the reasoning where the decision actually gets made.

• Component releases went from weeks to hours At eBay and Nike, most of a release wasn't building the component — it was the coordination around naming, theming, and getting tokens in sync. Automating that coordination cut release time by over 90%.

• Replaced parallel forks with shared foundations Co-led Nike's Podium Foundations Library and eBay's token and component architecture, so multiple enterprise and consumer teams built on one foundation instead of maintaining divergent copies of it.

• Gave design leadership real numbers instead of anecdote At Verizon, adoption and coverage were known only by impression, which made investment decisions guesswork. I built a real-time analytics platform over Figma and GitLab so gaps and adoption could be measured across the org.

• Moved system checks from review time to authoring time Reviews kept catching the same problems, late, when they were most expensive to fix. Plugins like "Designer's Definition of Done" and interactive component blueprints surface those checks while the work is being done.

• Made browser debugging match how developers actually reason On Microsoft Edge, developers debugging layout and typography had to infer structure from a flat DOM tree. I built 3D DOM inspection and font diagnostics so the structure and the metrics were directly observable.

• Embedded in squads rather than handing off to them Handoff is where intent gets lost. Working as both product designer and design systems engineer lets me stay in the squad through implementation, where the decisions that break systems actually get made.

• Helped designers move into systems and design ops work There's little practical material for designers making that transition. Through writing, podcasts, and long-form articles, I've worked with thousands of designers on the shift toward systems thinking.

LinkedIn · Twitter · YouTube · Articles Or reach out: hello@darianrosebrook.com