When experience makes us faster, how do we slow down without losing momentum?

There is an interesting change that happens as we become more experienced at what we do.

Problems that once required us to stop, explore and think through several possibilities start to feel familiar. We recognise their shape sooner, remember something similar we've encountered before and begin forming an idea of what might work almost instinctively.

That's one of the advantages of experience. We gradually build a catalogue of things we've seen work, things we've seen fail and situations that looked very different on the surface but turned out to have surprisingly similar problems underneath. Over time, that catalogue makes us faster, and most of the time that's exactly what we want. We shouldn't need to rediscover everything from first principles every time we encounter something familiar, but I've been thinking about the other side of that speed.

The faster we become at recognising patterns, the easier it is to move from I've seen something like this before to I know what this needs without noticing the distance between the two. Sometimes that distance is tiny. Sometimes it contains most of the problem.

Experience can make us faster at finding good solutions. It can even make us faster at identifying the problem. But it can also make us faster at becoming confident that we have the right solution before we've confirmed that we have the right problem to solve.

A problem well-put is half-solved.

There's a reason that idea has survived for so long. How we define the problem changes what we're capable of seeing as a solution.

We see the problem and immediately want to fix it

I was discussing a legacy modernisation project recently with another designer and our Design Manager. The primary objective of the work is relatively straightforward: take an existing legacy product and bring it visually into the new design system. It isn't supposed to be a complete redesign of the experience.

But when you ask any designers to spend a lot of time looking closely at an old product, especially good designers, something fairly predictable happens. We find bad UX, and naturally we want to fix it.

I understand that instinct because I have exactly the same one and have been through a similar experience before with another project. It's difficult to look at an awkward interaction, an unnecessarily complicated flow or something that clearly feels like it could work better and simply move on because that isn't what you're there to solve.

You start thinking about what would work better, and sometimes the answer seems obvious almost immediately, particularly when you've encountered similar ones before. I don't think there's anything wrong with that. In fact, I'd be more worried if experience somehow trained us to stop noticing those things altogether, but recognising something as a problem and understanding the problem aren't necessarily the same thing.

John Dewey described reflective thought as moving through a felt difficulty, defining it, suggesting a possible solution, reasoning through that suggestion and finally testing it through further observation. More than a century later, that sequence still feels remarkably relevant to design work.

Experience can compress those stages, which is useful. The danger is compressing them so much that they effectively become one. We see something wrong, recognise a familiar pattern and almost immediately arrive at the thing we think should replace it.

Not every UX problem needs weeks of discovery.

That doesn't mean every UX improvement needs weeks of research, workshops and exploration before anyone is allowed to make a decision.

Discovery should be proportional to the problem. Some problems really are small, familiar and well understood. There may already be strong evidence, an established pattern or enough surrounding context to make a reasonably confident decision quickly. Spending two weeks investigating something we already understand well enough isn't necessarily better design.

Experience should allow us to move faster when the evidence allows us to move faster. Other problems only look small until you start exploring them.

You notice an interaction that doesn't quite work and begin looking at alternatives, but then realise another workflow depends on it. That introduces another user type you hadn't considered, which exposes a permission you weren't aware of, and suddenly there are several states and edge cases that weren't visible when the problem first caught your attention.

Something that looked like a two-day improvement has become a much larger product question. That isn't failed discovery. Quite the opposite. The exploration has done exactly what it was supposed to do: it has shown you that the problem is larger than you initially thought.

Where things become difficult is accepting that discovering that complexity doesn't mean you now have to finish solving it.

Sometimes the right design decision is to stop

This is where scope discipline gets uncomfortable, particularly as a designer.

You've already spent time on the problem. You understand it better than you did yesterday, you're beginning to see possible solutions and, perhaps most dangerously, the work is becoming interesting and at this point, stopping can feel like throwing away momentum.

There's also a very human tendency to want something tangible at the end of an investigation. We found a problem, spent time understanding it, so surely the useful outcome is a solution.

I'm not convinced that's always true. Sometimes the most responsible conclusion you can reach is simply that this problem needs more exploration than the current initiative can reasonably give it.

That doesn't mean forgetting what you've learned. Document the problem as you currently understand it, capture what you've discovered, record what you know and what you still don't know, and preserve any useful hypotheses that might help when someone returns to it, then move on.

Not because the problem isn't important, but because it might be important enough that squeezing the rest of the investigation into whatever time happens to be available isn't actually giving it the attention it deserves.

A visual modernisation can quietly become a redesign

This becomes particularly visible in modernisation work. Imagine the company has approved a visual modernisation. The objective is to move an existing product onto a new visual language and design system, while largely preserving how the existing experience works.

As the team works through the product, every section creates opportunities. We're already changing this screen, so perhaps we should improve this interaction too. If we're changing that interaction, maybe the workflow around it could be simplified. Once we do that, another state needs to change, and that affects a pattern somewhere else.

None of those decisions has to be unreasonable. In isolation, each one might genuinely make the product better, but collectively they can change the nature of the programme without anyone ever explicitly deciding to do so.

What began as a visual modernisation gradually becomes a visual modernisation combined with continuous UX redesign, except the second part hasn't necessarily been given its own time, resources or expectations.

The modernisation then takes considerably longer because Design is doing more than the apparent scope suggests, while the UX work itself is still being fitted into a delivery schedule designed around something much more contained. That's an awkward trade-off because you can end up slowing down the visual modernisation without necessarily giving the deeper UX problems enough time to be explored properly either.

There is another risk here too. The more experienced we become, the larger our collection of solutions becomes, and that can subtly influence which problems we think we're seeing. Abraham Kaplan described a version of this in The Conduct of Inquiry when writing about what he called the “law of the instrument”:

Give a small boy a hammer, and he will find that everything he encounters needs pounding.

Kaplan was talking about research methods rather than product design, but the warning translates surprisingly well. Experience gives us a much larger toolbox. That's useful, but it also means we have many more familiar solutions available to influence how we frame the thing in front of us.

Sometimes the pattern really does fit. Sometimes it just looks familiar enough that we stop looking.

That doesn't mean we should stop improving the UX

I don't think the answer is to tell designers, “This is visual work, don't touch the UX.” Modernisation should expose UX opportunities. If you're looking closely enough at an old product to modernise it properly, it would be strange if you didn't find things that could work better.

Some of those opportunities will be understood enough and contained enough that ignoring them wouldn't make much sense either.

The question becomes whether we can understand the problem sufficiently within the time available, reach a reasonably justified solution, understand enough of the consequences around it, and absorb the additional implementation and testing effort without materially changing the objective of the modernisation.

Sometimes the answer will be yes. The problem is understood, the improvement is reasonably clear, the impact is contained and the cost is small. Experience has helped us recognise something quickly and there isn't much evidence suggesting that we need to slow down. Take the opportunity and make the experience better.

Other times, you start pulling at the thread and realise there is much more attached to it than you expected. That's probably the point to stop.

Finding a problem doesn't create an obligation to solve it immediately. Sometimes the useful outcome of the work is discovering that the problem deserves a larger investigation than you can give it right now.

The problem can survive the sprint

I think this distinction is particularly important because deferring a UX problem doesn't have to mean abandoning it.

When we talk about trade-offs, it's easy to think of them as one thing winning and another being lost. But quite often what we're actually deciding is what happens now and what has to wait. There is still a cost to that decision, and pretending otherwise doesn't help.

Context can decay. Details will be forgotten. Someone may need to reconstruct parts of the thinking later, and users may continue experiencing something we already suspect could be better. Those things should absolutely be part of the decision when the trade-off is being made, but a trade-off doesn't automatically mean that the loss side has to remain a loss forever.

If we've considered the consequences and deliberately decided that completing the larger objective matters more right now, continually pulling the deferred work back into the current scope means we haven't really made the trade-off at all. At some point we have to accept the cost we've chosen, make use of what that decision gives us and finish the thing we decided was more important.

Then we can come back and when we do, we shouldn't necessarily assume that the solution we were beginning to form months earlier still deserves to be completed simply because we've already invested effort in it. The product may have changed. The architecture may have changed. We may have learned something new from users or from other parts of the product. Some of the context we had before may have disappeared, but the context we have now might also be better. We might even discover that the original problem no longer exists.

What matters to me is that prioritisation doesn't quietly become abandonment.

If something was deferred because something else mattered more at the time, it should still be possible to return to it and ask whether it matters now. Perhaps it still does. Perhaps it has become more important. Perhaps something else solved it along the way, or perhaps what we've learned since means we no longer think it should be solved at all. Any of those outcomes is fine, but if we eventually abandon it, that should be a decision too.

Experience should make us better at stopping too

We often talk about experience making designers faster at solving problems, but perhaps another part of becoming more experienced is getting better at recognising when we shouldn't finish solving one yet.

That's harder than it sounds. It means being willing to put down something you've already invested time in, even when you're finally starting to understand it. It means accepting that the solution forming in your head may be good without assuming that makes it sufficiently justified and sometimes it means accepting that we've learned enough to know we need to learn more is a perfectly useful outcome.

For me, good scope management isn't about refusing to explore anything outside the brief. That would throw away too many useful opportunities, and it would discourage exactly the kind of curiosity I want designers to have.

It's about being willing to explore far enough to understand whether something belongs inside the work we're doing now, or whether we've just discovered a problem that deserves a brief of its own.

Experience will probably continue making us faster at seeing what we could change. I don't want to lose that. Pattern recognition, intuition and the accumulated knowledge that comes from having solved similar problems before are some of the most useful things experience gives us.

But perhaps experience should also make us more comfortable with the possibility that our first answer isn't the answer, that the familiar problem isn't quite the problem we thought it was, or that something worth fixing doesn't necessarily need to be fixed today.

The goal isn't really to become slower. It's to become better at recognising the moments when speed has stopped helping us, so perhaps the question isn't always: Can I make this better?

Sometimes it's: Do I understand this well enough to make it better now?