Estimating Design Work: Appetite, T-Shirt Sizes, and Fixed Time

How to estimate design work without faking precision: appetite versus estimate, T-shirt sizes for UX, and why design effort does not match development effort.

info Quick Definition
Estimating design work means calculating how much effort a user experience problem needs, knowing the estimate will never be exact. The most useful practices separate the time a problem deserves from a prediction of how long it will take, and then compare the planned effort with the real one.

Why is it hard to estimate design?

Because design work is exploratory. Nobody knows in advance how many versions will be needed until problems appear. In addition, design effort and development effort do not follow the same curve. A visual change can be quick to draw, while the data or integration work that supports it can take weeks.

NN/g sums this up in its article on UX capacity: UX effort can be significantly disconnected from development effort. That is why estimating design with the same logic as code often gives numbers that are useless for planning.

Why does this matter for a junior designer?

Because sooner or later someone will ask, “how long will it take you?” If you answer with a precise figure without a basis, that figure becomes a commitment. If you answer “I don’t know”, the team loses the chance to plan. There is a middle ground, and it is worth learning early.

Estimation is also a conversation about scope. When a task runs long, the useful question is not “why did it take longer?” but “which part of the scope can we cut?”

What is appetite, and how is it different from an estimate?

Shape Up, Basecamp’s method, separates two ideas. An estimate predicts how long something will take. Appetite says how much time a problem deserves. For Basecamp, appetite is completely different from an estimate: an estimate starts with a design and ends with a number, while an appetite starts with a number and ends with a design.

The practical consequence is that time is fixed and scope varies. Shape Up calls this “fixed time, variable scope” and treats it as key to defining and shipping projects successfully. Instead of asking how much it will cost to build everything, the team asks which version fits in the time the problem deserves.

For a designer, this changes the work. It is no longer about drawing everything that was requested, but about finding the version of the design that solves the problem within the agreed time.

How do you estimate in practice?

  1. Start with sizes, not hours. In its survey, NN/g found that many UX professionals prefer to estimate their effort separately from the development team, and that T-shirt sizes (S, M, L, XL) are a common way to do it without affecting the team’s velocity.
  2. Estimate the data and integration work too. A design that depends on new data or an API has effort that does not appear in the mockup. Ask what supports the screen before you estimate it.
  3. Use a consistent scale. NN/g notes that it does not matter which scale you use, as long as you keep it. Switching scales midway prevents comparison.
  4. Expect several attempts. According to NN/g, UX teams usually need several rounds before their estimates become precise.
  5. Review the past. Compare each estimate with the real effort and look for patterns of error. If you always underestimate user testing, that is already useful information.

Team ceremonies, such as planning or sprint review, are the natural place to make this comparison. The article on team ceremonies describes how they are structured.

How do you estimate without breaking the team?

NN/g warns of a risk: separate UX points can hurt team cohesion, and UX can end up seen as a separate unit of work. Its recommendation is to fold UX estimation into the main team’s estimation process over time.

In practice, that means the designer joins the same conversation as the developers, even if the scale is different. A design estimate that nobody discusses with engineering is not useful for planning.

When should you NOT estimate?

  • When the problem is not yet defined. Estimating something you do not understand only produces arbitrary figures.
  • When the work is safety-critical or subject to legal deadlines. In those cases scope is usually fixed along with time. That is not the fixed-time scenario of Shape Up.
  • When the team turns the estimate into a performance measure. That discourages honest estimation. For that topic, the article on career plans and performance evaluation is more useful.

Example

Illustrative example: a team gets a request to redesign the reporting dashboard.

  • First estimate: the designer says “M”, because there are four new screens.
  • Development question: the dashboard needs data from a service that does not exist yet. The data effort is “L”.
  • Decision: the team sets an appetite of three weeks. That time covers redesigning two screens and integrating the basic data. The other two screens move to the next cycle.
  • Review: at the end, the team compares. The design took as planned, but the integration took twice as long. Next time, that integration is estimated earlier.

What the team learns is not how to predict better, but how to cut scope in time.

For the financial side of these decisions, the article on budget management helps connect effort with cost.

Common mistakes

  • Estimating design without including the data or development work that depends on it.
  • Using the development team’s point scale for UX when it does not fit.
  • Asking for precision from the first attempt.
  • Estimating separately so strictly that the UX team becomes isolated.
  • Confusing appetite with a delivery promise.
  • Never comparing the estimate with the real effort.

Sources

Frequently asked questions

How do you estimate design work?
A common approach is to use T-shirt sizes (S, M, L, XL) instead of hours, then review the real effort afterward. Nielsen Norman Group notes that many UX professionals prefer to estimate their effort separately from the development team.
What is appetite in Shape Up?
It is how much time a problem deserves, not a prediction of how long it will take. Basecamp presents it as different from an estimate: time is fixed and scope adjusts.
Why is it hard to estimate design work?
Because design effort can be very disconnected from development effort. A visual change can be quick while the data or integration behind it takes much longer. According to NN/g, several attempts are needed before estimates become precise.
Should design use the same scale as development?
Not necessarily. NN/g says it does not matter which scale you use, as long as you stay consistent over time. What matters is comparing estimates with the real effort.
What share of the budget should go to usability?
In 2003, Nielsen Norman Group cited about 10% of a project’s budget. It is an old data point and only context, not a rule; use it as an order of magnitude when you argue for your proposal.