July 12, 2012
As I’m responsible for both the code and the graphics of Grasshopper™, icon design is a significant part of my job. In fact, my very first productive work on computers at all was icon design. When I was 14-ish my dad got an Acorn RISC PC with RISC OS 3.5 and using applications such as Paint, Draw, Artworks and later on PhotoDesk and Compo I spend many a happy afternoon replacing icons for file formats, applications and toolbars. It wasn’t until the start of my actual programming career that icon design became a vital part of my skill set and I have a suspicion that —just like programming itself— it’s something you simply cannot master. No matter how much code you write or how many icons you draw, there’s always room for improvement.
These days I work on Windows and I primarily use Xara for my icon design, augmented by Rhino for complicated 3D shapes and Paint.NET for pixel post-processing. Over the years I have amassed some opinions, guidelines and techniques on the matter, some of which I’d like to share with all of you. Let’s start with what icons are and what they should not be.
- Icons are visual cues that aid in the process of navigation, messaging or analysis.
- Icons are conduits of love from developers to users.
- Icons are not descriptions of features.
- Icons are not art.
I’m aware that a lot of people disagree with these points, too bad for them that they are wrong. Allow me to defend my position point by point.
 Icons are visual cues that aid in the process of navigation, messaging or analysis.
Anything that doesn’t serve a purpose should not be part of a UX. Information overload is one of the biggest problems in interface design and any pixels wasted on something irrelevant are pixels that cannot be used for something worthwhile. The three most important functions for icons are navigation (finding the right pixel to click), messaging (the application informing the user of vital events) and analysis (the user retrieving information about the state of the application); icons help the user find the right tree in the interface forest. For this to work different icons must look different, even in peripheral vision. When you use very similar shapes and/or colour palettes, icons become less distinguishable and thus less able to aid the user. Take Photoshop for example, it has been around since 1988 and Adobe has not been squeamish about redesigning how it looks and works (for which I applaud them). There’s a lovely article on Hong Kiat about the evolution of Photoshop, but here I’m only concerned with the main toolbar (click to embiggen):
There’s a number of interesting effects over time here. Initially the resolution and colour depth of displays were very limited and therefore the early toolbars have a very clean and efficient feel to them. As time goes on displays support more shades and more pixels and the toolbar becomes both bigger and more crowded. There are more edges, more separators, more shadows. This upward trend of visual density is broken in Ps7 and CS3 starts to look almost as clean as PS.87 used to be. Note that the graphics quality of the icons either goes up or remains constant from left to right. But image quality and functionality are not the same and for a long time Adobe sacrificed one and favoured the other.
Another interesting thing to note is the most prominent item on the toolbars; the Photoshop banner image. Not only is this utterly redundant information, it is also the only thing on the toolbar that has a photoreal quality to it, including colours in Ps7 and CS3. To be fair, CS4 (not shown) no longer has this banner. It seems that as we hone our UX design skills we revert to the minimalistic approach imposed on us in the early days of computing. As it turns out doing things because you can is a bad strategy even in UX design.
However the most striking feature of the Photoshop toolbar is that it is entirely greyscale. Colours can serve as excellent markers that speed up navigation and one ignores this benefit at one’s own peril. The icons actually do have colour, but this is only visible on mouse-over, which is both redundant (it doesn’t tell the user anything she didn’t already know) and too late.
From a functional point of view, we should expect icons to be memorable and recognizable. Photoshop does a good job of the former, but not the latter.
 Icons are conduits of love from developers to users.
Laugh if you must, but I’m dead serious about this. We humans are visual animals and presentation matters. Users will never see the code that runs your application, they’ll only see what it looks like. Icons are one way in which a developer can show that he cares enough about his users to put in the effort and provide them with good icons. From a functional point of view there may not be a difference between an ugly and a pretty icon. They may be equally memorable and recognizable. From an emotional point of view, it can make all the difference in the world.
Of course I’m not arguing that icons are the only conduit of love, nor that it takes only pretty icons to make someone feel good about using your software. I’m just saying you wouldn’t show up for a wedding without showering and wearing clean clothes, so why would it be all right to take the same approach to UX design? Over the past 5 years or so there has been a rapid shift in this attitude in software land, no doubt fuelled by Apple’s new rise to eminence. It seems a lot of software companies have started hiring professionals to do their graphics work for them and by and large this has been a good thing. But it’s not enough to have someone on the team who’s good at graphics, in fact, if you’re unlucky, it may in fact be a set-back. Read on.
 Icons are not descriptions of features.
Remember my two fundamental icon characteristics? Icons need to be memorable and recognizable. They do not necessarily need to be representative. Indeed, many of the standard icons we all know are not. Nobody uses floppy-discs anymore, yet it is still the standard Save icon. Open is often depicted as a folder, which is silly as what we open are files, not folders. Paste uses a clipboard image, which is a tangential reference to a real world counterpart of a mechanism that allows all applications within the same OS to share data. And that’s all fine; these icons work great. And yet a lot of people seem to feel that an icon should describe the feature it represents, and that any failure to do so is either unprofessional or cheating.
Imagine if you will that the concept of a clipboard with the associated actions of cut, copy and paste is not well established. Let’s say that your application introduces this functionality for the first time. First of all, would you have called it “clipboard”, “cut”, “copy” and “paste”? Could be, the terms are borrowed from the existing practice of editing paper documents using scissors and glue, but you could just as easily have picked the words “pinboard”, “take”, “duplicate” and “insert” and it would have worked just as well. Would you have used scissors and a clipboard icon to represent Take and Insert? Very unlikely I should say. Scissors and clipboards are allusions to the metaphors we originally assigned to these actions. But we can go even further than this level of abstraction. The icon for paste could have been a tube of toothpaste, and as long as everyone ends up using that same imagery, it would have worked just as well. Hell, the icon for paste could have been a pink sphere, and as long as cut and copy aren’t red and purple spheres, it would have worked just as well.
If you want to explain what a feature does, either use tooltips or a help file. Don’t try and put too much gunk into an icon as it will most likely affect how easily people can recognize and memorize it.
 Icons are not art.
As mentioned previously, icons are purely functional beasts. There is no room for artistic exuberance because pixels are at a premium. I know that some people have a much wider definition of Art than I do, and for them, Icon Design may well count as Art. I however prefer to draw a distinction between the functional (design) and the expressive (Art). Many things are a little bit of both, some things are unambiguously one or the other. Icons should be unambiguously functional. There is room for Art in UX design though, banners and splashes for example are cases where pixels are briefly abundant and therefore allow for non-functional use.
Techniques explained by means of an example.
Time to move on from posturing to advice. This post has already grown far beyond what I was planning so I’ll keep it very brief. The following is a list of unsorted guidelines, not rules:
- Use colours, but not too many in a single image. Two is already pushing it.
- Don’t add too much detail, photorealism is not important or even desirable.
- Don’t use perspective unless it is a vital part of the image.
- Don’t use near-vertical or near-horizontal lines as they cannot be anti-aliased properly.
- Make a new image for every size. Icons are usually small images so they need to be very crisp. You’ll only achieve this by aligning your geometry with the pixel-grid.
- Don’t use black outlines. You’re almost always better off using a dark grey or darker version of the fill-colour of a shape.
- Use shadows to provide depth, but make them very faint.
- Large areas should have subtle gradients rather than solid fills.
- Don’t use text in images if you can help it.
- Don’t imply transparency unless it’s a vital part of the image.
- Add a faint (5%~10% opacity) one-pixel edge around high-contrast transitions. This creates an über-anti-aliasing effect when regular anti-aliasing is not sufficient to smooth a transition.
- Only use dark outlines for silhouette edges. Internal creases are best left alone.
- When representing real world materials (such as wood or paper) apply a faint pixel noise.
- Don’t stack icons too close together. If you have no control over icon placement in a UX, be sure to leave empty pixels around the edges.
I started with a pixel grid and an isometric drawing of a open box. I’m going to be adding outlines on top of these surfaces rather than behind them, so all the vertices are aligned to the middle of pixels, rather than points between pixels. Basic shading has already been applied (light always comes from the upper left direction) and the faces on the front and right of the box have a fairly strong gradient that darkens them at the top.
Once the fills are done I add the outlines. I use a dark shade of brown rather than black to minimize anti-aliasing artefacts. I could have used different shades of dark brown for different fill shades, but I couldn’t be bothered in this case. Note that only silhouette edges have been outlined, and even there I omitted the outlines where the flap surfaces give way to the interior of the box. Outlines become thinner when they terminate, I just happen to like that style.
Time to add some depth to the image with drop-shadows. I prefer my shadows to fade away rather than be crisply outlined. Note that drop shadows do not need to be geometrically correct in order to conjure up a feeling of depth. In fact, I often find that using non-correct shadow outlines gives a more pleasing result.
Ultimately, I want to soften the transition between the inside of the box and the back flaps. A real box would most likely have curved surfaces here rather than sharp creases and I want to convey that imperfection. The line on the left is of an in between colour while the line on the right is more reminiscent of a highlight. After the image was exported, noise was applied using Paint.NET (not shown).
 I’m aware that homonymic metaphors are very much language bound and that therefore a tube of toothpaste may in fact not work quite as well for non-English users. However the difference in efficacy will be small as long as the icon is memorable.