How I work: from adoption problems to an experience that works
I don’t deliver abstract recommendations. I deliver documented flows and functional prototypes your team can implement starting the next day.
Principles that guide my work
First I understand the problem, then I propose the design
I don’t start with the solution. Before designing any flow, I understand how the current user interacts with the feature, where they lose trust, and what they expect to happen when the AI acts. Only then do I design.
I design for real AI behaviors, not ideal ones
Most adoption problems come from designs that assume the AI always responds well, fast, and with certainty. I design for real latency, uncertain responses, errors, and fallbacks. Those states define whether the user trusts or abandons.
I deliver prototypes in code, not in Figma
I increasingly deliver functional prototypes that already account for real response times, loading states, and the non-deterministic behaviors of AI. Your engineering team receives something that already works, not an interpretation of what should work.
The human always knows what the AI is doing and why
I design the system’s autonomy boundaries: what the AI decides on its own, when it asks for validation, and how it communicates its decisions. User trust isn’t built with good UI, it’s built with sustained transparency.
A single point of contact who understands the full problem
I cover experience design, interaction logic, and engineering. You don’t need to coordinate between three different people for someone to understand the entire problem.
First I understand the problem, then I propose the design
I don’t start with the solution. Before designing any flow, I understand how the current user interacts with the feature, where they lose trust, and what they expect to happen when the AI acts. Only then do I design.
I design for real AI behaviors, not ideal ones
Most adoption problems come from designs that assume the AI always responds well, fast, and with certainty. I design for real latency, uncertain responses, errors, and fallbacks. Those states define whether the user trusts or abandons.
I deliver prototypes in code, not in Figma
I increasingly deliver functional prototypes that already account for real response times, loading states, and the non-deterministic behaviors of AI. Your engineering team receives something that already works, not an interpretation of what should work.
The human always knows what the AI is doing and why
I design the system’s autonomy boundaries: what the AI decides on its own, when it asks for validation, and how it communicates its decisions. User trust isn’t built with good UI, it’s built with sustained transparency.
A single point of contact who understands the full problem
I cover experience design, interaction logic, and engineering. You don’t need to coordinate between three different people for someone to understand the entire problem.
What it’s like working with me
- •We start with a free conversation to understand where the real problem is.
- •If it makes sense to move forward, we define the scope and the most suitable work format.
- •I work iteratively with visible deliveries, not months in silence.
- •Direct and frequent communication, you know what I’m working on and what comes next.
- •Deliverables are actionable from day one, not decks with recommendations nobody implements.
- •We start with a free conversation to understand where the real problem is.
- •If it makes sense to move forward, we define the scope and the most suitable work format.
- •I work iteratively with visible deliveries, not months in silence.
- •Direct and frequent communication, you know what I’m working on and what comes next.
- •Deliverables are actionable from day one, not decks with recommendations nobody implements.
If you're building something with AI, or want to start, let's talk.
Available for new projects. I respond within the first 24 hours.