Product designer · Design systems · AI-native UI

Twenty-plus years in the Valley. Now home in London.

I build the system underneath the product. Design systems, and the governance that keeps AI-generated UI on-system and actually good, from first prototype to production code.

San Francisco Bay AreaLondon
What I do

I work on the seam between design and engineering, and I treat that seam as a product.

i.

Design systems as infrastructure

Tokens, components, patterns, governance and release, owned end to end as something the whole company builds on.

ii.

Design-to-code governance

The checks that keep AI-generated and hand-built UI on-system, and the process that turns real gaps into real components.

iii.

Taste as a system input

Craft rules written down so AI tools produce screens that are good, not just compliant. Design judgement stays human.

Selected work

Recent work at a cybersecurity platform company.

Most of my recent work is under NDA. What's here is my role, my reasoning and the outcomes, with diagrams drawn fresh for this site.

The governance loopAn idea is generated by a person or an AI tool, then checked against the kit. On-system work snaps to the system and ships. Anything new files a typed gap, a designer makes the UX decision, it becomes a real component, and it goes back into the kit that future checks use.IdeaGenerateperson or AI toolCheckagainst the kitThe kitparts, coloursSnap to systemthen it shipsFile a gaptyped, visibleUX decisiona designer calls itReal componentfitsnewback into the kit
The loop, redrawn for this site. Labels are illustrative.
01 · Flagship · Design-to-code governance

Keeping AI-generated UI on-system

The problem
AI tools could produce a product screen in minutes. Nothing stopped them inventing colours or rebuilding components that already existed.
What I built
A governance step between "someone generated a screen" and "it ships". It checks against approved parts and colours, fixes what it can, and files a clear gap for what it can't.
What changed
It became a named step in the engineering org's AI development workflow, other teams' tools depend on it, and the CTO sponsored rolling it out to designers and PMs.
The call that mattered: permit new compositions, prevent undeclared visual decisions.
Read the full case study →
Passing versus goodTwo layers. The bottom layer is the automated check, which proves a screen is built from approved parts. The layer above is UX review, which asks whether it's actually good. Tooling raises the floor; design judgement stays human.UX reviewis it actually good? hierarchy, densityThe checkbuilt from approved partsDesign judgementstays humanTooling raisesthe floorA passing check gets you here, not to the top.
02 · Craft and AI

Green doesn't mean good

The problem
Generated screens came back technically correct and completely characterless. Every instruction the AI tools received was a prohibition. Nothing said what a good screen is.
What I did
Wrote the craft layer the tools read: what a screen leads with, how much each region can carry, when structure beats colour. The guidance grew from about 60 lines of "don't" to about 170 that include "do".
The call that mattered
I showed screens that passed every rule and were still wrong, and put the question in writing. The workflow's owner agreed that a passing design still goes through UX before engineering.
Passing means built from approved parts. It never meant good.
The coverage auditA grid of about 100 hand-built elements. About 7 were things the system genuinely couldn't do. The other 93 or so rebuilt components that already existed.About 7: genuinely missingAbout 93: already in the kit
03 · Evidence-led roadmap

The audit that changed the roadmap

The assumption
People went off-system because the system was missing things. The obvious answer was to build more components.
What I did
First I checked the gate could actually see. I hand-built a chart that should have failed, and watched it pass. Then I built a coverage pass that sorted every element into on-system, plumbing or hand-built.
What I found
Of roughly 100 hand-built elements, only about 7 were things the system genuinely couldn't do. The rest were rebuilds of components we already shipped.
What changed
The roadmap moved from "build more" to "make it findable". Cheaper, and it fixed the real problem. [NEED: what shipped after, in one line]
Field notes

Still hands-on. Still checking my own work.

Hands in the code

The bug that survived two fixes

A date field kept jumping to the wrong month for some regional formats. Two fixes shipped over two months and neither worked.

I reproduced it in the browser instead of guessing from the code. The on-screen hint and the parser disagreed, and the tests only ran in the one setting where they matched. I fixed it, changed how component tests are written, then found the release pipeline wasn't publishing and checked the published package myself.

A tag isn't a release.

Working with AI

Being wrong in public

An AI-assisted analysis said the dark theme was half-built. It went out as a proposal and got accepted.

Then I went back to the actual screen. Every system component was fine. The only broken card was hand-built. I retracted it the same day, where the original went, kept the original visible, and turned the smaller true finding into its own proposal.

AI makes a plausible analysis cheap. Checking it is the job.

Principles

A few things I've learned the long way.

A passing check proves a screen is built from the right parts. It can't prove the screen is good.That part stays with designers. Good tooling just gives them more time for it.
New is never a failure. Undeclared is.A design system should be a floor, not a ceiling.
Measure it. Don't infer it.AI makes a plausible analysis cheap. Checking it is the job.
If it needs a walkthrough, it isn't finished.Plain language for PMs, designers and engineers alike.
The long arc

Twenty-plus years. One through-line.

I've been making software make sense to people since before most of today's tools existed. I've shipped through every shift, from desktop to web to mobile to AI. Now I'm bringing that back to London.

20+years designing software
[#]products shipped
10+companies, from startups to enterprise
1homecoming
  1. 2022 to nowStellar CyberLead Product Designer · LondonOwn the design system and the design-to-code governance behind the company's AI-native development workflow.
  2. 2020 to 2022Palo Alto NetworksSenior Product Designer[NEED: one line on what you owned and what changed.]
  3. 2016 to 2020PagerDutyVisual Lead[NEED: one line on what you owned and what changed.]
  4. 2012 to 2016Sony, Samsung, PRO UnlimitedSenior UI/UX and visual designTook a Sony Android app from first wireframes to launch, working with design teams in San Diego and Tokyo. Then senior visual design at Samsung and PRO Unlimited.
  5. 2006 to 2012Strikeforce, Align Technology, ShutterflyCreative Director, UI Designer, Senior DesignerWhere the craft started. Led creative direction and a full brand reinvention at Strikeforce, the MMA promotion later bought by the UFC's owner.
Earlier work

[NEED: the PagerDuty story. Four years as Visual Lead at a well-known developer tools company]

[The problem, what you did, what changed. Three lines is enough.]

Contact

Looking for a Staff or Principal role where this is the job.

Design systems, design engineering, AI design tooling. London or remote across the UK and Europe.

Email me LinkedIn CV (PDF)