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.
Let's talk about what you're building.
Available for full builds with integrated AI, audits of features that aren't landing, or help evolving your operational software toward AI-native architecture. I'll respond in under 24 hours.