The No Bullshit Guide to Icon Design and Usage

Too much advice on good icon design is just fluff. Essentially it boils down to:

create clear, simple beautiful icons, and avoid making complex ugly ones.

That is worthless advice. Technically it is not wrong, but this is kind of like company mission statements. They exclusively talk about what is good, but as with everything in the world, there is always a question of trade-offs. To understand what good design is you have to understand what trade-offs you got to make to achieve good design.

That is what I will focus on here. There are lots of nice things we can do with our icons, but we got to learn how to prioritize. What is important, and what makes most impact.

Identifiable over Intuitive

The underlying idea of intuitive icons, is that the user should be able to figure out what they mean by simply looking at them. This leads to the idea of treating icon design as if you are designing a little cartoon. Designer put in lots of elements in the drawing to explain what the icon does.

That is a terrible idea, don’t do it! What you end up with is icons, like the ones you see below:

Example of icons with too many small details.

Can you honestly guess what these icons do?

Microsoft Windows is full of these kind of icons. They try to tell you what they are for by adding lots of elements. This is an utterly pointless and futile exercise, because people cannot guess what the icons are anyway until they’ve tried them.

You could say the same about the icons below. For somebody seeing them for the first time, it is impossible to guess what they are for.

Standard icons on music and video players

However the fundamental difference with these and the MS Excel icons I showed previously, is that these have an easily recognizable shape, and they are clearly distinct from each other. Why is that important? Users are going to spend a lot less time learning icons for the first time, than repeatedly using those icons.

Don’t prioritize making your icons intuitive! You will most likely fail. Try to make them clear and distinct, so their purpose is easy to learn. The music player buttons have an abstract relation to what they do, which aid users when they try to recall what the icons do. That is diffent from conveying to a first time viewer of the icon what they do. Design for recall, not first encounter.

If you can make your icons intuitive then do that, but don’t try to accomplish this at the expense of making them easy to identify and distinguish.

Focus on Action not Object

With the cartoon-story-approach to icon design, you end up with a drawing of the object you are doing something with, combined with an annotation of the action you are doing.

Icons conveying an action is being done to a table cell, by showing an icon of table cell. Tiny annotations of the symbols =, >, < and ab are added to convey what action is performed on cell.

The most classic case of this found in any Microsoft product, is the abundance of icons for adding stuff. We get a base icon show what kind of stuff we are adding and then a tiny plus symbol indicating we are adding stuff.

Different icons in MS Excel, which are all used to add something.

The problem with this design is that the action you are doing, is the most important thing, yet the least visible.

In some software this means you end up with rows of icons, which at a glance look identical. At closer inspection you see a tiny annotation tell you that there different actions being performed. This slows down the user and makes your icons fail in their primary function, which is to give users quick access to your application’s functionality.

Instead draw all the user’s attention to the action being done.

You can’t see what object the action is being done to, but you can very clearly distinguish between the actions being performed.

Utilize Context to Reduce Need of Details in Icons

You will probably protest and say, “how is the user going to be able to distinguish between different add operations?”

That is a great question. The problem with telling you how to design icons, is that it can’t be done without considering context. Icons are never alone. E.g. if you look at Apple software you never see plus and minus annotation combined with an icon. Instead buttons are placed in a context.

Using standarized icons for adding and removing networks. We don’t need little icons represent a network with a + and - annotion on them.

This shows a list of networks, and it is clear due to the proximity of the icons that they add and remove networks to the list.

Apple uses context for less common operations such as stepping inside code you are debugging in their integrated developing environment (IDE) xCode.

Highlighted in orange: Upper right corner, are icons for hiding and showing sidebars and bottom bars. Lower middle are icons for running, pausing and stepping through program code in the xCode debugger.

When you start debugging a new pane is shown at the bottom, giving you information about where you are inside your program code. Right above this information you got buttons for controlling you’re debugging. While these buttons are quite abstract, you can infer their meaning by context.

The buttons highlighted in the top right, have a different context, and hence you can infer that by being at the top they influence the whole application window. These buttons are used to configure what you see in the main area.

Figuring out the meaning of buttons is harder without context. E.g. Microsoft’s IDE, Visual Studio, has for many years kept buttons for debugging together with a whole host of other unrelated buttons in the top toolbar.

MS Visual Studio. On second row we got a toolbar for running, pausing and stepping through program code in the Visual Studio debugger.

As you can see here in MS Visual Studio, the icons for controlling the debugger is hiding among lots of other toolbar icons. You need to spend some time locating it. The problem with this approach is that it forces you to design your icons more distinct form each other. You can use simple icons such as plus, minus, arrow left and arrow right, because these could be related to almost any action.

xCode in contrast keeps rather few icons in the main toolbar. This is what xCode looks like right after you have started a project.

xCode upon starting a new project. Only ever a single row of button on the top.

Notice both how simple and few icons they use compared to MS Visual Studio. This is accomplished by showing the majority of icons in context when needed and simply avoid using icons which represent operations common across absolutely all Mac applications such as loading and saving. You don’t need icons to convey that these operations exist. That is obvious already.

Focus on Objects Rather than Actions

I know I said the reverse earlier, but sometimes every button adds something. Then what is important is not the action add, but rather what gets added.

This is a screenshot from Apple’s spreadsheet application Numbers. The icons:

• Table
• Chart
• Text
• Shape
• Media

All add an object to your open sheet. However it would be superfluous to affix a plus symbol to every icon to indicate that.

Don’t Overuse Icons, Sometimes Text is Better!

The simplest solution to a lot of icon design challenges is to simply not create an icon. Studies show icons are actually not that easy to use. A problem with using too many icons is as I described earlier that it forces you to complicate the design of your other icons to make the distinguishable from each other. By keeping the number of icons to a minimum, you also make it easier to create unique designs for the actions or object you do want to use icons for.

Usage of MS Windows ribbon design in MS Excel. Green outline shows some different icons for selecting background and text color.

The Microsoft ribbon design in an example of an extreme overuse of icons. Almost every action has to have an associated icon. This creates the problem when e.g. selecting color. Notice how icons for selecting color has to be made more complex to distinguish between what sort of color we are selecting. Are we selecting e.g. a font color or a cell color?

You can see how Apple solves this in Numbers by simply not using an icon at all but using a standard color well widget. The context tells the user what sort of color gets selected when they hit the color button.

Apple iWork applications avoid complex main toolbars by placing all context dependent UI components in a sidebar. So the currently selected object will decide what is shown in the sidebar.

The color wells themselves don’t tell us which color they affect, however there are “fill” and “Border” headlines which communicate which colors are affected. For font colors we got a selection in the sidebar like this:

The trick Apple has done in this case to get away from the abundance of icons used by Microsoft is to use a whole sidebar instead of a toolbar for most of their functionality. They have also divided it into multiple tabs and with sections which can be collapsed and expanded.

This makes it easier for them to utilize headlines, labels, layout and spacing to communicate the purpose of different UI components. The MS ribbon on the other hand has severe size constraints and hence must cram in functionality on very little screen real-estate.

This is a question you have to consider when doing icon design. Can the overall UI be redesigned to require fewer icons and allow more standardized icons to be used?

Color and Shape of Icons

I don’t want to write too much about the drawing of the icons themselves as you can find plenty of other guides on this. I wrote this guide mainly because I realized when googling that almost nobody actually discuss how to approach icon design from a more philosophical stand point. Like how you think before you even start firing up photoshop.

Icon silhouette

Create an easily distinguishable silhouette, for your icons. Basically make filled monochrome icons first and make sure that you can distinguish them from each other by outline or silhouette alone.

This is an example of silhouette icons.

Pick 2 to 3 Primary Colors

If you look at Apple’s iOS icons e.g. you will notice that each application icon is dominated by 2–3 unique colors. This makes each icon easily distinguishable as opposed to if you used lots of colors or used the same primary colors over and over again.

For toolbar designs you should also stick to a few dominant colors. However with toolbar design you might want to keep colors similar between strongly related icons.

Toolbar icons which can be selected for Apple’s Keynote application. You can only fill one row at a time. On each icon 1–3 colors dominate.

For instance you may notice forward, backwards, front and back icons follow similar color scheme. However completely unrelated icons such as table and guides, have complete different color schemes. This is wise since they have very similar boxy shapes.

Contrast this with e.g. toolbar icons in MS Office. The same color scheme is used for icons which look similar in shape but which are functionality quite different.

Icons from MS Office. Few colors are used, however the same color selection is repeated for unrelated but similar looking icons.

E.g. some of the blue and gray icons likely represent dialogs, documents or property lists while others represent spreadsheets. So despite having very similar overall shape, but entirely different usage, they use similar colors.

Traffic Signs Not Images

When designing icons try to think more in terms of traffic signs rather than in terms of images or pictures. You want to create an iconized version of reality not something photo realistic.

I know flat design is all the rage these days, but personally I think one should be careful about simplifying too much. Some mobile UIs have made UI elements so simple you can distinguish them from mere text or information. That is IMHO not good UI design. So I don’t mean you should literally make icons look like traffic signs but that they serve as useful inspiration towards how to think about icon design.

Disclaimer

I am not actually a UX designer. I am simply a developer who cares deeply about usability and design. I wrote this piece out of frustration that professional UX designers and experts often speak language which software developers don’t understand. I want reach developers and teach them about good design because for desktop application development which I do, they still have substantial influence on how user interface ends up.

So I am happy to get feedback from UX professionals to improve this story.