Jelena Racković · · 3 min read · Teams & delivery
Estimating design work so people can plan around it
Sooner or later, every designer is asked the same question: how long will it take? Project managers need a number, clients need a budget and developers need to know when the screens will arrive. The question is fair. The difficulty is that design work does not divide into hours and days as neatly as everyone would like, and pretending that it does is how projects get into trouble.
Design is not engineering
Engineering work, for all its complexity, can often be broken into tasks with reasonably predictable effort. Design is different. Part of it is execution, which can be estimated, but a large part is thinking: understanding the problem, exploring directions, discarding most of them and recognising the right one when it appears. That part does not follow a stopwatch. A solution can arrive in an hour or take a week, and the difference rarely depends on effort alone.
So when I estimate design, I am honest about that uncertainty rather than hiding it inside a confident number. The aim is not a precise figure. It is an estimate people can plan around, with the risks clearly visible.
Thinking in three dimensions
What makes design plannable is a good map of the work, and I think about that map almost like a cube. One side is breadth: the screens, flows and modules the product needs. Another is depth: for each of them, the states, the edge cases, the responsive versions, the empty screens and the error messages nobody remembers until they are missing. The third is time: the phases, from discovery through concepts and detailed design to handoff and support during development.
Looking at the work in all three dimensions changes the estimate completely. A list of twenty screens sounds manageable. Twenty screens, each with five states, two breakpoints and a design system that has to support them, across four phases, is a different conversation, and a far more honest one. Once the cube is mapped, each part can be sized, sequenced and assigned, and the overall number stops being a guess.
Out of scope comes first
The most important part of any estimate I write is not what is included. It is what is not. I state it first, clearly and in plain words, because the boundaries of design scope are remarkably easy to cross. A small extra screen here, an illustration there, a quick logo refresh, a few banners for the launch, a presentation for the board: each request sounds minor, and together they can double the work without anyone noticing until the deadline slips.
Putting out of scope at the top is not about being difficult. It protects everyone. The client knows exactly what they are paying for, the team knows exactly what they have promised, and when a new request arrives, there is a calm, shared reference to decide whether it fits, waits or becomes a new piece of work.
Plannable, not precise
An estimate built this way will never be exact to the hour, and it shouldn’t pretend to be. What it offers is better: a clear map of the work, honest ranges where uncertainty is real and firm boundaries around the scope. Project managers can plan with it, developers can schedule around it and clients can budget for it. And when something changes, as something always does, everyone can see what moved and why.
That, in the end, is what people really need when they ask how long design will take. Not a promise, but a plan they can trust.
Is your design system starting to fade?
I’d like to hear about it →