My workflow
This is the way I work. The way I think. The way I like to make things happen.
Getting curious
Before I draw anything, I find out what’s actually going on: the product, the business behind it, the people using it and the constraints nobody put in the brief.
Most projects arrive with a solution attached. My job here is to find the problem it was meant for.
How I do that?
- Heuristic Audits
- Data and Analytics
- User Testing and Ethnographic Observations
- Product and Market Analysis
Getting clear
Research is only useful once it turns into a decision. I boil what I’ve found down to the few problems worth solving, and the ones we’re leaving alone on purpose.
Then I give it a structure: what goes where, how people move through it, and which rules the whole thing has to follow.
How I do that?
- Problem Framing
- Information Architecture
- User Flows and Wireframes
- Design System Strategy
Getting things done
This is where it becomes screens. I design the flows and the interface, build the components behind them, and document everything so developers don’t have to guess.
How I do that?
- Interaction Design
- UI (User Interface) Design
- Service Design
- Documentation Design for Developers
- AI-Assisted Design and Build
Getting better
Nothing survives first contact with real users, and that’s fine. I test, listen to the team and to whoever is using it, and fix what didn’t hold.
Then I do it again, until the product works without me in the room.
Next step
Got a project stuck somewhere between step one and step four? Tell me where, and we start from there.