Stop counting clicks

A product can put everything one click away and still leave people wondering where to start. On a recent enterprise software project, many tools and modules had been grouped on the homepage to make them easier to access. Yet during testing, many people skipped that page and used the main navigation instead. The shortcuts were there, but people chose another route. That’s worth paying attention to, especially when so many design decisions start with a request to reduce clicks. Before we shorten the path, we need to understand why people aren’t taking it.

The symptom isn’t always the cause

When someone tells us a product feels complicated, it’s tempting to look for steps to remove. We’re often asked to keep an action within three clicks, and we understand the appeal: it gives a team a clear target. But it also assumes that the number of interactions is what makes the task difficult. That’s an assumption we need to check.

The difficulty might come from navigation that’s hard to follow, labels that don’t match the language people use, or information that appears too late. Someone might be clicking more because they’re searching for guidance, not because the task requires all those steps. In that case, the extra clicks are a symptom. A shorter route won’t necessarily solve the problem.

That distinction matters in the homepage example. We observed people choosing the main navigation, but that alone didn’t tell us why. Putting tools one click away can still leave someone with a lot to scan, compare, and interpret before making a choice. The click count may be low while the mental effort remains high. It’s something to investigate, rather than a reason to assume that fewer clicks will help.

What happens when we solve the wrong problem?

Consider a workflow that guides someone through five decisions, one at a time. If we assume the number of steps is the problem, putting all five decisions on one screen looks like an improvement. But the decisions haven’t gone away. Now the user may need to figure out the order, understand which choices affect the others, and decide what to deal with first. We’ve made the interface shorter without necessarily making the task easier. Sometimes, removing a step just leaves more of the work to the user.

In enterprise software, some complexity belongs to the work itself. A request may need an approval, one decision may affect another, and different roles may need different information. We can question those processes too, but hiding them won’t make them disappear. Our role as designers is to understand what people need to get done and help them work through it, without asking them to figure everything out at once.

That doesn’t mean adding steps is the answer, either. A review screen before an important submission can be useful. The same confirmation repeated throughout an everyday task can quickly get in the way. Someone who uses a tool all day may need a more direct route than someone opening it for the first time. Both needs are legitimate. We have to understand the context rather than apply the same rule everywhere.

Start with what makes the work difficult

Watching people complete real tasks gives us a better starting point. Where do they hesitate, backtrack, or ask for help? What were they expecting to happen? If they’re searching for information they need to make a decision, bring that information forward. If they’re struggling to choose between options, look at how those options are named and organized. And if a step serves no useful purpose, remove it. The observation should guide the change.

From there, we can make a change and see whether it actually helps. Can people complete the task without asking for help? Are they making fewer mistakes or going back to check things less often? Do they know whether the task is finished? The number of clicks still belongs in that assessment, especially for repetitive work. It just shouldn’t decide, on its own, whether the design succeeds.

The goal is to understand what makes the task difficult before deciding how to simplify it. Sometimes the answer is removing a step. Sometimes it’s adding one. And sometimes, the number of steps was never the problem. What matters is whether the change makes the work easier.

That’s the approach we take at Osedea. We work closely with users to understand what’s getting in their way, explore better ways to support their work, and test those ideas in practice. Does your product feel more complicated than it should? Let’s talk about your project and how we could make it easier to use.

‍