HOW I WORK
From complexity to clarity. And from clarity to better products.
I help product teams understand complex systems, align decisions, and turn them into experiences that work.
Clearer product structure
Understand how the pieces fit together.
Better-informed decisions
Make important questions visible and discussable.
Ready to move forward
Give your team a direction and usable design references.
When should we work together?
We're building something new
The idea or requirements need a clearer product structure.
Our product is getting complicated
Features, roles, and workflows are starting to overlap.
We're redesigning a critical workflow
A significant flow needs attention within an existing system.
We're ready to build, but questions remain
Product behavior and edge cases still need clarification.
My default starting point is talking to different experts from different teams, because each describes the same system differently.
In several complex systems, I learned the vocabulary before designing anything. In one of them, I even took an online course about the system. There is all kinds of onboarding material to learn from.
I watched users work, listened to recordings of user interviews, and from time to time talked to users myself.
I use AI to scan competitors, terminology, and comparable products, and then check the findings with people.
Understand before solving.
Understand the system
The team can identify dependencies and unresolved questions.
I start by identifying the entities in the system and naming each one.
Then I map how the entities relate to each other: permissions, and dependencies one way or another.
I draw what we need to see, depending on the case: an information architecture, an entity diagram, or the new flow.
I also build a low-fidelity prototype of the new flow, focused on structure rather than visual design.
Find the connections
The team has a clearer direction to evaluate and refine.
Designing a high-fidelity prototype that shows the intended look, behavior and states.
Using the prototype as the reference to teach AI how the product should look and behave.
Extracting colors, type, components and rules from the prototype into a working design system.
Shape the solution
The team has usable references for continued design and development.
The usual handoff package: specs, flows, states and assets, ready for development.
Writing the rules, tokens and component guidelines your team needs to build consistently.
Working in the production code together with developers, when the project calls for it.
Make it tangible
What you walk away with
Product models and maps
A shared view of the system.
Flows and prototypes
A way to review proposed behavior.
UI and interaction design
Concrete design direction.
Rules and documentation
Reusable guidance as the product evolves.
Not every project needs all four. This is an index of outputs, not a fixed package.
Working together
How involved does our team need to be?
Product and domain experts help establish context and review decisions. Developers join early to surface constraints and edge cases. We agree who needs to participate according to the scope and the questions we're solving.
How do you fit into our workflow?
I adapt to your existing tools and ways of working. Structured Markdown and reusable AI context are already part of my practice where useful. I'm continuing to develop AI-assisted code generation and validation; generated changes need review.
What happens when the design is ready?
Your team receives the designs, rules, and reference examples agreed for the project. I work with development on questions within that scope. Design guidance and HTML prototypes support implementation; production development and verification remain with the team responsible for them.