My process
Before designing anything, I map the people, data, rules, and constraints: stakeholder interviews, domain research, and time with the SMEs who know the real edge cases.
Stakeholder & SME interviews · Domain and industry research · Risk and dependency mapping
I turn research into a clear problem statement, agreed priorities, and a few design principles, so the team knows what we’re solving and why. Those principles become the tiebreaker when tradeoffs come up later.
Problem statements · Design principles · MVP scope & priorities
With complex products, the experience often succeeds or fails at the structure level. I work out entities, relationships, information architecture, and flows before any pixels.
Entity & relationship maps · Information architecture · Journey maps & task flows
I design in the open. As I move from wireframes to high-fidelity prototypes, I bring stakeholders into reviews, engineering into feasibility discussions, and users into testing whenever possible, so feedback shapes the design while it’s still cheap to change. When it surfaces new constraints or edge cases, I revisit the underlying structure rather than force the design.
Wireframes & prototypes · Collaborative reviews · Usability testing
I partner with Product and Engineering through implementation, helping resolve tradeoffs, refine details, and make sure design decisions translate into the final experience. I document reusable patterns and conventions the team can build on beyond the initial release.
Reusable patterns & components · Implementation support · Post-launch iteration