Frontend lead
Anaplan Design System
Joined as the project transitioned from hope to funded initiative. Stayed 3.5 years as frontend lead (after the founding engineer moved on), growing the system from SCSS variables and manual components to composable React and complete design tokens. Spanned C-suite advocacy, designer partnership, engineering execution, and DevOps delivery.
Origin
Anaplan’s design system existed as a shared hope between a designer and an engineer before I arrived, moving from hope into a funded initiative just as I came on board. The first job was to begin equipping product teams: SCSS variables and CSS, JS, and markup components with clear usage guidance, built for manual inclusion by teams that weren’t yet ready for a package-managed dependency.
What we built
Our system grew in two phases. The first was infrastructure. Extract and synthesize patterns from across product surfaces, document them, and give teams something they could pull into their apps without a build-step rewrite. Every component was delivered with usage guidance, because adoption is a communication challenge as much as a code problem.
The second phase began when the founding engineer moved on and I took frontend lead. Over the next three years I was the sole continuous contributor. We built the system into a composable React component library with a complete design-token layer, Jest and Cypress tests, and a CI pipeline that let product teams consume it as a package. TypeScript, React, Node, Docker and Kubernetes, Jenkins. Internationalized, usability-focused, and WCAG AA across content and controls.
The four surfaces
Design systems die from non-adoption more often than from technical flaws. Four surfaces had to be tended in parallel:
- Advocacy, from C-suite through to consuming engineers. The case for investment has to be made, and remade, at every level that signs off on headcount or roadmap space. Happily, the upside of a unified presentation across products and web properties is easily understood, and components that reduce work are readily adopted once this is known.
- Designer partnership on usability and accessibility. Hand-offs corrode; partnership compounds. Accessibility reviews worked best as part of design critique, not as a gate at the end.
- Engineering execution. Ship the components, keep the docs current, demonstrate real use across properties. The library was credible because it was used in the products, not just described in Storybook.
- DevOps collaboration on pipelines and delivery. A component no one could install, or that broke a consumer’s build, was a component no one trusted.
Reach
Broadly adopted across Anaplan’s SaaS product and web properties, covering interfaces for engineers, SaaS users, content administrators, and public web visitors. The same component vocabulary spread across audiences that rarely share one, telling a story of cohesion and trustworthiness.
What it taught
If I had to frame it as a lesson (it’s how this is apparently done?): Come in early. Drive technical evolution. Own advocacy across technical and business audiences. Raise standards. Maintain coherence of purpose through personnel changes and scope shifts. Test.
Planning and hoping for more personnel consistency at Veridi and NetterTech, but the shipping discipline is the same.