Are there any rules on when to use icons vs. icons with text vs. just text links in a web application?
[disk icon] save
Extra question: Is [disk icon] save -or- save [disk icon] preferable?
Icons are notoriously ineffective at labels, being very difficult to interpret correctly without training or experience. For most situations, users learn correct interpretations better with text alone than with icons alone. See: Wiedenbeck, S (1999). The use of icons and labels in an end user application program: An empirical study of learning and retention. Behaviour & Information Technology, 18(2), p68-82.
Icons are especially bad for anything abstract, such as Invoice or Bid, since abstract things generally do not have any strong visual image (both Invoice and Bid could be represented as paper documents, but how would you distinguish them?). Similarly, icons are particularly bad for actions (e.g., Save, Publish); it’s hard to clearly show a process with a picture. Yes, icons are used all the time in toolbars for actions, but toolbars were intended for experts, and nonetheless users are frequently confused by them (on average, users know only six Word toolbar items after regularly using Word for two years).
Icons can save space over text, but at the price of recognition. For small icons, such as 16x16 pixel, it’s very difficult for users to even recognize what they are supposed to be a picture of, let alone what the picture is supposed to stand for. One user I know thought the “disk” icon for save was a picture of a TV (she was old enough to know what a floppy disk was). I personally used Word for years thinking the Track Changes icon was some sort of stylized Rosetta Stone. Expert users find it easier to rely on the memorized physical position of the toolbar controls rather than the icon labels to pick a control. Bigger icons (e.g., at least 32 by 32 pixels) can help recognition, but take so much space you’re better off using the space for a clear text label. If space is limited, often you’re better off using abbreviated text than icons.
It’s extraordinary difficult to get icons right. Do not attempt to develop a new icon without extensive iterations of user testing. Even then, you may fail. Microsoft designers tried everything to make interpretable icons for Outlook’s toolbar before giving up and going with text labels on key controls.
Icon labels also make tech support difficult (e.g., “Click on the yellow sheet with a blue checkmark,” versus “Click on ‘Accept’”).
As rule of thumb, icons alone should only be permitted when at least two out of the following three conditions apply:
Tooltips are required for icons when they are used alone, but they are a poor substituted for text labels. You users shouldn’t have to use you app by groping around for things. The fact that text labels never need graphic tooltips is a pretty good clue that text is better than icons.
If space allows, icons combined with text is best (I think there was research showing this from the late 1980s but I can’t find it). Selective use of icons with text makes certain items stand out more or add visual interest. It may also improve the scanability of the items, but good text labels can do this too. Users have been known to subjectively think an app is easier if it has icons, even when they don’t actually improve performance (see Wiedenbeck, 1999 cite above), so that’s another reason to have icons and text combined.
I usually see the icon either above or left of the text label. I don’t think it’s necessarily inherently better than the alternatives, but it’s a convention you should follow too if you have controls next to each other so the user can rely on experience to tell which text label goes with which icon.
Let the user choose, defaulting to Both.
Text+Icon helps first-time user learn the icons; but as he uses the application more, the user will get used to the icon and doesn't need the text anymore. Once he learned what the icons means, he'd prefer a larger workspace rather than the redundant Text.
According to research cited by Don Norman, icons alone work the least well. Solo text works better than icons. And text + icons works best.
Firstly, when are you going to design a user interface you have to consider the principles of usability (consistency, affordance, etc.). Affordance is one of the main concepts and it means that your interface should be intuitive. For example, your icons should be related with the meaning of the following action like the example cited above for save icon by Michael. Some icons are also standardized and you can reuse the meaning. The point is that if you use only icons for tool-bars, etc. you have to use the tooltip in the case that the icon is not good enough to express the meaning but if your icons are permissive enough they do not need a label and the tooltip could be enough.
In any case, it is difficult to design icons specially when your system is for an specific system and you have to design icons. In this case, you can propose some designs and evaluate it with the users. It could be helpful to know what the user thinks about your system, visual interfaces and icons. Also you can make a re-memorable test one day after your real test trying to evaluate if the users can remember your icons, the meaning or your icons or the possible areas where they can find the action that you are asking. Also a questionnaire could help if you have more than one design for icons.
On the other hand, if you need to put the label I think that it is better the label below the icon: [icon] [label]
Remember that “An affordance is an aspect of an object that makes it obvious how the object is to be used. In user interface displays, the features that create affordances are usually visual . .." Rosson, M. B. & Carroll, J. M. (2002) Usability Engineering, Morgan Kaufmann.
Or maybe if you have time... you can read this one: www.cs.swan.ac.uk/~csharold/cv/files/Affordance.pdf
If during the design process you have considered the affordance, maybe the labels are not necessary and you just use the tooltip otherwise you can consider the labels below the icons and evaluate or propose more designs to be evaluated with users(no so many) they can be colleagues at the beginning until the version that could be tested with final users.