How long does design take?

I've been thinking about this question lately. As a designer, you get asked for estimates or timescales a lot right? "when can I have this by?", "when will it be ready?" etc but how do you know?

We've probably all heard the phrase, "it's done when it's done" or thought the longer I spend on it, the better it will be. But can we really say why?

Whilst there isn't a specific formula, there are better ways to think about the problem and this article will help you find your own solution and become comfortable with why some things seem to take unmeasurably longer than others.

What's the problem?

It's common for people to think that design is the act of creating the design assets. However, if you asked "How long did this book take to write?" and the answer was how long it took to type onto page, it wouldn't represent the time taken to write the book.

But why is this the wrong answer? surely it's factually correct?

It's common for people to think the act of creating the output is the measure of the task, but that ignores everything that proceeds the output. Whilst an experienced designer might draw recangles more quickly, or author might write words more prolifically based on their experience. Measuring output is the wrong way to think.

You could go as far to say we're answering the wrong question, or the question fails to differentiate between the mechanical act of creating assets themselves and the process of writing or designing. This article is a good example, it's probably going to take an hour to write, but there's no way I could write it in an hour without years of experience and additional thought to come to the conclusions I have within an hour.

How many questions do you have?

The key aspect of design work, or any work really is that the speed you can execute depends on how quickly you have the answers to the questions you encounter.

Let's think of this simply, how quickly can you do the washing up? is it quicker if you know where the bowl, cloths and washing up liquid are kept? The locations of key tools need to be found, but if you know the answer, you perform the task quicker.

Why is this so relevant to design? my view is that design typically is the first time we REALLY start to ask questions. Everything from the lower level, what colour should this be? to the higher order, how should this work?

The more answers you have, the less time you spend asking questions. Or put the other way, the fewer questions you need to ask, the quicker you can complete a task.

This is why established products and products areas which are well understood are quickly to design and develop. You have all the answers already, you're just executing a known plan.

Experience

Often people look at experienced team members and think they are magical, they do things so quickly, they never get it wrong!

Is this really the case? well....yes and no.

Experience means you've seen this before,

Practical contact with and observation of facts or events.

and what does that equate to? it means you've already asked the questons (hopefully) and (hopefully) got an answer. It may not be the best answer, or the current answer, but you have an answer, and that experience biases your approach both positively and negatively.

On one hand, a common/simple problem may have a common or simple solution which you can draw on like muscle memory, making task execution quicker. This can be anything from a design approach, to a narrative example to a heuristic justification, ultimately you have a frame of reference.

On the other hand, past experience can close our eyes to new solutions, so we need to remain open minded and explore new solutions when constraints change, anything from technology, domain and our own ability so we're not too anchored to the past.

How do I get experienced?

The obvious answer is "practice" and whilst this is correct, there is a key difference in the rate people accumulate experience.

The first thing in my mind is curiosity, the specific act of being motivated and driven to ask questions gets answers far quicker than anything else. ALWAYS dig deeper, always want to know why, why? because it gets you another answer, it helps you answer that question yourself when the time comes.

The second is support, you can't do everything yourself and you'll never have all the answers. Building the network of people around you and your role you can ask questions of, will, surprise surprise, get you more answers faster which will in turn, enable you to build your own views and answers to the questions you encounter.

The two points are so key in any role, design, development, management etc but especially true in design, because my personal belief is that the design discipline SHOULD have the most questions to ask as it typically explores new areas first, and as a result, should be the most pro-active in seeking answers.

If you as designer if don't have the answers based on your experience, you need to work hard to get them. Design crosses boundaries, internal/external, technological/regulatory, management/product/design/developent/qa and that's part of what makes it hard, you need to find the people to ask, know what to ask and ingest and process answers from such a wide range of stakeholders and sources that you can sythesise all of that into a single coherant solution and on top of that know how best to communicate all of that back our to the same range of audiences in the compelling way.

Patterns and systems

Design questions and answers can be a simple as is X or Y variant better. A junior approach to this may be to create a full design concept and then ask key stakeholders which is best. We may have our own thoughts and opinions, but ultimately we're looking for someone without our specific skillset to validate our work. Stakeholder feedback is import but in the right area.

What if we got more specific about the feedback we're looking for? what if we use know "good answers" to low level questions like what typeface to use, or what colour a button should be or how a dialogue should display because we already have established pattern and systems to provide those answers?

Patterns and systems enable us to compose 1-N solutions at speed, allowing us to rely on past answers to build new solutions.

We may stil need validation for approach, but the context for stakeholders is not about the detail, that's in the bag, which leaves us the airspace to ASK QUESTIONS about the bigger problems, how well does this fit our clients use case? do we have a way to monitor user behaviour in this process? who do I speak to about feeding our success metrics into the annual report?

What about unanswered questions?

There are always times when experience, support, patterns and systems can't answer our questions, this can cause us to slow down, which many people see as bad, but really the speed reduction here is a good thing. We have identified unanswered questions, do we guess and go from past experience? or do we explore and ask more questions?

It can be tempting to work from huerestics and past experience, but are we truly getting the answers to our new questions? or fitting an answer in because we don't know any better?

Pragmatism is a reality, but talented designers see when unanswered questions are causing too many guesses and need more exploration. This doesn't always mean some lengthy research phase, it may just be re-assing an existing component based on a new need.

Being able to optimise the rest of our processes, low level design decisions and established patterns allows us to deliver value asking the bigger questions no one else can, and again sythethise the answers back into our solutions. Of course, much of this is invisible to the end user and at times stakeholders, so we often remain the unsung heroes!

Summary

Design is about getting the answers to questions as effectively as possible, through our own experience or the experience of others. Effective designers have a huge range of stock answers to fall back on which make us faster at what we do.

We're also insightful enough to recognise that tools like design systems allow us to scale those answers out to our teams to provide answers consistently and at scale.

What we need to do to help answer the question "how long will it take?", is be able to recognise at a glance, what likely unanswered questions may exist and guess how long they will take to answer. This is why we ask a lot of questions! we're reducing risk, by finding answers quickly and in turn, better able to output faster.

If we want to be effective estimators, we should give ourselves a bit of a question/answer/exploration budget in each task, and stick to that, falling back to huerestics if needed.

If we want to add most value, we need to factor in time to research, explore and document our findings so we can share the answers with others.