Icons are everywhere, both in software and outside of it. The power of an image helps users identify things quickly and accurately.
The KDE visual design group say that icons "convey meaning that users perceive almost instantaneously." They can be also useful for internationalization and when concepts are hard to describe in words.
Looking for how to add icons in Balsamiq? Check out our documentation on Adding Icons.
When to use icons
It is rare that icon use is actively discouraged. The biggest danger when using icons is the use of ambiguous or unclear icons, which can either mislead the user or conflict with their adjacent label, resulting in a slower and/or more frustrating experience with your product. In short, bad icons are costly.
The GNOME developer guidelines state that choosing the correct icon for each purpose is "vital to making sure that your application is usable." They go on to encourage their use, though, calling them "an essential part of any application" and "a crucial part of its identity."
Icons are also a great way to provide redundancy, especially for important messages. In the following example, there are 3 ways that the error state is conveyed: the text itself, the color, and the icon. The icon reinforces the severity of the message.
When used correctly, icons can speed up a user's interaction with your product, enhance its usability, and reinforce your brand identity.
How to use icons
Note: The Google Material Design Guidelines differentiate between product icons and system icons. Product icons are primarily for branding and visual identity purposes. An example of a product icon is an application icon on the task bar or home screen. The guidelines below apply mostly to system icons, which are identifiers for actions or commands.
- Adjust the degree of abstractness according to familiarity of the metaphor.1
- Apply metaphors only once (e.g. do not use a brush twice for different options).1
- Use arrows only if they can easily be related to spatial features such as Previous/Next in a sequence or Up/Down in a hierarchy. Avoid using arrows metaphorically (such as for Reply/Forward or Undo/Redo).1
- Use consistent rules for placing text next to icons.1
- Icons that lose details when shrunk may need a special version that preserves meaning even at smaller sizes. Critical details may become unrecognizable when scaled down.1
- Avoid using text in icon designs; it may not scale well to smaller sizes.1
- Follow conventions. Don't create new metaphors when familiar ones exist.2
- Always accompany icons with text labels unless the icon metaphors are nearly universally recognized (e.g., home, print, search), which is rare.3
- Don't use icons that are commonly associated with a different meaning.4
- Establish color and design rules for icons and apply them consistently. See the Google Material Design guidelines for a good example.
- Apply tooltips for additional information or when labels aren't used.
Icons often have "on" and "off" variants that are used to indicate states when used as buttons. A common example is switching between "liking" and "unliking" something. Badges can also be overlaid on top of icons to indicate a more complex state.5
Aside from a simpler version of icons, called badges5, most variations in icons come from their look and feel. Some are monochromatic and simple, others are bright and intricate. They can use a "filled" or "outline/hollow" style.6 The most important thing is that they are consistently styled and quick to grasp.
- KDE Human Interface Guidelines
- GNOME Human Interface Guidelines
- Nielsen Norman Group
- Nielsen Norman Group
- Microsoft UWP Guidelines
- Todd Wolfson