Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

When trying to find the optimal size and placement for an element, I can model the utility using Fitt's law. Of course, using this law by itself will just tell me that everything should be massive and infinitely close.

So we need some way of determining the cost of creating an object of some size & placement. My initial thought was to model it as an opportunity cost, and say:

Let p be the probability that the object will be used, and F(d,s) be Fitt's equation for a distance d and size s. Then the utility U(p,d,s) = p × F(d,s) - (1-p) × F(d,s)

Where the term p * F(d,s) indicates the utility if the object is used, and the term (1-p)*F(d,s) indicates the (negative) utility if the object is not used.

This has the obvious result: if p > .5, make it infinitely large; if p < .5, make it infinitely small.

I think what I really want is to add an entry to my "lottery" with some utility assigned to blank space. But I'm not really sure what that utility would be.

I'm sure this must be heavily studied. Can anyone point me to some resources to help clear up my confusion?

EDIT: Let's take a simple example. I can put all the actions they need under a menu. I can duplicate some of these actions as "quick buttons" to make it quicker for them to get to these actions. What is the optimal number of quick buttons?

Some basic observations:

  • If there are one or two actions which are used way more than the others, the ideal is to show only those one or two. Adding the infrequently used items isn't worth the cost of the clutter.
  • Even if all items are used with equal frequency, you don't want to put every single action as a quick button, because then you're just duplicating the menu

Can we formalize these observations?

Button count

share|improve this question
Can you provide some images of the results of your calculations? Images say more than words, and probably, equations. –  Naoise Golden Dec 29 '11 at 20:31
But +1 for the mind-tingling scientific question! –  Naoise Golden Dec 29 '11 at 20:34
@Naoise: It's hard to plot an equation in three variables, but assuming constant width you get something like this. Note that it peaks at d=0 when p < .5, and at d=infinity when p > .5. –  Xodarap Dec 29 '11 at 20:38
This approach takes no account for the relationship between elements and gestalt principles. Eg alignment, common sizes, patterns, groups, closeness of related elements. In fact it just fails to deal with just about every UX requirement I can think of. I can't see the benefit of where it's leading...am I missing something? Am I shortly to be out of a job thanks to an equation...? –  Roger Attrill Dec 29 '11 at 21:01
It wouldn't be a simple as Fitt's Law, that is true, but that doesn't mean Fitt's is irrelevant. It's more likely to be a complex combination of Fitt's, GOMS, Hick's, and some formulation of Gestalt principles (see csc.ncsu.edu/faculty/healey/PP/#Preattentive for a tiny step in that direction). –  Erics Jan 1 '12 at 4:17

2 Answers 2

So I've been thinking about this, and I think we can model it with a combination of Fitt's and Hick's laws.

  • Assume that the quick buttons are unordered, so time to find the correct one is linear
  • The menu is ordered, so it's the logarithmic Hick's.
  • The user first looks to see if it's on the quick button menu, and then looks on the menu.
  • The distance moved is linearly proportional to the number of elements in the list.

Under these assumptions, the average time taken to find a menu item can be found with the following octave code:

% Finds the average time taken to get a menu item
% menuProbs is a vector of probabilities that each element will be chosen
% quickProbs is the same, but for the quick buttons
function ben = avgTime(menuProbs, quickProbs)
ben = sum(menuProbs) * (length(quickProbs) + ...   % time to scan quick bar
                        log2(length(menuProbs)) + ... % time to find in menu
                        log2(1 + length(menuProbs))) + ... % time to move to menu
    sum(quickProbs) * (length(quickProbs) + ... % time to find in quick bar
                       log2(1 + length(menuProbs))); % time to move to quick bar

As an example: Let's suppose that there's a menu items of probability .3, .15, .05 and the rest .01. A plot of average time taken:

Time plot

You can see that the time hits a minimum at a few quick buttons.

I'm still hoping someone will post a more formal version of this, but putting it out there to spark discussion.

share|improve this answer

Like some of the commenters above, I'm sceptical that 'clutter' is easy to model with an equation. 'Clutter' is a function of several factors, not just a matter of increasing seek time by adding extra items -

  • Whether the additional items break or emphasise existing gridlines
  • Whether the items can be grouped logically, whether this grouping is understood by the user, and therefore whether the user is equipped to traverse items efficiently
  • Whether the items in a menu have a special relation to the content of the workspace
  • Where extra items are added (I am not convinced that users randomly iterate through groups when seeking elements)
  • Whether items have similar or easily-confused labels that create occasional productivity costs through misreading
  • Whether adding items entails removing borders, spacing and visual effects that either possess semantic value or otherwise aid item seek

Even then, I'm still not convinced that the cost of clutter is as simple as productivity cost. 'Clutter' creates a variety of issues that are difficult to quantify - things around the users' trust in a 'messy' service, perception of service stability, identification with interfaces embodying particular kinds of aesthetics - all sorts of factors in the usage of a service that need to be modelled in UX practice.

Whilst I wish you luck, I'm just not convinced that we can find a useful equation that isn't either a) impossible to calculate, thanks to reliance on elements that can't be quantitatively assessed, or b) lacking practical use, because it fails to model relevant factors.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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