About Me

I've been in and around front-end development for the best part of twenty years. I care deeply about craft - semantic HTML, modern CSS, accessible interfaces - but I'm just as interested in the architecture around the work: how token decisions made early ripple through everything later, where design-to-code pipelines quietly introduce friction, and why most component libraries solve the wrong problem.

If you're wondering what "design systems engineer" actually means in practice, I'll come back to that.

What I actually do

At my core, I build systems, and then I build the things that live inside them. The unglamorous bit that nobody talks about in job ads, and the bit that determines whether everything else works.

That usually looks like some combination of:

• Design system architecture
• Token strategy & naming conventions
• Design-to-code pipeline
• Component libraries
• Production-ready HTML & modern CSS
• Accessibility
• JavaScript & React
• Prototyping & discovery
• Web standards
• Mentoring & workshops
• Community building
• Public speaking
• DevOps & delivery metrics

Alongside the hands-on work, I spend a lot of time on the stuff that determines whether any of it lasts: architectural decisions at the foundation level, championing accessibility as a baseline quality requirement rather than an afterthought, and driving adoption across teams through influence, education, and trust rather than formal authority.

I'm also increasingly focused on translating complex architectural decisions into language that actually lands - with engineers, with designers, with product stakeholders. A design system nobody understands is a design system nobody uses.

In short: I like building systems that make other people's work easier. And I like leaving things better than I found them.

What I don't do

• Back-end development: not my bag
• Heavy OOP-style JavaScript: that's a different job
• Fixing printers, Wi-Fi, or "quick IT things"

Life's too short.

A bit of history (the short version)

I spent nearly eight years at an agency working my way up to Senior Front-End Developer: the kind of environment where you learn fast because there's no one else to fix it.

From there: UI Engineer at Zuto, then four years at Auto Trader as a Principal UX/UI Developer, focused heavily on accessibility, inclusive design, and front-end quality at scale. That's where the accessibility conviction really took hold, because it stopped being theoretical and became about real people hitting real walls.

Next came Co-op, where I was Lead Front-End Design Engineer on the design system: building shared components, shaping contribution models, and learning how much harder adoption is than implementation.

At cinch I took on a broader Engineering Practice Lead role: improving standards, rebuilding communities, clarifying expectations, and co-creating the engineering progression framework. Less building, more convincing. Turns out, that's a skill too.

Since then I've continued working as a Principal Design Systems Engineer, staying hands-on while pushing further into the architectural and strategic side of design systems. The DORA and SPACE interest crept in along the way, mostly because I got tired of teams measuring the wrong things and calling it progress.

So: Design Systems Engineer. What does that actually mean?

It's still not a title with a universally agreed definition, which is either a feature or a bug depending on your tolerance for ambiguity. The short version: it's someone who treats a design system as a product with real architectural concerns - not just a component library with a Storybook attached.

For me, that means caring about the decisions that happen before any components get built: how tokens are structured and named, what abstraction layers exist (and why), how the system will need to evolve as the product scales, and whether the people meant to use it actually will. It means being comfortable enough in both design and engineering to bring implementation-aware design thinking into conversations on both sides - without losing anything in translation.

It also means thinking about the design system not just as a resource for the people using it today, but as structured context that tooling, pipelines, and increasingly AI-assisted workflows need to consume reliably. The naming conventions, the architecture, the documentation - those aren't just human concerns anymore.

I don't do visual design. But I shape how things behave, scale, and hold together over time, and I'm deeply sceptical of systems that look great in a handoff and quietly fall apart in production.

It's a specific kind of role. I've been growing into it for years, and I think I'm finally honest enough to admit that's what it is.

Outside of work