“It Will Take as Long as It Takes.”
That was my answer when someone asked me how long a design project would take. I would get irritated. I thought the question was unfair because I genuinely didn't know. How could I commit to a timeline when I didn't even know what the solution was going to be?
It is embarrassing to admit now, but I said it to colleagues more than once.
Looking back, their question was completely reasonable. They weren't asking me to predict the final design. They needed to understand how long the work might take so that they could plan the project.
I simply didn't have a good way of answering them.
I Didn't Have Rails
The problem was that I didn't have a process.
I had design skills. I had experience. I had intuition. I could look at something and often tell whether it felt right or wrong. I could eventually get to a solution that worked.
But I couldn't always tell you how I had got there.
It was a little like shooting in the dark until I hit something.
I instinctively knew that some things were the right things to do. What I couldn't always explain was what happened between understanding the problem and arriving at the solution.
Before I had a process, I could often recognise a good answer. I just couldn't explain how I got there.
And that became a problem when someone asked me how long it would take.
If I didn't know what I was going to do next, how could I estimate how long it would take? Every project could become a new adventure in figuring out not just what to design, but how to get myself to the point where I could design it.
I Didn't Trust Process Either
There is another reason I think designers can be suspicious of process.
I came from a time when design education was much more focused on craft. We learned how to design. We learned the tools. We learned about visual decisions and execution. But design process wasn't something that was explicitly taught to us in the way I understand it today.
When I started working in the IT industry, I encountered process there.
But it wasn't my process.
It was something imposed on me.
And that created a fairly natural association in my mind: process meant bureaucracy, restrictions and somebody else telling me how I was supposed to work.
So when you tell a designer like that that they need a process, you shouldn't be surprised if they resist.
I did.
What I hadn't understood was that there was a difference between being given a process and understanding your own process.
The Black Box
The change for me happened at R K Swamy.
I was estimating multiple projects and I had a very practical thought: let's make a list of all the things I need to do so I can estimate the work better.
So I started listing things.
Understanding the requirements was one thing. Creating the actual visual design was another. There were other activities in between.
But there was a problem.
There was a large part of the work sitting between those visible activities that I hadn't really examined. It was essentially a black box. I knew that something happened in there because, somehow, a solution eventually came out of it.
I decided to open that black box.
Not for the client.
Not for the client relationship team.
Not because somebody had asked me to document a methodology.
I did it for myself.
I wanted to understand what I actually did when I was “getting the solution.”
What Happens Inside the Black Box?
Once I started breaking that part of the work down, something interesting happened.
I could see what I was actually doing.
I could see the questions I was asking. I could see the things I was looking for. I could see the decisions and explorations that were happening before I arrived at something I considered a solution.
And because I could see those things, I could also get a better sense of how long they took.
That was useful for estimating.
But estimation turned out not to be the most important benefit.
I had started by trying to answer a business question: How long will this take?
I ended up answering a much more personal question: What do I actually do to get to a design solution?
I wasn't inventing a process. I was discovering the process that was already inside the way I worked.
And once I could see it, I could start thinking about it.
That is the thing about naming something. Before you name it, it can remain invisible. Once you name it, you can examine it, question it and improve it.
Design and Technology Are Different Animals
There was another realisation that came from this.
In project discussions, I would sometimes sit with people from the technical team. They could sound very certain about their work.
“We can use this technology.”
“We can use this tech stack.”
“This will take this much time.”
I wasn't always able to respond with the same kind of certainty.
That used to make me uncomfortable.
But when I dissected my own process, I started to understand why.
Design and technology are different animals.
No matter how much I broke my design work down, there would always be things I could not know at the beginning. Some of the answers simply didn't exist yet. They had to be discovered through the work.
I wasn't failing to predict something that should have been predictable.
Some things in design are genuinely uncertain.
That distinction made me much more comfortable with uncertainty.
The Unknown Didn't Need to Become Known
This is where the process became particularly useful.
The people in the room, including the client, weren't necessarily interested in knowing all the unknowns. They were interested in knowing how long those unknowns would take.
That was a much more reasonable question than I had previously understood.
I couldn't necessarily tell them exactly what the final solution would be.
But I could understand what I needed to do to get there.
And once I understood the process, I could make a reasonable estimate of the effort involved.
That was good enough.
The technical person could give confidence about the implementation because they understood their process and their constraints.
I could give confidence about the design work because I had started to understand mine.
Neither of us needed to pretend that we knew everything.
The process didn't make the unknown known. It made the unknown estimable.
Confidence Without Certainty
There was another, less obvious benefit.
Once I understood my process, I became more confident in conversations about design.
Not because I suddenly knew all the answers.
In fact, I became more comfortable saying that I didn't know something.
The difference was that I now knew what I didn't know and why I didn't know it.
And I knew what I was going to do next.
Someone else in the room might still disagree with me. They might not be convinced that something couldn't yet be known. They might want a different answer.
But that disagreement didn't automatically make me doubt myself anymore.
I had a basis for my position.
That was a very different kind of confidence from being certain about everything.
It was confidence in the process rather than certainty about the outcome.
Process Didn't Take Away My Creativity
I think this is where many designers get process wrong.
We imagine process as a railway track.
You get on at one end and you have to follow the same route until you arrive at the other end.
Of course that feels restrictive.
But that isn't the kind of process I'm talking about.
A personal design process is more like rails than a railway timetable. It gives you somewhere to go when you don't know what to do next. It gives you a way of moving through the work without having to reinvent your entire approach every time.
You can still explore.
You can still change direction.
You can still follow an unexpected idea.
You can still throw something away and start again.
The process doesn't tell you what the answer has to be.
It helps you understand how you are going to look for it.
In fact, I think that can make you faster.
If you already understand how you work, you don't have to spend as much mental energy figuring out how to work. More of that energy can go into solving the actual problem.
A virtue is its own reward: a process is not
But there is another trap with process.
Following a process for the sake of following the process can be more counterproductive than having no process at all.
We were going for a certification and that required us to demonstrate that certain things had happened in a particular order, with specific artefacts produced at each stage.
We had already built the application, so we worked backwards.
We created the storyboards after the application had been created because that was what the process required us to show. We were following the process, but the process wasn't helping us create the product. We were creating evidence that we had followed the process.
That experience stayed with me. A process is a means to an outcome. It isn't the outcome itself.
If a step helps us think better, make better decisions, or arrive at a better solution, it has value. If we're doing it simply because the process says we should, we should stop and ask why.
The value of a process is not in following it. The value is in what it helps us achieve.
Don't Adopt Someone Else's Process
After I had articulated my own process, I remember thinking, “Why is everyone not doing it?”
It makes me smile now because the answer is fairly obvious.
Many designers have experienced process as something imposed on them.
They have been given methodologies. They have been asked to follow stages. They have seen process become documentation, approvals and bureaucracy.
So they resist.
But perhaps the answer isn't to persuade designers to adopt a better process.
Perhaps the answer is to ask them to look at the process they already have.
What do you do when you receive a new problem?
What questions do you ask?
Where do you look for information?
How do you explore possibilities?
What makes you reject an idea?
What makes you move forward?
Where do you usually get stuck?
What happens inside your own black boxes?
And how long do those things usually take?
You might discover that you already have a process.
You just never named it.
Process Is Not About Knowing Everything
That is probably the biggest thing I got wrong earlier in my career.
I thought being good at design meant being able to come up with the answer.
Then I thought being professional meant being able to tell people how long it would take to come up with the answer.
Neither is quite right.
Being experienced at design also means understanding the journey between the problem and the solution.
It means knowing which parts of that journey are reasonably predictable and which aren't.
It means being able to explain uncertainty without being paralysed by it.
And it means having enough understanding of your own work to tell someone, honestly, what it will take to find out.
That is what process eventually gave me.
Not certainty.
Something more useful.
A way to work with uncertainty.
You already have a process, you just don't know it
If you resist the idea of process, I'm not going to tell you to stop being creative and start following a methodology.
Don't believe me,try this-
Look at the last few projects you've worked on.
Look at what you actually did.
You may find patterns.
You may find that you ask the same kinds of questions. You may find that you explore in a particular way. You may find that there are certain activities you repeat on almost every project.
Name them. That is your process
Now ask yourself whether that process is working.
Where does it help?
Where does it slow you down?
Where are the black boxes?
What could you make more deliberate?
What could you get better at estimating?
That is where process becomes useful, not when somebody hands it to you but When you own it.
Process doesn't replace intuition. It gives intuition rails.
And maybe that is the reason not to resist it.
You don't have to become more certain about design.
You just need to become more comfortable with uncertainty because you understand what you are doing inside it.
So if someone asks me today how long something will take, I don't have to say, “It will take as long as it takes.”
I can say something much more useful:
“I don't know exactly what the answer will be yet. But I know what we need to do to find it, and I have enough experience with that process to give you a reasonable estimate.”
That is what a process gave me.
It didn't tell me the answer.
It taught me how to get there.
