What I do
I make the words on your screen make sense — and keep them that way as the product changes.
How I do it
I start with the places people get stuck: empty states, dead ends, names that don’t mean anything yet,
flows that were designed with lorem still in them. I fix a few visible problems first,
then dig into the system underneath — IA, patterns, ownership — so the next release doesn’t recreate the same mess.
Where I plug in
You’re probably here because something looks finished and still confuses people, or a feature is ready and nobody knows what to call it,
or the team built content debt faster than anyone can pay it down. I’ve done this as an embedded lead and as a contractor.
Either way, I’m usually the first officer to the designer or PM piloting the work: I navigate while they drive, and we ship together.
How I like to work
I’m decisive. I’ll tell you what I need, what I need from you, and what “later” will cost if we kick it.
Ambiguity is fine — that’s a known unknown. What I won’t do is pretend “we’ll figure it out later” is a plan
when it usually means the day before launch or the day after never.
I do my best work when I can present my own recommendations to stakeholders, argue in good faith, and leave with clear owners.
I’m a poor fit for “disagree and commit” without reciprocal engagement, or cultures where “everyone owns content” means nobody does.
Where I thrive
- Framing problems and goals so the room can actually agree
- Naming the work, assigning ownership, and moving
- Planning for best case and worst case before either arrives
- Pushing back on incentives that make products worse over time
- Unblocking other people and making the learning stick