MMXXVI
Phases
The Process
Every project is different. The shape of the work is not — research, then synthesis, then drawing, then handing it off. Four phases, in order, with a great deal of pacing back between them.
Discover.
Research, stakeholder interviews, competitive analysis, and user empathy mapping to understand the problem space. The thing the project is for rarely shows up in the brief; it shows up around the third coffee, when someone says but really, the problem is —.
The first month of any engagement is mostly listening — to teams, to support tickets, to the quiet pauses in user-interview recordings. I take notes by hand and transcribe them by hand. The friction is the point.
Define.
Synthesize insights, define personas, map journeys, and establish clear design principles and success metrics. Principles are guardrails, not garnish — they have to make decisions easier later in the project, not harder.
I write a one-page north star document at the end of every Define phase. If a future decision can't be checked against that document in under thirty seconds, it isn't actually a principle yet.
Design.
Ideate solutions, create wireframes and prototypes, establish a visual language, and iterate based on feedback. I draw screens before I draw systems, and systems before I draw screens. The first pass is always one specific moment, rendered in detail; then the tokens, the components, and the rules.
I'm a vocal advocate for prototyping in the medium of the final product — code, or as close as the team can stomach. Static mockups lie about motion, density, and the feel of touch.
Deliver.
Handoff to development, create documentation, conduct usability testing, and refine based on real-world usage. The artifact of design is not a mockup; it is a shipped behavior. I prefer teams that ship.
I write release notes in the design system the way an editor writes them in a typography journal — with care, and with a sense that someone will read them. Documentation is design.