My working method, from the first question to production

Why I stick to a method

I've worked at agencies, at startups, and inside established product teams. The context changes, and so does the budget, but projects that go wrong almost always share the same flaw: people started designing before they knew what they were trying to solve.

My method comes down to four stages: discovery, scoping, design, development. Nothing original in the words. What matters is what I refuse to skip, and the fact that I stay involved from the first stage to the last.

1. Discovery: understand before you design

Discovery answers one simple question: what is the real problem, and who has it?

I rely on three things.

User interviews. I talk to the people who will use the product before I open Figma. Not to ask them what they want, but to understand how they work today, with which tools, and where they lose time. At Nanotera, this is what showed that the job wasn't to add features, but to bring together tools scattered between headquarters and the stores.

Competitive benchmark. I look at what direct competitors do, and also at products in other industries that solved a similar problem. A benchmark isn't for copying. It tells you what users already know, and therefore what they expect to find.

Client workshops. A workshop brings the people who make decisions to the same table as the people who know the field. That's often where the constraints no brief mentions come out: a technical dependency, a commercial commitment, a team nobody should forget.

By the end of this phase, I need to be able to state the problem in a few sentences everyone agrees with. If I can't, discovery isn't over.

2. Scoping: decide what we'll do, and what we won't

Good discovery always produces more ideas than there is time to build. Scoping is where you choose.

I use two tools, depending on the context.

MoSCoW for conversations with a client or leadership: what's a must, what's important, what would be nice to have, what we won't do this time. The last category is the most useful. Writing down what's out of scope prevents most misunderstandings.

RICE when features need to be ranked against each other: how many people are affected, what impact it has on them, how confident we are in the estimate, how much effort it takes. The final score matters less than the discussion it sparks. When two people disagree on the expected impact of a feature, you've just found a hypothesis to test.

This is where wearing both hats helps the most. A designer alone tends to fight for the best experience. A product manager alone tends to fight for scope. Holding both roles, I make the trade-off while I design, not three weeks later in a committee meeting.

Scoping ends with a written scope, clear priorities, and a clear idea of what will prove the project succeeded.

3. Design: build a system, not a series of screens

I never start with a page. I start with the foundations: colors, text styles, and spacing, set up as variables. Then come the components, and only then the screens, assembled from those components.

This discipline costs something up front and pays off for the rest of the project. When a color changes, it changes everywhere. When a component evolves, every page follows. Above all, what I deliver already looks like the structure the developers are going to write.

During this phase, I get sign-off often and in small pieces. First the flows as wireframes, to talk about logic rather than taste. Then a prototype, to test the key flows before a single line of code is written. A mistake caught in a prototype costs an hour. The same mistake caught after development costs a week.

At Adcleek, this approach is what made campaign ordering accessible to people who aren't digital marketing specialists. The interface was designed to guide and explain at every step, and that choice wouldn't have held up without components that stayed consistent from one screen to the next.

4. Development: stay until the end

Many designers consider their work done once the mockups are handed off. For me, that's where the most decisive part begins.

I work with developers, not ahead of them. At Adcleek, I took part in planning poker sessions and technical discussions. Understanding why a feature is expensive to build often leads to a variant that's almost as good for the user and half as hard to build.

I document what I deliver. A component without usage rules will be misused. I describe its states and edge cases, and what happens when a text is too long or a piece of data is missing.

I do the design QA. I compare what was built with what was designed, screen by screen, and fix the gaps with the team. At Nanotera, this follow-through all the way to production was fully part of my role.

On Xola, I worked with a CTO based in the United States and development teams in India. At that distance, closeness doesn't come from being in the same room. It comes from the clarity of what you hand over and the regularity of your exchanges.

What wearing both hats really changes

Holding both roles doesn't mean doing two jobs halfway. It means every design decision is made knowing its cost, its priority, and its expected effect on the product.

In practice, that gives three things:

• designs that reflect the actual scope, so fewer features get designed and then dropped;
• faster trade-offs, because the person designing is also the one who knows what matters most;
• continuity between the original intent and the shipped product, because the same person follows both.

How I adapt the method to the context

The four stages stay the same everywhere. What changes is how much weight each one gets.

At a startup, time is short and so is certainty. Discovery is brief and targeted: a few well-chosen interviews beat a full study that arrives too late. Scoping is ruthless, because every extra feature delays the moment the product meets its users. Inspy, which I designed as a school project before it became an entrepreneurial one, taught me this: a clear vision and a tight scope are more convincing than a list of features.

At an agency, the client isn't always the user. Workshops take center stage, because you have to align people with different expectations before producing anything. Documentation counts double: the team that will maintain the product is often not the one that designed it.

In an established product team, the product already exists and it has users. Discovery draws on usage data as much as on interviews. Design has to work with what's already there, and development becomes an ongoing dialogue rather than a handoff. On Xola, which already had a large user base, the goal was to modernize the flows without breaking people's habits: a constraint you can only meet with a deep knowledge of the existing product.

In all three cases, the order stays the same. Understand, choose, design, follow through. Swapping two stages always costs more than shortening one.

What this method prevents

I often describe it by what it produces. It's just as valuable for the problems it prevents.

• The feature nobody uses. It almost always comes from an idea that was never tested with a user. That's what discovery is for.
• The project that never ends. It comes from a scope that stayed vague. Written scoping, with a list of what we won't do, gives you a stopping point.
• The gap between the design and the product. It appears when the designer disappears after handoff. Design QA closes it.
• The product that degrades with every update. It's missing a system. Variables and components protect it.

None of these are talent problems. They're problems of sequence and follow-through.

The three rules I don't negotiate

1. No mockups before the problem is stated. If nobody can say in two sentences what we're trying to solve, we're not ready to design.
2. No handoff without components and variables. A design that can't be maintained isn't finished.
3. No project dropped once the mockups are delivered. Results are judged in production, not in Figma.

In short

• Discovery: What is the real problem, and who has it? — Interviews, benchmark, workshops, a clearly stated problem
• Scoping: What will we do, and what won't we do? — Scope, priorities (MoSCoW, RICE), success criteria
• Design: How do we solve it consistently? — Variables, components, flows, tested prototype
• Development: Does what shipped match what was planned? — Documentation, work with developers, design QA

Listen, understand, decide, deliver: that's the short version. The four stages are the version you can actually practice.