3

I am designing a web app in which people can come in and rate "objects" and comment on them. I know that the easier it is for the user to perform the main activities the better, but I was wondering if there's any documentation or resource to which I can refer in regards of how many clicks are recommended.

Perhaps too few ain't the best, perhaps a fixed number has been set (e.g. no more than 4 clicks, 2-3 recommended).

What should I be looking for in this subject?

2
  • 2
    The answer is enough to complete the task and no more.
    – DA01
    Commented Mar 24, 2011 at 22:13
  • As stated in my question I agree that the less the better :). My question was if there are any resources that point to studies or anything regarding the subjects. Such as how many clicks does it take for a common user to enter a site, try and find what he's looking for, give up and leave. I'm pretty sure there gotta be articles about it :).
    – PedroC88
    Commented Mar 25, 2011 at 0:23

3 Answers 3

4

See Neilsen's take here: http://www.useit.com/alertbox/interaction-elasticity.html

Note he warns against focusing on the number of clicks - he takes the approach (as Peter of the Corn noted in his post) that it's the ease of clicks that really matters. He also adds that context plays a role in what is acceptable, and that you need a good understanding of why a user must click and what happens when they click to know what is acceptable.

Scott Hamill at UXBooth posted this view: http://www.uxbooth.com/blog/stop-counting-clicks/

Given the name of the article I'm not sure there's much more to say, except he quotes research that shows how essential it is that the user feels a click was worth it - if each click provides some measure of success in a task, you don't need to bother counting.

9

While it is generally agreed as a rule of thumb that fewer clicks are better, a more important metric is considering how much the user has to think to complete the action. Ten thoughtless clicks are a great leap better than having to perform one confusing click.

As long as the process is simple and requires very little thought, the number of clicks requires is almost a moot point (although more than five or six I would guess is usually excessive). If you can reduce the number of clicks without sacrificing (and perhaps even enhancing) the ease of use, by all means, do it. If reducing the number of clicks makes it more difficult, don't do it.

EDIT: The ideas in the post above are basically copied from the book Don't Make Me Think by Steve Krug. He talks about the common idea that "it should never take more than X clicks to get anywhere on the site," and how this methodology is flawed because clicks are fairly inexpensive for the user, but stuffing everything into fewer pages to make fewer clicks is very detrimental to the user experience.

2
  • Maybe it's true for web apps, but not entirely correct for desktop workflow applications. RSI rears its ugly head. Commented Jun 15, 2013 at 20:58
  • @DeerHunter I agree that UX for workflow applications is different: you can make more sacrifices in the initial learning curve for a faster workflow than you can in a public-facing application. This is the case regardless of whether it's a desktop app or a web app. Commented Jun 16, 2013 at 0:17
3

Grab the study 'Designing for the Scent of Information' from UIE:

http://www.uie.com/reports/scent_of_information/

In summary: The specific number of clicks (or pages) is irrelevant. What matters is that the user feels that they are progressing through their task as they click.

Lots of suits like to repeat the phrase "3 clicks! Every page should be accessible in 3 clicks!" which I put up there with phrases like "Ideally you only have 7 menu items" or "be sure to put the content above the fold". All of which have little to no basis in any real user behavior or research.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.