One standard built in flight

Three constraints I inherited

Design

What builders chose, learned, or never touched

I structured the system in tiers — primitives, components, and, rarely, patterns — not for scalability's sake, but to shape our design and builder partnership. Primitives stayed locked in the code I owned; builders worked one level up, choosing from a pre-built library of components, and only rarely combining them into larger patterns.

Typography was the one tier builders learned rather than had locked down for them. A detailed usage guide I put together empowered them to make that call themselves — recognizing which type standard, ServiceNow-native or not, applied to whatever they were building.

Owning the code layer builders couldn't touch

WalkMe's defaults didn't give us control over HTML structure, and unlike an engineering team, builders had no way to patch a broken component themselves. I wrote the HTML and CSS for every component myself — not a stretch assignment, but the only way to guarantee nothing broke downstream, because no one else could fix it.

Pre-built components, self-serve documentation

Documentation did two jobs. Pre-built variants covered the common cases, so most builders never had to make a design decision. For the rest, a usage guide taught just enough judgment to recognize a mismatch and flag it to design — self-serve by default, with a built-in escalation path.

The system as infrastructure

When it shipped, adoption specialists with no design or engineering background could build on-brand experiences independently — and knew when a case fell outside the system and needed design input. The goal was never builders who worked like designers. It was a system that made judgment unnecessary for the common case, and legible for the rest.