How I work
Five phases, in order. The uncomfortable ones — naming what would falsify the direction, and saying which numbers are still guesses — are the ones that make the rest worth anything.
The ring is the shape of the process — the sections below are the detail.
01Understand
I start by finding out what is actually true about the problem, from the people who have it, before proposing what to design.
Understanding starts with the people who would use the thing, not with an interface idea. I run interviews, look at what already exists through competitive analysis, and map the journey someone follows today to get the job done. On agency and enterprise engagements that has meant global usability research; on my own concept work it means interviews and a competitive teardown before a single wireframe. Nothing gets designed until I can state the problem in the words of the person who has it.
- User interviews
- Journey maps
- Competitive analysis
- Field research
02Define
I turn what I learned into a specific problem statement and a definition of success, before any screen gets designed.
Research only helps if it turns into a decision I can be held to. I write the problem down in one sentence specific enough to be wrong, and name what a good outcome would actually look like before any screen gets designed. On systems work that also means writing down the design principles the interface has to hold to, the same color or interaction rule meaning the same thing everywhere it appears. Definition is where scope gets set, so validation later has something honest to test against.
- Problem statements
- Success criteria
- Design principles
03Design
I move from rough directions to a detailed interface, checking every decision against the system as I go.
Design starts with more than one direction, in wireframes and rough flows, before any gets refined into a final interface. Every decision gets checked against the system rather than the single screen in front of me: does this color, this spacing, this interaction pattern already have a token or a component, or does it need one. That discipline is what let design systems like Oracle’s Redwood and CloudNatix’s own run across a hundred products or a whole platform, and it is how I still work on a project of one.
- Wireframes
- Interaction flows
- Design tokens
- Component libraries
04Validate
I test the design with real people before calling it done, and I report what the test actually showed.
Before a design ships, it gets checked two ways. A heuristic evaluation catches the structural problems a trained reviewer can spot without a single user in the room. Moderated usability testing on a working, click-through prototype catches the ones only a real person attempting a real task will surface. I score sessions against a rubric rather than relying on impressions, and I write down what happened even when it is not the result I was hoping for. A concept that has not been tested this way stays labeled as untested.
- Heuristic evaluation
- Moderated usability tests
- Click-through prototypes
- Accessibility review
05Ship
I take the design through to shipped, working code, and I keep watching how it performs after launch.
Handoff is not always the end of my involvement: increasingly there is no handoff at all, because I build the front end myself in React, TypeScript, and Tailwind, against the same system the mockups came from. Where I do hand off, it goes to a living design system, not a static file, so a component behaves the same way for an engineer as it did in the design tool. Either way, I keep watching how the shipped interface actually holds up, not just how it looked at review.
- Front-end implementation
- Handoff with a living design system
- Post-launch review