Approach

Most B2B products that fail are not poorly designed. They are designed without asking the right question early enough, or without verifying the answer soon enough. The prototype arrives too late, after the specs, after the budget decisions, when it can no longer change anything.

I design data-dense business tools in partnership with a product lead. EdTech, construction, civic tech, media. My method rests on a simple principle: frame the problem, build a testable answer within a week, and decide based on what we observe, not what we assume.

What follows describes this working system. It adapts to each context. The principles stay the same.

How the work is structured

Three stages, adapted to each project. We set the rhythm together from the first week.

Frame

Before the first screen, we align on what we are solving and why it matters.

I work with the PM and the business team to define the problem perimeter, the hypotheses we want to test, and the success criteria. We identify the user profiles involved, their real workflows, their frustrations. We map the risks. This framing produces a shared document that everyone can refer to throughout the project, so the team does not revisit the same questions later.

Output

Scoping document with perimeter, risks, and hypotheses. FigJam board or Notion doc, restitution deck.

Example

France VAE: 10 field interviews with counselors restructured the collective MVP priorities before a single screen was designed.

What guides the decisions

Three principles that orient every project.

At UNOWHY, the Connect dashboard prototype showed that teachers needed specialized applications, not a unified dashboard. We changed direction. That prototype showing the "wrong" direction saved the project six months, because it asked the right question at the right time. At Toolkit, the V2 prototype helped the CEO secure the second funding round. In both cases, the prototype did what a specification document never could: it made the decision tangible.

Working together

I work in partnership with a product lead. Three principles frame this collaboration: every workshop is prepared with a scenario and a defined deliverable, the PM sees progress as it happens, and every tradeoff is documented so we do not revisit the same debates. On the split, product specs are the PM's responsibility. I produce annotated mockups and documented flows that feed them. We align on priorities upstream, and carry them together in front of stakeholders. The PM has continuous visibility on the design work: we do not present design "when it is ready", it is visible from the first explorations.