Skip to content
← Back to home

How I Work

I don't show up with a fixed method and apply it regardless of context. Every project starts differently, and my job is to figure out which situation I'm in, then work accordingly.

After 10 years and projects across healthcare, automotive, cosmetics, hospitality, and financial inclusion — in France, China, Australia, and Japan — I've learned that good design is less about mastering a particular toolkit and more about knowing when to slow down and when to move fast, when to push back and when to ship.

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.

Problems I Help Solve

[Design Debt Illustration]

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 — not a full redesign fantasy.

Outcome: Fewer bugs, simpler maintenance, and users who spend less energy fighting their tools.

[Ecosystem Illustration]

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.

[Team Alignment Illustration]

Teams That Aren't Aligned

The friction between designers, developers, and product owners is one of the most expensive problems in product development. I facilitate workshops and design sprints that get everyone working from the same understanding.

Outcome: A team that moves forward together, not a nice document that sits in a drive.

[Validation Illustration]

Validating Ideas Before Committing

I use AI-powered tools alongside HTML, CSS, and JavaScript to build functional prototypes fast. Not polished, not production-ready — but real enough that users can interact with them. The difference between a Figma prototype and something that runs in a browser is significant.

Outcome: Validation in days rather than weeks.

[Research Illustration]

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.

The Way I Think About Design

Design is not a deliverable. It's a way of approaching problems: with curiosity, some scepticism, and a bias toward making things concrete rather than leaving them abstract.

I've spent time in agencies, in-house teams, startups, and large corporate innovation labs. What stays consistent is a preference for getting something in front of real users quickly, listening carefully to what they say and what they don't say, and iterating from there.

I'm also genuinely interested in the technical side. I've been learning frontend development for over a year because it makes me a better collaborator with engineering teams. When I can build a working prototype instead of mocking one up, the feedback I get is qualitatively different.

[Process Visualization]

Examples of Deliverables

[Icon] Wireframes & Flows
[Icon] Interactive Prototypes
[Icon] Design Systems
[Icon] Research Reports
[Icon] Workshop Facilitation
[Icon] Working Code Prototypes

Let's Work Together

Have a project in mind? I'd love to hear about it.

GET IN TOUCH