This a really interesting and persuasive read for me. I've been thinking about this topic as part of brainstorming a simple design system and I had come to the conclusion that the inconsistency of not having icons for every menu item was a big annoyance. After seeing how descriptive the icons are in older menu examples compared to the abstract blobs in newer menus, I have to admit I might be wrong. At the very least, ensuring that the icons themselves are as illustrative as possible about the intended outcome of its selection is necessary.
It also makes me think about the classic Save icon: the floppy disk. That was certainly descriptive at its origination, but is it still so? In the age of natively storing documents in the cloud or copying to a USB drive, it seems like we might want more than one save menu or an appropriate icon for where the file resides on the single Save menu item. Microsoft Office has the Autosave toggle switch that serves some of this purpose, but it could definitely be better.
I also think about the Zune UI where sometimes a menu consisted only of the icons. How do you enable unique menu designs like Zune without icons for everything?
>It also makes me think about the classic Save icon: the floppy disk. That was certainly descriptive at its origination, but is it still so? In the age of natively storing documents in the cloud or copying to a USB drive, it seems like we might want more than one save menu or an appropriate icon for where the file resides on the single Save menu item.
It originated from when floppy disks were still widely used, yes.
Nowadays, people associate the icon of a floppy disk more with "saving locally" than the floppy itself. Changing it will just cause confusion.
Another example is how the icon for Database was chosen to resemble an old-timey stack of hard drive platters. Everyone knows what it means, even if your database isn't stored on HDDs, so there is no need to change it.
Even the telephone icon on your phone resembles an old-fashioned telephone horn, despite these getting less and less common.
I think local save is usually the floppy and cloud save is usually a cloud icon . The semantics change a bit when the app in question is a cloud app though.
> It also makes me think about the classic Save icon: the floppy disk. That was certainly descriptive at its origination, but is it still so?
This is a pet peeve of mine and it feels like some cargo cult within the UI design "field". There's nothing wrong with the floppy icon. It's perfectly fine. Even if someone doesn't get it, the consistency of its use across apps is enough for its meaning to be clear, which is what really matters.
> It also makes me think about the classic Save icon: the floppy disk. That was certainly descriptive at its origination, but is it still so?
It's a symbol, it could be a 7-pointed star and people would associate it with Save.
Even when you knew what a floppy disk was, why would you push that button? You haven't seen a floppy in years, don't have a floppy drive and don't want to create a floppy disk.
I always thought menus had icons so they could be matched to the same functionality on the toolbar. If a menu lacks an icon, then it's probably not on the toolbar. This falls apart when there is no toolbar. But I have definitely found an action in the menu, looked at the icon, and matched it to a a button elsewhere.
I changed the UX in my mobile app from text only to icon + text by default in menus, buttons, and links.
There are several reasons I made the switch, but the primary reason is that it makes it easier to build a kind of muscle memory for navigating and performing particular actions. In essence, the text is there for new users and the icons are there for experienced users.
I think the key in apples guidelines is the word arbitrary. A lot/ most of the icons in apples menus are purpose made for the menu item - so it’s not as big of an issue.
I think this is an example of the emojification of communication. I suspect that trend is being sustained, at least, by LLMs who are prone to abusing vapid emojis everywhere.
I think that to a certain superficial level of analysis, a matched set of icons looks "complete" and indeed impressive. Designers and implementers of the interface can fool themselves through customary use that they're creating a language of ideograms. Their users, who interact with their product only a few hours per week, only perceive visual noise and clutter.
This article made me realize why I always struggle to get through long documents generated by LLMs. The overuse of emojis doesn’t make it easier for me to find useful information, instead, it just adds a lot of noise.
I always took it as a plus for soft internationalization, e.g. we may not have translated or localized to the current user language, but icons area decent generic hint.
It's also very useful if you're dealing with both English and local language versions of the same software, as translations aren't always 1:1, but icons generally are.
From the article: "What I find really interesting about this change on Apple’s part is how it seemingly goes against their own previous human interface guidelines..."
Welcome to Apple of the last decade. As an avid user of many Apple products, this has been extremely frustrating to experience. Hopefully Alan Dye's departure will see at least partial return to obeying Apple's own HIG.
Have you seen any specialized software, e.g. AutoCAD by Autodesk?
In the top ribbon menu there are icons only. And not any familiar ones at all.
Icons, text representations of the action behind the menu items…
It's a designer hell in which you have no chance to please everyone. Like someone using a vim editor for 20 years... some people are using icons, other want text and the third group wants combination of both.
When only some things have icons, it's almost like a flag that these things are more special/useful/used. I think that is by far more useful than everything having an icon that you have to think about (or see the text next to it) to understand
The thoughtful inclusion and exclusion of icons in menu items builds hierarchy. When every item is special, none are. You've lost the ability to differentiate.
Icons everywhere is a hallmark to me of "webby" UI.
Over the years I've noticed something unusual about myself: I don't even see these icons. My brain goes directly to the text. This applies to all visual material, but is most evident in printed advertising.
Apparently other people notice the hot girl and the puppy and the fried chicken sandwich first. Meanwhile, I've already read all the fine print.
I used to notice and somewhat - but not solely - rely on icons, especially nice designed sets.
It seems though that a combination of samey-sameness (greyscale, shape, etc...) and the constant bombarding of attention-grabbing imagery (emoji, gif, ads...) has desensitised me from visual cues and I zero in on text instead now.
There was a comic artist I used to follow when I was doing more front end work, who would blog about his craft. One of the things he said that really hit me was talking about silhouettes. The visual noise in certain eras of comics make them very unapproachable. If you repainted your strip by flood filling everything with black, would people have any clue what's going on?
One of the things I'm seeing in some of these examples is icons with the same silhouette doing nothing or less than nothing for scannability. This is the same problem AWS has. Their dashboard is just noise, because the icons are neither visually distinct nor descriptive of the project.
I've also seen some of this same problem with card and board games as well. You can see that some designers care about accessibility. This type has both a distinct color AND shape so colorblind people can see it, all the icons are big enough that people can make them out sitting upside down in front of the person across the table from them, even if they're over 40.
His first example, Google Sheets, does well by this metric IMO, but the next few are kinda bad.
> You can see that some designers care about accessibility. This type has both a distinct color AND shape so colorblind people can see it […]
This is something visual artists usually learn and are good at and it's not primarily for accessibility, it's simply good design. Accessibility improves as a side effect.
> One of the things I'm seeing in some of these examples is icons with the same silhouette doing nothing or less than nothing for scannability.
I have this issue with Google apps on my phone. Once they decided that all icons should have the same four blurred colors with low contrast, you just can't tell which app you're looking at without the text label below. And I'm not visually impaired.
Not sure I agree. It's much easier for me to find the link icon than "Insert Link" in the Google Docs example. It's seem pretty close to a standard icon so, for me at least, it's helpful to find it. Same wit some of the others like increase indent, decrease indent, left, right, center justification, and lots of others.
I can also be helpful for non-English (or non-language of your choice) when you haven't had time to localize or don't have perfect localization. Let's assume the user has Japanese as their second language. It's much easier to find the option you want with icons than without
Just right-click any file in VSCode/Cursor to see how absolutely chaotic and tedious a long menu is without icons. Now imagine that Google Docs example without icons.
It’s much easier to recognize the funnel icon to make a filter, than to skim all that text.
I never noticed this but VS Code has almost no icons in menus. I'm fine with this though. We aren't supposed to use the menus all the time but rely on shortcuts or the command palette.
It has always been so since the dawn of modern desktops. I don’t see how/why this is noise. This is like a developer at a standup insisting we can make the app faster adding some micro services, flashy UX, and a few months of work while the - end user will still enter 20 order changes in an 8 hour day because that’s the environment.
There are so many reasons to add icons as many have already stated here. One reason i didnt see is for multi lang help. Sometimes the icon is enough when i dont know the language used.
However, i think what may be described here is that apps often deviate from a “universal” standard or reuse something to mean another. This defeats most of the benefits of using icons imo.
Wow. Icons in Menus are so useful that I absolutely didn't expect this article is to complain about them. They help me location the item I'm trying to click tremendously.
Come on, could we get back to hating Cloudflare or something?
> What I find really interesting about this change on Apple’s part is how it seemingly goes against their own previous human interface guidelines (as pointed out to me by Peter Gassner).
> They have an entire section in their 2005 guidelines titled “Using Symbols in Menus”
> Use text, not icons, for menu titles. Only menu bar extras use icons to represent menus. See Menu Bar Extras. It’s also not acceptable to use a mixture of text and icons in menu titles.
> Avoid using custom symbols in menus. People are familiar with the standard symbols. Using nonstandard symbols introduces visual clutter and could confuse the user.
The notable thing here is how recent of a shift this is, and how longstanding the prior rule was. Navigating internet archive is slow/tedious, but I think the rule/guideline was explicitly called out in the guidelines up until a year or two ago. So it was probably the guideline for ~20 years on macOS and has just now been changed.
From an accessibility/localization stand point, icons+text everywhere seems to be ideal.
Also, I disagree with:
> This posture lends itself to a practice where designers have an attitude of “I need an icon to fill up this space”
Sure, that does technically happen, but is in no way preventative or mutually exclusive with the follow on thought:
> Does ... the cognitive load of parsing and understanding it, help or hurt how someone would use this menu system?
That still happens, because if they mismatch an icon with text, that can result in far worse cognitive load/misunderstanding than if no icon was present at all. This becomes readily apparent in his follow on thought experiment where you show someone a menu with icons+text, but "censor" the text. Icons+text is also superior to [occasionally icons]+text in the same thought experiment. From my perspective, the author just argued against their own preference there.
I'd argue that the thought process behind determining an appropriate icon is even more important and relevant when being consistent and enforcing icon+text everywhere, not diminished. It also has the broadest possible appeal (to the visual/graphically focused, to the literary focused, to those who either may not speak the language, and/or to those who are viewing the menu with a condensed/restrictive viewport that doesn't have room for the full text). Now, if the argument is predicated on "We aren't willing to pay a designer for this" then yeah, they have a point. Except they used Apple as an example so, doubt that was the premise.
I used to manage a team working on the news feed at Facebook (main page).
We did extensive experimentation, and later user studies to find out that there are roughly three classes of people:
1) Those that use interface items with text
2) Those that use interface items with icons
3) Those that use interface items with both text and icons.
I forget details on the user research, but the mental model I walked away with this that these items increase "legibility" for people, and by leaving either off, you make that element harder to use.
If you want an interface that is truly usable, you should strive to use both wherever possible, and ideally when not, try to save in ways that reduce the mental load less (e.g. grouping interface by theme, and cutting elements from only some of the elements in that theme, to so that some of the extra "legibility" carries over from other elements in the group)
But also from an accessibility stand point, providing users with affordances to remove distractions (animations, transitions, and yes, icons) should be an option. But I disagree with the author that the default should be less icons.
132 comments
[ 2.8 ms ] story [ 79.6 ms ] threadIt also makes me think about the classic Save icon: the floppy disk. That was certainly descriptive at its origination, but is it still so? In the age of natively storing documents in the cloud or copying to a USB drive, it seems like we might want more than one save menu or an appropriate icon for where the file resides on the single Save menu item. Microsoft Office has the Autosave toggle switch that serves some of this purpose, but it could definitely be better.
I also think about the Zune UI where sometimes a menu consisted only of the icons. How do you enable unique menu designs like Zune without icons for everything?
It originated from when floppy disks were still widely used, yes.
Nowadays, people associate the icon of a floppy disk more with "saving locally" than the floppy itself. Changing it will just cause confusion.
Another example is how the icon for Database was chosen to resemble an old-timey stack of hard drive platters. Everyone knows what it means, even if your database isn't stored on HDDs, so there is no need to change it.
Even the telephone icon on your phone resembles an old-fashioned telephone horn, despite these getting less and less common.
This is a pet peeve of mine and it feels like some cargo cult within the UI design "field". There's nothing wrong with the floppy icon. It's perfectly fine. Even if someone doesn't get it, the consistency of its use across apps is enough for its meaning to be clear, which is what really matters.
It's a symbol, it could be a 7-pointed star and people would associate it with Save.
Even when you knew what a floppy disk was, why would you push that button? You haven't seen a floppy in years, don't have a floppy drive and don't want to create a floppy disk.
There are several reasons I made the switch, but the primary reason is that it makes it easier to build a kind of muscle memory for navigating and performing particular actions. In essence, the text is there for new users and the icons are there for experienced users.
1. Remove all icons from menus.
2. Make mouse-over do nothing - I should be able to move the mouse anywhere on the screen, and nothing should change colour/pop out etc.
I think that to a certain superficial level of analysis, a matched set of icons looks "complete" and indeed impressive. Designers and implementers of the interface can fool themselves through customary use that they're creating a language of ideograms. Their users, who interact with their product only a few hours per week, only perceive visual noise and clutter.
Welcome to Apple of the last decade. As an avid user of many Apple products, this has been extremely frustrating to experience. Hopefully Alan Dye's departure will see at least partial return to obeying Apple's own HIG.
In the top ribbon menu there are icons only. And not any familiar ones at all.
Icons, text representations of the action behind the menu items…
It's a designer hell in which you have no chance to please everyone. Like someone using a vim editor for 20 years... some people are using icons, other want text and the third group wants combination of both.
The thoughtful inclusion and exclusion of icons in menu items builds hierarchy. When every item is special, none are. You've lost the ability to differentiate.
Icons everywhere is a hallmark to me of "webby" UI.
Apparently other people notice the hot girl and the puppy and the fried chicken sandwich first. Meanwhile, I've already read all the fine print.
No idea why I'm like this.
It seems though that a combination of samey-sameness (greyscale, shape, etc...) and the constant bombarding of attention-grabbing imagery (emoji, gif, ads...) has desensitised me from visual cues and I zero in on text instead now.
One of the things I'm seeing in some of these examples is icons with the same silhouette doing nothing or less than nothing for scannability. This is the same problem AWS has. Their dashboard is just noise, because the icons are neither visually distinct nor descriptive of the project.
I've also seen some of this same problem with card and board games as well. You can see that some designers care about accessibility. This type has both a distinct color AND shape so colorblind people can see it, all the icons are big enough that people can make them out sitting upside down in front of the person across the table from them, even if they're over 40.
His first example, Google Sheets, does well by this metric IMO, but the next few are kinda bad.
This is something visual artists usually learn and are good at and it's not primarily for accessibility, it's simply good design. Accessibility improves as a side effect.
I have this issue with Google apps on my phone. Once they decided that all icons should have the same four blurred colors with low contrast, you just can't tell which app you're looking at without the text label below. And I'm not visually impaired.
I can also be helpful for non-English (or non-language of your choice) when you haven't had time to localize or don't have perfect localization. Let's assume the user has Japanese as their second language. It's much easier to find the option you want with icons than without
https://www.youtube.com/watch?v=z7kXUbwngB4
Somewhere in there, I think he does have a point.
It’s much easier to recognize the funnel icon to make a filter, than to skim all that text.
What will you gain from removing the icons?
However, i think what may be described here is that apps often deviate from a “universal” standard or reuse something to mean another. This defeats most of the benefits of using icons imo.
Come on, could we get back to hating Cloudflare or something?
> What I find really interesting about this change on Apple’s part is how it seemingly goes against their own previous human interface guidelines (as pointed out to me by Peter Gassner).
> They have an entire section in their 2005 guidelines titled “Using Symbols in Menus”
2005?? Guidelines evolve.
> Use text, not icons, for menu titles. Only menu bar extras use icons to represent menus. See Menu Bar Extras. It’s also not acceptable to use a mixture of text and icons in menu titles.
> Avoid using custom symbols in menus. People are familiar with the standard symbols. Using nonstandard symbols introduces visual clutter and could confuse the user.
The notable thing here is how recent of a shift this is, and how longstanding the prior rule was. Navigating internet archive is slow/tedious, but I think the rule/guideline was explicitly called out in the guidelines up until a year or two ago. So it was probably the guideline for ~20 years on macOS and has just now been changed.
Also, I disagree with:
> This posture lends itself to a practice where designers have an attitude of “I need an icon to fill up this space”
Sure, that does technically happen, but is in no way preventative or mutually exclusive with the follow on thought:
> Does ... the cognitive load of parsing and understanding it, help or hurt how someone would use this menu system?
That still happens, because if they mismatch an icon with text, that can result in far worse cognitive load/misunderstanding than if no icon was present at all. This becomes readily apparent in his follow on thought experiment where you show someone a menu with icons+text, but "censor" the text. Icons+text is also superior to [occasionally icons]+text in the same thought experiment. From my perspective, the author just argued against their own preference there.
I'd argue that the thought process behind determining an appropriate icon is even more important and relevant when being consistent and enforcing icon+text everywhere, not diminished. It also has the broadest possible appeal (to the visual/graphically focused, to the literary focused, to those who either may not speak the language, and/or to those who are viewing the menu with a condensed/restrictive viewport that doesn't have room for the full text). Now, if the argument is predicated on "We aren't willing to pay a designer for this" then yeah, they have a point. Except they used Apple as an example so, doubt that was the premise.
We did extensive experimentation, and later user studies to find out that there are roughly three classes of people:
1) Those that use interface items with text 2) Those that use interface items with icons 3) Those that use interface items with both text and icons.
I forget details on the user research, but the mental model I walked away with this that these items increase "legibility" for people, and by leaving either off, you make that element harder to use.
If you want an interface that is truly usable, you should strive to use both wherever possible, and ideally when not, try to save in ways that reduce the mental load less (e.g. grouping interface by theme, and cutting elements from only some of the elements in that theme, to so that some of the extra "legibility" carries over from other elements in the group)
Isn't it obvious? Because compared to "Settings" it is a far less important infrequently used setting.