The Vernacular of Icons
Icons are a wonderful thing. Whether used in software development, the custom-designed interface of a SaaS application, or on a website, icons can be a useful design shorthand. Especially when it comes to software, where it seems like the most successful designs are the simplest designs, every pixel is scrutinized for its overall effectiveness. Often, icons can be used to make designs more efficient, clean, and usable. Icons can make copy more skimmable, features more discoverable, and application functions more accessible. However, like anything else, there is a danger to the over-reliance on icons.
The problem with icons, as we see it anyway, has to do with the common language of the web. That is, often it is the least common denominator that is used to judge an application’s, or website’s, usability, and icons (especially in the context of the web) just have not been used long enough to establish a common meaning that everyone knows.
For example, what does the icon to the left mean? This should be simple, we see icons like this almost every day. However, depending on who you are, it could be a lot of things. I imagine possible answers would vary wildly among different age groups, different levels of web and/or software use, and different cultures. That is precisely the problem with icons. They, often, do not have a direct, concrete meaning. And, with more and more types of software, and interactive design in general, using icons, sometimes the meanings of icons can be stretched in unexpected ways.
The reason why this happens is usually simple enough. As a designer, or developer, we often go looking for icons to match what we are trying to say. For example, we know that we need something for a print function, and the icon above happens to be the first one we see. We think to ourselves, “Well, that is close enough, paper can mean print, right?” The problem is, this approach can be backwards. That is, instead of looking for an icon that roughly matches what we are trying to say, we should look at a given icon and ask ourselves “What would this icon mean to most people?” Sure, a piece of paper makes sense to use in the context of a print function, but if we asked ten people what the paper icon meant to them, how many would answer “To print, of course!” Probably not many (if any at all).
Another trap we can often fall into is tucking icons either to the side, or on the top of our designs. We are already reaping the clutter savings of using an icon instead of clunky text, why not clean up our design even more by moving the icon(s) out of the way? The reason is, that by making a design too spartan, we make it harder to use. Sure, our 16×16 pixel icons look pretty, and our application has plenty of whitespace, but no one can figure out how to do anything.
Now, that is not to say that icons are always confusing. Quite the contrary, actually, icons can be a great way to simplify a user interface and make even the most boring (or promotional) content easily skimmable. Personally, I think we, as designers of things people use, run into trouble when we rely solely on icons to communicate what we are trying to say. Icons can be a great helper for intuitive architecture, labels, and function, but they are rarely a substitute for any of these things.
The best design option is often a hybrid approach of using icons and short text. This way, you can give people an idea what each label means (without forcing them to read each one), and also give them an option to read the labels to know exactly what each function does. To me, this is the best of both worlds. You get the easy skimmability and recognition of icons, with the precise labeling of text.
Here is an example of what I mean. Take Google’s revamped design for Gmail (which is shared by many of their applications). By default, the header functions in an email look like this:
Now, I will grant you that this is a very clean design, but what good does using only icons give you if you have to mouse-over each item to see what it does? To me, this adds an unnecessary learning-curve to the application. Sure, you figure it out pretty fast, if you use gmail all of the time, but what if you don’t? What if you use an email client most of the time and only use online Gmail every now and then? If that is the case, I think you will find yourself mousing-over the buttons on the page to figure out (or remind yourself) what each one does. To me, this is introducing a usability problem for negligible design clutter savings. To put it more simply, it is making something more difficult to use with little, if any, design gain for the user.
Now, imagine if Google had used even a small amount of that ample white space to add labels. It might look something like this:
To me anyway, this is much more usable, mostly because it does not punish the seldom and/or first-time user. Plus, it only took a few more horizontal pixels to add the labels. As such, this solves the usability problem of not knowing what each label means by only adding a small amount of design-overhead to the page.
Of course, my way is not as contemporary as Google’s way, and if design aesthetic is of primary concern, then a minimal-only approach might be warranted. However, I, like most users, would argue for most applications, simple is always better.