Stop estimating design work

This was originaly posted here

Human beings are terrible at guessing. Our ability to estimate is awful because we’re biased creatures. Our inclinations and opinions are vital to our survival. But these make us bad at estimating things.

In my role as a design leader, estimations are always part of the job. I spend a lot of time looking at budgets and timelines. Working out how long a design project would take is part of my job. I sit in meetings and pull numbers out of thin air and we add them to a chart. It’s a hidden secret that forecasts aren’t worth the paper they’re written on. Yet we treat them as if Moses brought them down from the mountain himself. Why?

Forecasting is a foundational part of traditional business. In the product world, we forecast by estimating the time it takes for us to complete our work. Engineering has used this technique for years in Agile teams. Design has adopted their habits without thought.

Design work and Engineering work are different. Engineering has to meet a certain standard. Tests need to be ran, completed and passed. Nothing like this exists for design work. User Stories are functional, solution-focused pieces of work. Design tasks are usually more open and problem-focused.

Design by its very nature is exploratory. Your job is to figure out how to fix the problem set out before you. You’re experimenting, prototyping, testing. How can you estimate that? You can’t. You can’t say that Feature X will take 2 weeks to design because nobody knows what Feature X is going to be yet.

However, how can you plan anything without some kinda of idea of how long this project will take? But we need to think about it in a different way. It’s not the idea of time constraints that are the problem, it’s how we’re using them. There has to be another way.

In my team, we started to experiment with a different approach. Instead of looking at design tasks and estimating the time we would take to complete them — we decided to flip it around. Instead we ask ‘Where is the best use of our time?’. We define how much time we want to spend on the problem, driven by our appetite to solve it. We set a deadline and carve up the work based on it’s importance or complexity. This has not only been super effective for our teams productivity but also on our approach to design.

We assign each design task a Large, Medium or Small. This is a relative unit of time, dependent on how long the timeline stretches. The idea here is that feature could be designed in 2 days, it could be designed in 2 weeks. It leaves the decision of ‘how good can we make this?’ to the forces of the company. Do we have the time to do this amazing first time round or can we just do the bare minimum and come back around later? This pragmatism has stopped countless back-and-forth discussions between design and product teams.

Designers can fall into a trap of thinking design has to meet a standard. We look at classical design like Eames chairs or the iPod and think we need reach the same level of craft. But designing for software needs to be iterative. You don’t get one go round. Making trade-offs and prioritising where to focus your effort is good design. I would argue, in software, it’s more important than creating a “perfect” UX — whatever that is anyway.