Product design
Products people understand the first time.
I work on the ones with real complexity underneath. Most of the job is figuring out what the system is actually made of, and the screens follow from that. When it goes wrong, it’s almost never because the interface was ugly.
A good fit when
- Your product has more states than screens, and the states are winning.
- Compliance or regulation shapes the flow and nobody has designed around it properly.
- Several roles use the same object and mean different things by it.
- A redesign has been attempted before and collapsed once the edge cases arrived.
- You need someone who'll still be there during build, when decisions get quietly reversed.
Probably not when
- You need a visual refresh and the structure is already sound.
- You want screens produced to a spec that's already settled.
- The timeline can't accommodate a discovery phase of any length.
I’d rather say this upfront than three weeks in. If it’s the second list, I probably know someone better suited.
How it goes
Five steps, and I don’t skip the fourth.
01
Discover
Learn the business before the product. Who pays, what breaks, what's already been tried.
02
Define
Name the actual problem. Usually it isn't the one in the brief.
03
Design
Map the system, then explore several ways through it. Structure before screens.
04
Validate
Put it in front of the people who'll use it, early enough that changing it is still cheap.
05
Deliver
Ship it. I stay through build, because that's where design decisions get quietly reversed.
Tell me what’s broken.
Two or three projects a quarter, booking from Q4. A paragraph about the product and what isn’t working is enough to start.