About
How I work, what I believe, and what I’m good for.
I’m a Senior Product Designer. Over 10 years designing enterprise SaaS, fintech, and consumer products, from research and strategy through to the shipped UI. For the last three, I’ve built them in code too. That combination is rare: most designers don’t ship production code, and most engineers don’t come from design.
I care more about the stuff below the interface than the stuff on it. The interesting problems at senior level aren’t “how does this screen look.” They’re “what is the right product to build, and how do the systems underneath support it.” Design thinking is the lens; engineering is the way I get to ship the answer.
Design and code, not design or code
The gap between designed and shipped used to be weeks. A spec, a handoff, a slow loop of reviews. The compromises stacked up on both sides. The design drifted, the implementation drifted, and the thing that actually shipped was a third, worse thing. I got tired of it.
Now I close the loop myself. I design in Figma when structure needs thinking through, and I build in TypeScript when the real answer is in the interaction. Some problems only become visible in code: the latency of a state change, the feel of a transition, the way a form field fails. Those are design decisions, and they’re easier to make while writing the code that renders them.
Accessibility as a default, not an audit
At Peak I led the first accessibility playbook (WCAG 2.1) and a colour-vision-deficient data-visualisation framework. At IBM’s Weather Channel I ran the design QA and accessibility audits for products at 100M+ MAU. The lesson from both: accessibility is a design-system problem, not a ticket-tracker problem. The patterns that make a chart or a form accessible for one user make it more resilient for every user. Screenshots, projectors, eye fatigue at 4pm, the subtle ways interfaces fail.
My rule of thumb is the same everywhere: colour alone is never sufficient. Every piece of information carried by one channel should be carried by at least one more.
AI agents as leverage, not replacement
I use Claude Code, Windsurf, and ChatGPT daily, across the whole design process. They help me synthesise research, draft and pressure-test flows, and turn a direction into a working prototype in hours instead of days. They’re also why I can ship a product end to end on my own: a multi-tenant SaaS in 11 days (Nexus Portal), or an AI code reviewer I actually use on my own repos (CodeLens).
What the agents don’t do is taste, strategy, or judgement. They can write a data model; they can’t tell you which data model is right for a product that hasn’t been built yet. They can implement a flow; they can’t tell you what the flow should look like for a user who hasn’t used the thing before. I do those parts. The agents do the typing.
The result isn’t cheaper design or faster coding. It’s a tighter loop between deciding what to build and having it running in front of a user. That loop is where good products come from.
What I’m good for
Teams I’ve done my best work with have three things in common:
- A complex product domain. Data-heavy dashboards, AI-assisted workflows, identity verification, forecasting. The kind of products where the hard part isn’t the UI. It’s figuring out what the UI should say.
- High-velocity shipping culture. I work fast and I work end-to-end. Long handoff loops kill the thing that makes me useful.
- A willingness to let design lead the technical call occasionally. Some product decisions get made by the person drawing the flow, not the person designing the database. I’m that person.
If that’s you (a Senior Product Designer role, ideally with product ownership and room to prototype in code) I’d like to hear from you.