I design products in the broadest sense: systems, services, objects, and the connections between them.

My work focuses on turning complex operational situations into products that feel coherent today and remain adaptable as organisations grow. I work where product strategy, design and engineering meet, helping teams make decisions that scale beyond a first launch.

Since 2020, I have led Product Design at Ublo, where I joined as the company's first designer. Over six years, I helped shape the product from its early direction into an ecosystem of four connected products used by more than 250 organisations and 10,000 users, while building the design function around it.

Currently Head of Product Design at Ublo

Positioning

I began my career as an industrial designer at ENSCI - Les Ateliers, designing services and physical products before working on software. That background taught me to design from materials, use and manufacturing rather than from interfaces alone, and it continues to shape how I approach digital products.

I am most interested in the foundations that make products sustainable: information architecture, design systems, product infrastructure, operational workflows and the collaboration between design and engineering. I would rather build the system that enables a thousand outcomes than produce a thousand individual screens.

The strongest products I have worked on were never designed in isolation. They emerged from continuous conversations with engineers, product managers and the people who rely on the software every day. My role is not only to shape interfaces, but to help teams understand the constraints behind them and make decisions that remain coherent over time.

Alongside product design, I continue to build physical objects, fabrication projects and generative experiments through my independent practice at defd.studio. Making remains an essential part of how I evaluate ideas: a concept only becomes meaningful once it has been confronted with reality.

Artificial intelligence follows the same principle. I see AI as another interface to design, one that should help people extend their capabilities without taking control away from them. Trust, transparency and human judgement matter more than automation itself.

Systems over surfaces.

The responsibilities that recur across my work, whatever the medium: products, systems or the organisations that build them.

  • 01

    Product strategy

    Working where product strategy, design and engineering meet, so decisions scale beyond a 1st launch instead of being solved one screen at a time.

  • 02

    Product infrastructure

    Information architecture, operational workflows and the shared foundations that keep a product coherent as an organisation grows.

  • 03

    Design systems

    Tokens, component behaviour, governance and adoption: the set of decisions that lets a product grow without losing coherence.

  • 04

    Creative leadership

    Building the design function and the operating model that let a team make good decisions without depending on any one person.

Three ways the same practice shows up: a platform, the systems under it, and the leadership around it. Scroll each one to read it.

Case study 01

Ublo.immo

Designing an operational product ecosystem

Founding Product Designer · Head of Product Design · September 2020 to Present

Ublo is a property-management platform built around four connected products: rental management for managers, a tenant extranet, an inspection app for check-in and check-out, and a co-ownership app. They all run on the same underlying data while serving users with different responsibilities and constraints. The work was never to design four independent interfaces, but to make one operational model understandable from four perspectives.

250+
organisations on the platform
+10,000
users across four products
0 → €2M
ARR from new billing features
01 · 01

Defining the product before it existed

I joined Ublo before the product had a validated direction or a production-ready interface. Design started with understanding how property managers actually worked rather than improving existing software.

From my first week, I led continuous discovery through interviews, field observations, market research, workshops, prototypes and usability testing. That work established the initial product direction and influenced several roadmap decisions before the company had a Chief Product Officer or production code.

[À ÉCRIRE] What field research disproved in the founders' original intuition. One concrete example.

Field research confirmed the need for a rental-management product centred on everyday operational work rather than administrative software. The established competitors had dominated the market for decades while leaving many operational frustrations unresolved.

One platform, four perspectives

Although every product relied on the same underlying data, each audience interacted with it differently: property managers needed operational control, residents expected clarity and transparency, and field teams required speed and reliability during inspections.

The work was adapting one operational reality to four distinct contexts without fragmenting the product.

Continuous discovery as product infrastructure

Discovery was never treated as a phase preceding delivery. User research, usability testing, customer conversations, behavioural analytics and cross-product audits became continuous inputs into roadmap decisions throughout the six-year period.

This helped connect customer feedback with operational priorities rather than isolated feature requests.

My take

Case study 02

Design systems

Building design systems as a playground for the team

Ublo · 2022 to Present · defd.studio · Ongoing

A design system is not a component library; it is the set of decisions that lets a product grow without losing coherence. At Ublo the challenge was to support four connected products while making white-labelling scalable for dozens of organisations.

At defd.studio the challenge is the opposite: working alone, with complete freedom to experiment with component architecture, accessibility, internationalisation and implementation directly in code. One system is shaped by operational constraints; the other exists to question them.

Ublo
~90%
components shipped without rework
~5 min
to deploy a new client brand
~3x
faster front-end delivery per cycle
02 · 01

From products to a shared foundation

The four Ublo products had evolved independently. Patterns diverged, components were duplicated, and every new client required dedicated front-end work to reproduce their visual identity.

The challenge was not to redesign the interfaces. It was to establish a shared foundation capable of supporting every product without preventing future evolution.

defd.studio
95
components in the library
WCAG AA
accessibility baseline
i18n + RTL
ready out of the box
02 · 01

A laboratory for new patterns

If the Ublo system answers how a foundation stays coherent under constraints, the studio system asks the opposite: what becomes possible when there are none? It exists to experiment with emerging patterns long before they are safe enough to ship.

The studio system is a React and TypeScript library of 95 components, fully documented, strongly typed, WCAG AA accessible, internationalisation and RTL ready, and it powers this portfolio. It is also where I explore what a component library should become in an AI era, ahead of any production need.

Because I design and build it myself, I can push on component APIs, accessibility, motion and developer experience at the same time, and keep a constant watch on where the craft is heading. Documentation lives at design.defd.dev.

A shared foundation across four products

The Ublo system was designed to solve three problems at once:

  • consistency across four products
  • governed white-labelling for dozens of organisations
  • faster product delivery without creating a central design bottleneck

Its purpose was organisational before it was visual.

Building through code

The studio system is an independent research environment where accessibility, component architecture, documentation and implementation can be explored without production deadlines.

Working directly in React and TypeScript makes it possible to evaluate design decisions at the same level of precision as engineering decisions.

My take

Case study 03

Creative leadership

Building a design function, not only designing products

Head of Product Design · Ublo · 2021 to Present

A product eventually becomes larger than any individual designer. The question stops being “how do we design this feature?” and becomes “how do we help dozens of future decisions stay coherent?”. Creative leadership at Ublo was less about managing designers than about designing an environment where product, engineering and design could work as one system.

0 → 1
design function built from the ground up
6 yrs
leading product design at Ublo
1
apprentice mentored to full autonomy
03 · 01

Building a design function from scratch

There was no existing design team, process or shared practice. Every design decision depended on immediate project needs.

The first challenge was therefore organisational before it became operational: to establish a design function capable of supporting multiple products without introducing unnecessary hierarchy.

End-to-end ownership

The design team stayed intentionally small. Rather than specialising around disciplines or products, designers owned work from discovery through delivery while relying on shared systems to keep the ecosystem coherent.

This encouraged broader product understanding and reduced organisational fragmentation.

Design as organisational infrastructure

Processes, documentation, reviews and DesignOps were treated as product work. They existed to improve the quality and consistency of future decisions rather than to increase managerial control.

As the organisation matured, these shared structures became increasingly responsible for maintaining quality.

Language as design

The interface is not only visual. Vocabulary, labels and interaction copy shape how people understand a system.

By documenting recurring content decisions and embedding them in everyday practice, language became another shared layer of the design system rather than an isolated editorial task.

My take

The case studies explain the work. This section explains the environments in which it was produced.

Experience

Education

Full profile on LinkedIn

Notes on practice. Published only when there is something worth documenting.

Product design is only one part of the practice: objects, materials and the things that shape how I look at product work.