What I add first isn’t a Figma file. It’s a sharper problem statement.
Two frames on this page. Where I add value, in the language teams already track. And how I think about the work, in the language I actually use.
One project. Five moves.
Ranked by hours. Figma is the shortest.
01
Framing
02
Research
03
Decisions
04
Ship
05
Figma
Sharpen the question. Cut the wrong-brief weeks.
Interviews. Clustering. The pattern surfaces.
Trade-offs named in the language the org tracks.
Handoff, QA, iteration. The work ships.
Finally, the pixels. Twelve of one hundred.
Move across the ribbon to explore each move
One project. One hundred hours. Five moves.
Where I add value
The shorter version of how the work pays back.
I frame the problem before Figma opens.
Most design hours go to the wrong question. I push for a sharp problem statement at the start so the team doesn’t spend three weeks building a beautiful answer to the wrong brief. The case studies show the artifact; the savings happen earlier.
I tie design decisions to business outcomes.
Revenue, retention, ship dates, ML-signal integrity. Every callout you see in the case studies names a trade-off in those terms. Stakeholders stop arguing about taste when the cost is named in the language they already track.
I talk fluently with PMs, engineers, and stakeholders.
Fifteen years across marketing, operations, and product mean I can hold a technical review, a stakeholder briefing, and a research synthesis without translation cost. Less translation, fewer meetings, fewer surprises.
How I think about the work
A few things I’ve come to believe.
Design is decision-making.
Everything visible on a screen is a record of choices someone made, and could have made differently. If you can’t explain what you didn’t build and why, you didn’t really design it. You just shipped it.
Problem framing comes before pixels.
Most designs fail at the question, not the execution. What problem, for whom, under what constraints, and what would success actually mean. If those four answers aren’t clear, the prettiest interface in the world won’t save the work.
Prototypes are probes, not proof.
You build them to find out, not to convince. If you can’t name in one sentence what the prototype is trying to teach you, you’re producing, not prototyping.
The best design decisions are also the cleanest business calls.
When a trade-off is named in the language the org already tracks, stakeholder debates resolve fast. Most arguments about taste are really arguments about cost that nobody named.
Translation cost between disciplines is real.
Designers, PMs, and engineers each carry a dialect. The team that doesn’t need a translator between them ships faster. Fifteen years across marketing, operations, and product mean I can hold all three conversations without the relay.
How I use AI
AI holds the complexity so I can hold the craft.
Every project passes through a stack I’ve built inside Claude Code. Twenty-plus custom skills automate design-system audits, voice reviews, brand-token checks, competitive scans. A dozen subagents handle research, critique, and copy sweeps in parallel. A vault holds every design decision, every review, every project log, so context survives between sessions.
The point isn’t speed. It’s holding more without dropping. Eighteen concurrent projects instead of three. Every case study checked against Designing with Intention, Refactoring UI, NN/g, and the twenty senior portfolios I calibrate against. The review happens automatically. Every deliverable filtered for AI-tell vocabulary against my own voice profile. The edit pass is scripted.
What AI doesn’t do: pick the direction, make the taste calls, decide what to refuse. Those stay mine.
If any of this reads like the seat you’re trying to fill, the case studies show it running in the artifact. An email is the shortest way to start.
Get in touch