I listen, therefore I make.

I start with what you're hoping for

Before I draw anything I want to know what a good outcome would feel like for the two people who have to live with it: whoever maintains the thing, and whoever it is actually for.

At HP the brief looked simple: digitise a program. Underneath it were partners losing hours to spreadsheets and internal teams re-keying hundreds of price updates by hand. None of that was in the brief. I asked for the time to go and find it, and I got it.

That is usually the part I have to make the case for. I’ve found it pays for itself every time.

I look for the seam

The interesting problem is rarely the page. It’s the place where two groups are quietly guessing about each other, and everyone downstream pays for the guess.

• At HP, internal teams and partners were working from different documents. One published catalog put them on the same page: quoting got 40% faster, and a catalog update went from two weeks to a day.
• At Indopelita, someone would read about a service and then start again at a blank contact form. Now the service travels with them, and the enquiry lands already understood.
• At Moira, what an editor sees while composing a page is the same component the visitor gets. One definition, so the two can never drift apart.

Find the seam and a lot of smaller problems stop happening on their own. That is usually cheaper than fixing them one at a time.

I lead it, and I keep my hands in it

I’ve run this work end to end alongside product managers, engineers, business and data teams, across regions that genuinely disagreed about how things should work. A good part of the job is holding a direction steady while a lot of people pull on it, and making sure the people pulling feel heard rather than managed.

I also build. Moira Studio is a content system I designed and then developed, so their team can publish without waiting on anybody. I do that when it’s the surest way to get the outcome right, not to prove I can. Knowing what something costs to build changes what I choose to draw, and it means the handover has far less to go missing in.

I count it in numbers the business already tracks

Delight matters, and it isn’t the whole argument. I want to know what changed in how people actually behave, in the terms the organisation was already measuring before I arrived.

• 40% faster quoting, and 135 hours given back per person each quarter.
• Over 80% more request-for-quote conversions, and more of the right enquiries.
• 90% adoption across HP resellers in North America, because the new way was genuinely easier than the spreadsheet.

If I can’t say what moved and for whom, I haven’t finished thinking about it yet.

I leave you something that keeps growing

I try to design myself out of the picture. A system that only works while I’m still in the room isn’t finished.

• Moira's team publishes new pages themselves, without a developer.
• Indopelita's design system was built for the features I won't be there for.
• HP's catalog stopped needing a designer at all once it shipped.

If it can’t grow after I go, I treat that as a defect rather than a limitation.

Who I work best with

• Teams with a messy inheritance: a legacy tool, a spreadsheet everyone secretly depends on, three regions solving the same problem three ways.
• People who'll let me talk to their users before I talk about solutions.
• Anyone who cares whether it still works in a year, and who'd rather be asked than told.

You don’t need a finished brief. Half of mine have started as “we think something’s wrong here, but we can’t name it yet.” That’s a good place to begin.