How I Work
My job is to move things forward across timezones, disciplines, and levels of ambiguity without adding more coordination overhead than I remove.
Problems I Help Solve
What I bring to a project is a combination of research rigour, pragmatic prototyping, and the ability to work across disciplines without losing sight of the actual users.
Validating Ideas Before Committing
I build functional prototypes, real enough that users can play with them and give you feedback that counts for something. There is a world of difference between clicking through a Figma file and using something that runs in a browser.
Outcome: Validated direction in days rather than weeks, async-compatible.
Teams That Aren't Aligned
Cross functional friction is bad enough in the same office but it builds up fast across timezones. I work with structured async documentation, targeted virtual workshops, shared Figma/FigJam spaces that provide distributed teams with a single source of truth.
Outcome: Distributed teams that move forward together, without the meeting overhead.
User Research That Leads Somewhere
Surveys and generic usability tests often produce data that feels reassuring without being useful. I run structured research using frameworks like HEART and CASTLE designed to generate insights tied to specific decisions.
Outcome: Directions the product team can actually act on.
Fragmented Ecosystems
When companies grow fast or through acquisitions, tools often end up looking and behaving differently. Users have to context-switch constantly. Design Systems are my answer: a shared foundation that unifies the experience and reduces development time.
Outcome: Consistent experiences across products and faster implementation.
Design Debt
Applications age. Interfaces that made sense three years ago start to accumulate friction: inconsistent patterns, workarounds layered on top of workarounds. I audit what exists, identify where the debt is worst, and propose improvement strategies that are realistic.
Outcome: Fewer bugs, simpler maintenance, and users who spend less energy fighting their tools.
What Working With Me Looks Like
I’ve been working with distributed teams for over a decade so remote isn’t a constraint I’ve adapted to, it’s just how I work. In practice: async by default, clear documentation of decisions, files organized so anyone on the team can get up to speed without a meeting. I’m responsive during CET business hours with natural overlap with UK and early US East Coast hours. I travel for workshops, sprints, or alignment sessions that truly need real-time collaboration. Paris to London or Berlin is half a day.
Early Stage
- Scoping the problem
- Identifying the right users to talk to
- Running design sprints to generate and pressure-test ideas
Mid-Build
- Shaping the interaction model
- Designing and iterating on screens
- Working alongside developers in sprint cycles
Post-Launch
- Auditing what's working and what isn't
- Running usability tests
- Proposing a roadmap for improvement
Most engagements start with a 30-minute call to understand the context and constraints. If there's a fit, I typically begin with a short scoping phase before committing to a longer contract. This protects both sides and gets us to useful work faster.
Examples of Deliverables
Before & After 
Before & After 
Experience Map 
Personae 
Screen Flows 
Sketch 
User Testing 
Design Sprint Board 
Design Sprint Board The Way I Think About Design
I have worked in agencies, in-house teams, startups and corporate innovation labs in France, Australia, China, Japan and Belgium.
What that teaches you is that design doesn’t travel well in nature. What is obvious to the user is cultural. Assumptions about hierarchy, communication style, etc. I have learned to check mine.
On the technical side: I make working prototypes in code because it changes the quality of feedback I get. It also means I’m still useful long after a traditional designer would’ve passed things off.
Let's Work Together
Have a project in mind? I'd love to hear about it. I reply within 24H.
GET IN TOUCH