Where the hours go
One project. Five moves.
Rough proportions across a real engagement. Figma is the shortest of them.
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.
Eighteen 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.
I run AI-augmented research and synthesis.
Claude for clustering 200-plus community posts. AI-assisted competitive audits. AI-augmented production workflows that cut a creative team's timelines twenty percent at VARA without dropping quality. The model is the second pair of hands, not the designer.
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. Eighteen years across marketing, operations, and product mean I can hold all three conversations without the relay.
Eighteen years across all three · no relay needed
If any of this reads like the seat you're trying to fill, the case studies show it running in the artifact. The contact page is the shortest way to start.
Get in touch