How to Estimate Design Projects Without Getting Burned

Every designer has given an estimate they later regretted. Two weeks turns into six. A "small revision" turns into a full redesign. The project you thought was scoped correctly spirals because the stakeholder had different assumptions than you.

Estimates are always wrong. You still need them. Here's how to make them less wrong.

Why estimates fail

Most estimation failures come from one of three places:

Scope ambiguity. You estimated based on what the client described, but they were describing the happy path. They didn't mention the 12 edge cases, the three approval rounds, or the fact that they'd want to revisit the navigation after seeing the first mockup.

Underestimating complexity. Simple-sounding tasks often aren't. "Design the onboarding flow" sounds like a handful of screens. It's actually: multiple user paths, error states, empty states, a returning user path, accessibility requirements, mobile variants, and developer handoff notes.

No buffer for review cycles. You estimated the design time but forgot to account for three rounds of stakeholder feedback, two rounds of revisions per screen, and the inevitable "can we explore a completely different direction" conversation.

Break work into estimable chunks

You can't estimate "design the dashboard." You can estimate individual pieces of it.

Start by listing every screen, state, and component you expect to design. Go granular:

• Dashboard: default state, empty state, error state, loading state
• Data table: default, sorting active, row hover, empty, error
• Filters panel: collapsed, expanded, active filters applied

Each of those is a design task. Now you can assign time to each one instead of guessing at a total.

This exercise also surfaces scope you weren't aware of. Before you've written a single estimate, you've already found the edge cases.

The 3x rule for complexity

Once you have your task list with rough time estimates, apply the 3x rule: any task that involves significant complexity, ambiguity, or stakeholder decision-making, multiply your estimate by 3.

Complexity multipliers:

• New patterns you've never designed before
• Anything that requires technical investigation (can this actually be built?)
• Features with no clear prior art in the product
• Anything where stakeholder buy-in isn't secured yet

This feels aggressive until you've done it once and seen how accurate it turns out.

The logic: your first estimate is your best-case scenario. The 3x estimate is your realistic scenario. You'll often land somewhere in between.

Building in review rounds

Always specify the number of review rounds in your estimate — and name them.

A typical project structure:

• Round 1 — Initial concept presentation. Feedback collected. Major directional decisions made.
• Round 2 — Refined designs based on Round 1 feedback. Minor adjustments expected.
• Round 3 — Final polish and sign-off. Only critical fixes.

If a client wants a fourth round, that's a scope change — not something you absorb for free. Make this explicit upfront, in writing.

Budget 20-30% of your design time for revisions across these rounds. If you estimate 20 hours of design work, budget another 5-6 hours for revision cycles.

Communicating estimates to clients and stakeholders

Don't present a single number. Present a range.

"This project will take 6-8 weeks" is more honest and more defensible than "this will take 6 weeks." When the project hits 7 weeks, you're still within estimate. When you say 6 weeks and it takes 7, you've missed your number.

Alongside the range, explain what's included: number of screens, number of review rounds, what's in scope and what isn't. A well-scoped estimate document does two things: it protects you if scope creeps, and it aligns the client's expectations before the project starts.

For internal stakeholders, the same logic applies. Be specific about what's in scope. "Login and onboarding flows, desktop only, two rounds of review, no mobile variants" is a scope statement. Without it, someone will assume mobile is included.

Tracking actual vs estimated time

Estimates only get better if you learn from them. Track your actual time against your estimates on every project.

In Notion, a simple project tracker works well: a table with columns for task, estimated hours, actual hours, and notes. Review it at the end of every project to find your systematic biases. Most designers consistently underestimate a particular type of work.

In Linear, you can track issues with estimates and log time against them. If your team is already using Linear for project tracking, it's worth adding design tasks directly to the board so your estimates live in the same system as engineering estimates — that alone helps stakeholders understand where design fits in the timeline.

Try Notion Free

The pattern you're looking for: where do you always run over? Complex components? Stakeholder-heavy features? Mobile variants? Once you know your bias, you can correct for it.

One number people ask for that you shouldn't give

"How long will the whole project take?" — asked before you've done any discovery.

The honest answer is: you don't know yet. What you can give is an estimate for the discovery phase, after which you'll have enough information to estimate the rest. Positioning it this way is both more accurate and more professional. Clients who push for a hard total number before you understand the scope are clients who'll hold you to a number you made up.