I deal with a lot of legacy interfaces with brightly colored icons and they can be just as confusing if not more confusing than minimalist icons. But I think people have a survivorship bias (we remember the good examples over the bad ones), as well as a familiarity bias (I like the things I grew up using!).
I think the benefit of flat, monochrome designs is that they force you to offload meaning into the layout and flow of the application. You actually have to pick out a nice, meaningful spot to put the button, and make sure it makes sense in the context, and make sure users can discover it easily. Compare that to an open source application that just throws a bright green plus sign at the end of a row of icons and expects you to know what it does.
> I deal with a lot of legacy interfaces with brightly colored icons and they can be just as confusing if not more confusing than minimalist icons. But I think people have a survivorship bias (we remember the good examples over the bad ones),...
I don't think anyone's disputing that you can do colorful icons poorly, but that's not an argument against them as a concept.
> ...as well as a familiarity bias (I like the things I grew up using!).
One of the cardinal sins of modern UX is fixing things that aren't broken, often just as you were getting used to the last "fix."
> I think the benefit of flat, monochrome designs is that they force you to offload meaning into the layout and flow of the application. You actually have to pick out a nice, meaningful spot to put the button, and make sure it makes sense in the context, and make sure users can discover it easily.
Nothing's stopping a designer from doing that with colorful icons.
I think the real reason for flat, monochrome icons is designers prioritizing the overall visual look/style of an application over its usability. It's almost like a less extreme version of designing a "computer interface" for a movie.
I would argue that we are not "fixing things that aren't broken". Technology is being adopted by more and more people. It should make sense that we find ways to make improvements to reach more and more users. I think software people run the real risk of designing interfaces only they like.
I'm currently dealing with software that uses old style icons and menus and users just thoroughly do not understand the interfaces. The problem is that when every icon is brightly colored and bold, none of them are meaningful to the user. They all look equally important even when not.
We're finding with flat, simpler icons we have a lot more control about making certain icons more important than others. We can still give them color! And it will be more meaningful! We can make them pop out when we need to!
> I would argue that we are not "fixing things that aren't broken". Technology is being adopted by more and more people. It should make sense that we find ways to make improvements to reach more and more users. I think software people run the real risk of designing interfaces only they like.
What I meant by that comment is redesigning interfaces for aesthetics reasons: skeuomorphism is out, now skeuomorphism is in, now it's out again. Whitespace is out, whitespace is in. Google has a new icon set out so now our icons are "out of date," etc.
Furthermore, there are real costs to obsoleting users' expertise with an existing interface, and those costs may not be outweighed by marginal improvements in a new design. Also expert users and beginning/casual users have very different needs, and I think there's often too much focus on beginners.
> We're finding with flat, simpler icons we have a lot more control about making certain icons more important than others. We can still give them color! And it will be more meaningful! We can make them pop out when we need to!
And that totally makes sense and I agree with it. What I disagree is rejecting color and depth in an interface for reasons of aesthetics, ideology, or fashion.
It is interesting. I will need to check sources (Samir Zeki's vision book is amazing), but color detection happens way sooner in the v2/v3 region than symbol interpretation which is a higher level function. This is why stop signs are red, traffic lights are not icons (even if distance wasn't a concern, icon based traffic lights would take too long for human vision system to process). Evolutionarily, certain colors such as red indicate threat, injury, decay or food (blood) and we're hardwired to detect it effortlessly and within 100 ms or so. Before the interpretation (v4/v5/limbic system) happens. Baring color blindness concerns, monochrome iconography is objectively worse in every way except for the reasons I'll discuss below.
If you study mission critical systems, even a fork lift, colors are everywhere. EMO button is red. CNC control panels have lots of colors.
The reason why we use flat symbols (recylcing symbol on a milk jug, hazard labels on chemicals, bathroom symbols and airport signs, and road signs) is a practical consideration about printability and ease of application (single printing ink, stencils ), color fastness in the sun, etc. It's not for the reasons you're alluding to, although some of those concerns are orthogonally valid - layout should be logical and flow should be intuitive. Color icons are far superior, if someone can publish a scientific study, I would bet on it with real money. They might be ugly, not against brand/identity/etc. but I am strictly speaking of their utility.
But you can do colors with icon fonts! In fact, one of their benefits is that you can do context specific colors. So only have things be red or green when it's most meaningful.
I think the problem is in having all icons be bright and meaningful all the time - too much visual information can be worse than too little.
I guess I don't understand this critique because with a monochrome iconset, I can style them to have the semantic color that's relevant at the time.
A dangerous or destructive operation can be made to be red, to indicate the danger of the action.
A primary action that I expect the user to do can be made a primary action color.
If the icons are _built_ with color, then I can't change the color based on the semantics of how the icon is used. If you give me a monochrome icon that I can style, then I can match the color to the placement and functionality of the icon.
So, yes, _in the application_ the icons shouldn't be monochrome. But in the _iconset_ I would generally prefer they be.
> But I think people have a survivorship bias (we remember the good examples over the bad ones)
Exactly! Survivorship bias is great, we get to only pick the examples that we know were good enough to survive! Why on earth would we want to have a truly random sample that gave us a whole bunch of terrible icons we'll ditch within 3 years?
I also think that "instant universal recognizability" is only one potential reason to use icons, and a fairly limited one. It's also great to have fairly abstract icons in a particular application that are used consistently within that application, so that people can use them as a mnemonic.
I deal with a lot of legacy interfaces with brightly colored icons and they can be just as confusing if not more confusing than minimalist icons. But I think people have a survivorship bias (we remember the good examples over the bad ones), as well as a familiarity bias (I like the things I grew up using!).
I think the benefit of flat, monochrome designs is that they force you to offload meaning into the layout and flow of the application. You actually have to pick out a nice, meaningful spot to put the button, and make sure it makes sense in the context, and make sure users can discover it easily. Compare that to an open source application that just throws a bright green plus sign at the end of a row of icons and expects you to know what it does.