A Developer’s Guide to Working with Icons
Working on User Interface (UI) back in the early 90’s, before any of the common standards were established, was interesting. I remember working on a communications package and the icon image for the application’s close button was a hand-drawn sunset. The developer wasn’t happy when I pointed out that an icon a user had to think about too much wasn’t really that useful.
Icons are getting slightly rarer within user interfaces. While they still have their purpose — for example, standing in for menus, especially for smaller screens — they are used less often than they used to be. Experimentation is more forgiving, and touch interactions allow for more control of the screen. Futurists assumed that the world’s population would read text less and rely on images more. Of course, today we actually create and consume a great deal more English text than in the past, largely because of mobile phones. We use emojis to accompany our missives, but icons are relegated to a visual shorthand where needed. But they are still everywhere.
If you work on a user interface, you may well need to select icons — even if a graphic designer will construct the final resource. This post guides the developer who has taken responsibility for UI through the stages of icon selection.
On the left is the icon strip taken from an app for a well-known social media platform. (Since I captured this, one of the icons that represents “verify” has changed. Suffice it to say, quite a lot about this app has changed recently.) The icons are usually paired with words if the media query detects enough room, but the strip on the left will be used otherwise.
Most of the images feel familiar. About half use retro representative objects (the bell, the magnifying glass, an envelope). Simple shapes with minimal drawing are preferred, and we will see why later.
Note that the single simplistic pawn-like human figure is used for “Profile”, which means that you might be puzzled as to what the two pawn figures next to each other represent — it is actually the new “Communities” functionality, but it shows that using multiple icon shapes is unwise if the intended meaning is unrelated to the single case.
By comparison, on the right is the icon strip for another similar social media application — it’s a third-party app for another well-known platform. Note that some of the icons are taken from the platform graphics (the at symbol, the heart, the octothorpe) so only a regular user of this social media platform could immediately discern their meaning.
There is also an even more retro representation; a feather (or quill) standing in for “compose”. Where possible, icons should make a thematic set; that is, they should be derived from similar viewpoints. This helps users to work out meaning without cognitive friction. Obviously, a feather is not really coming from the same place as some of the other symbols. Or worse, a feather and a bell might be linked with gothic horror.
But the circular icon third from the bottom is quite unclear — in fact, it stands for “local”. Oddly enough, it appears to be two figures next to each other… again.
The Old Ones
Skeuomorphism is the design practice of making a user interface resemble the real-world object it is emulating. The term also gets used for icons that refer to old objects the real world doesn’t see that much of anymore. If you are old enough, you will have picked up a telephone receiver. Yet the icon for “phone call” remains the one below today. Similarly “message” uses an envelope, as if we send letters off regularly like in a Jane Austen novel. This type of retro is now such a common feature it is not really commented on anymore. Old objects simply were more closely identified with a single function, so are better for icon design. An old home telephone only ever did one thing.
Example Icon Selection
To give ourselves a challenge, let’s think about an icon to represent “seasons”.
A quick word on licensing and ownership. If you take icons intended for production use, check licensing and attribution conditions. The Noun project is a good source of reusable icons with simple attribution terms. They actually have an API, but in general, a web page is the best way to explore the images. While generative AI is in limbo in terms of copyright, projects like Adobe Firefly use AI, but only over their own extensive stock of images. Large corporations will usually have art resources, although they may not be immediately appropriate for software use.
On my first try, I picked these two images from the Noun Project after entering in “seasons”:
Both try to encapsulate all four seasons. The first icon doesn’t seem to represent the usual seasonal order, and the tree may not represent autumn for everyone. But it does nicely represent four quarters, and the circular nature underlines a life process.
The second image does better to represent seasons as part of a cycle. Each image could be separated as required for further use. Using a leaf for spring breaks the climatic metaphor used in the other three seasons; whether a rain cloud is autumnal comes down to where you live.
Of course, we have another option these days. I asked Midjourney to produce an icon. While it is hard to keep it to simple lines, it can easily produce a more artistic and quixotic outcome:
The trick to finding the right image is to focus on the context of the term you need. Find all the aspects of the meaning; and make sure you know which aspects are needed in your app.
For “seasons” we have multiple competing aspects:
- Spring, Summer, Autumn, Winter
- Natural cycle
- Four quarters, division, period
- Climatic changes
This seems trivial, but different apps will need to place emphasis on different aspects, which then guides how an icon could be selected. For a gardening app, we definitely care about the order and the cycle. For a tax app, it is the quarters and division of a year that might be of interest.
We know that icons need to scale for use within apps that adapt to screen size. Predictably the simpler shapes of the second icon survive reduction to common size specifications better:
The Midjourney icon, probably because of the color range, actually retains its artistic feel even as it becomes indecipherable.
Icons are prey to CSS operations on their images. So if they are selectable we have to think about how the CSS will affect a button as it is selected, hovered over, inactive, etc. We can see a little of this going back to the social media icons:
The familiar birdhouse icon (which is no longer so apposite) on the top line alters by inversion as the text thickens to indicate selection; and gains a blue mark to indicate activity. The home icon from Elk uses a color change to indicate selection, whereas the Bluesky home icon goes for text thickness and inversion again.
This is further complicated by color “themes” — like “dark”, which all the apps in the above examples are running. This has led to icons being selected with the following properties:
- Simple, probably retro objects that quickly indicate functionality.
- Single-line drawings, which can change color or thickness and retain meaning.
- Shapes that can invert easily, like two of the “Home” icons above.
- Shapes that are reasonably scalable.
Product icons are always a different kettle of fish, as they are acting on a far larger stage. It isn’t unusual for a product icon to be derived from one of the in-app icons that are unique to the product — but they succumb to an additional range of corporate forces beyond the remit of this post. However, like most long-lived software, they go through revisions over time.
With so many ways to get icons, it is easy to find suitable candidates for probably 70% of what you need. It is only those last items in the set that you may need to work on. Try to keep thematic similarity, and remember that the actual art in the image can easily be changed — and probably will be.