How long product design actually takes

After "what will it cost", the next question is always "how long". Both get vague answers, and the vagueness is usually hiding the same thing: the designer does not yet know what the work is.

Here is what the time is actually made of.

The rough shapes

• An audit of an existing product: two to five days. You get a ranked list of what is wrong.
• One feature in a product that already exists: one to three weeks, depending on how much of it is genuinely new and how many places it touches.
• A product from nothing to something buildable: two to four months, including research, the structure, the interface, and the states nobody remembers until launch week.
• A full brand and product together: longer, and it is really two projects sharing a calendar.

Those assume one designer and a client who answers. Neither is guaranteed.

What actually makes it slip

Almost never the drawing.

Deciding who it is for. If that is still being argued internally, the argument is the first phase of the project whether or not anyone planned for it. This is the single most common reason a six-week job takes twelve.

Waiting for a decision. A question that takes you four days to answer adds four days, and most projects contain a lot of questions. This is the cost people never see on a timeline and always feel at the end.

Scope that grows sideways. Not "we added a feature", which is visible. The quiet one is "and it should also work for admins", which doubles the states without adding a line to the brief.

Finding out late. A flow that fails on a real device, a form that cannot survive being interrupted, a model that cannot represent what the business actually does. These are cheap to fix in week two and brutal in week ten.

The change that removed weeks from my projects

I stopped handing over static screens.

The work engineers build from is now a working prototype, built with AI coding tools, that behaves the way the real thing should. Not a picture of the product, the product's behaviour.

Two things collapse when you do this. Review stops being a meeting where everyone imagines the same screen differently and starts being ten minutes with a link. And the questions that normally surface in QA, weeks later and expensively, surface in week one while the answer is still cheap to change.

On one project I wrote 76 engineering tickets against a running prototype, with the rule that if a ticket and the prototype disagreed, the prototype won. There was nothing to reconcile afterwards because there was only ever one source. That is written up here, and why I stopped sending Figma files is the longer version.

What did not get faster: the research, the flows, and the argument for why the design is right. Those take exactly as long as they always did, and anyone telling you AI removed them is selling something.

How to keep your own project on time

Name one decision-maker. Not a committee. One person who can say yes, with the others consulted rather than blocking.

Answer within a day. You will get more of a designer's time than any contract can buy you, simply because they are never parked waiting on you.

Ask to see something in week one. Rough is fine. The point is to find out early whether you and the designer are picturing the same product, because that is the mismatch that costs months.

Write down what is out of scope. If nobody has, nothing is, and scope will grow into the gap.

The timeline question worth asking instead

"How long will this take" has one honest answer at the start of a project: it depends on things neither of us knows yet.

A better question is "what would make this take twice as long?" Anyone who has run real projects will answer it immediately and specifically. Anyone who has not will tell you it will be fine.

If you have something with a date attached, send me the problem and the deadline and I will tell you honestly whether they fit, including when they do not.