What Is the Best Approach To Minimalist Buttons (Icons)?

Question

My web app, like most, is trying to utilize as much space as possible by trying to use an icon as a button to perform specific tasks. I have quite a few that would make for a pretty obscure button, such as "mark as hidden". I can come up with icons that make sense if already know what you're looking at/for.

I have two problems with this approach:

1. To figure out what a button is, the user either has to:

   • [Mobile Devices]: Click the button and hope it have any adverse effects.
   • [Desktop]: Hover over the element which is acceptable, but doesn't allow for quick recognition of features. (This is on the lower end of my focus)

2. It forces users to become intimately familiar with your app. I realize any complex application will force users to do some learning to take full advantage of every feature, but it's my experience that users want to be able to play around with the basic functionality right off the bat.

Answer 1

I really like what Facebook and other online apps do when showcasing their features... They have a balloon with a description pointing to a button and invite users to click through the app (if needed) with a delimited and evident number of steps... Meaning, they will showcase 5 use-cases and they make you click on it. This is a one-time only feature... Once you've clicked is gone. Some games did the same, World of Warcraft, and Warcraft III had it.

Answer 2

This can be tricky.

What I've done is follow a simple rule: If it's not readily apparent what an icon might do, don't allow it to do anything permanent or drastic in one click. If you think a user might not be able to tell what an icon is going to do, bring up a menu for the user or at least make sure wherever they're headed it's both 1) easy to return to where they were, and 2) not going to alter or change anything just because they went there.

Some examples:

Menu probably needed

• Envelope icon: Okay, so you're sending or sharing or something, I get the idea. But sending or sharing what? And via what? This one probably requires some sort of menu, even if it's a "Share this via email? Yes No" sort of thing.
• Gears icon: So it seems like some sort of settings or something? That's a menu. Or you could just take them to the settings area, as long as they're not going to permanently alter anything just by going there.

No menu necessary

• Trash can icon: just about everyone knows what this is going to do, delete something. So (probably) no text necessary. (You still probably want a confirm on a delete, though, so maybe this is a bad example).
• Edit Pencil: If you have an edit pencil on a screen or in an area where there's only one thing it could be editing, it's probably okay just to take the user to the edit form on the first click.

Fuzzy ground

• Plus sign icon: Okay, depending on the app, this might not require text, but what if there are multiple things you can add? Then you might need to menu to choose what to add.

EDIT: Another thing to consider for usability's sake is the idea of having a dialog that warns them what the icon is about to do with a checkbox to suppress further warnings. Depending on what you have the icon doing and how frequently it's used. You don't want to hassle your experienced users.

Answer 3

My general rules are below.

1. A icon should be so universally recognized that it could appear without text.
2. Despite being universally recognized, icons should not appear without text.
3. Make icons as easy to perceive as possible. In addition to using universally recognizable conventions (see Point 1), make icons two-dimensional.
4. Each icon should distinct. If you're going to use variations of icons, they should still be instantly distinguishable.

Answer 4

here is my suggestion

• keep your icons simple and visually appealing , make sure you use the most common symbols(icons) so that users could easily recognize what their functionality is. If not simply disperse the idea of using icons
• Help feature - provide a help feature which documents the UI functionality for the users to use, especially if you have relative new ideas. (you can include a feature as told by @edgarator also)
• absense of icons doesnt necessary take much of UI space, best example is this UX.stackexchange site. Hence, use links, labels etc.
• users will take their own time to recognize new features and functionality in any new application. Hence, their is nothing much we can do about it, except to put our best effort in designing UI as simple as possible.

Answer 5

I would accompany each icon with a label. If you track interaction, you can monitor users as they interact with your app and become familiar with the icons associated behaviors. Reduce the size and/or contrast of the labels gradually, then remove them entirely.

Answer 6

My simple suggestion:

1. Use icon only if it's a standard icon. Examples: "x" for close, "<" for back, "+" for add, "trash can" for delete, "floppy disk" for save, etc.

2. Use icon and label if it's an action specific to your app. Example: "eye" with "Mark as hidden" text.

Answer 7

When you are removing text as a visual cue for a user you are taking away a very clear way of communicating what a control does. Because of this there are two things that you should consider when designing your icons:

Firstly you need to keep control over your metaphors. Interactions in software that are similar to real world interactions with objects or common interactions with software need to bear a very close resemblance to how those things behave, even if the underlying processing is very different. A couple of metaphors with physical world objects demonstrate this: the trash can icon on a desktop operating system, it is something where you put rubbish in both the physical and software context; and the email icon, as in both the physical and software world you send a mail.

The thing to watch for here is an icon that implies that extra things will happen, or a software process that requires extra action from the user. A contrived example would be if email needed to be synced on the receiving device in order to be displayed. The extra step messes up the metaphor.

Secondly, you need to ensure that the actions performed reflect what the user expects the application to do when they click the icon. As an example I can propose a potential mistake: using a trash can icon within an application which deletes the highlighted content for example. The metaphor itself would be a reasonable one, but the result would not be what the user would expect and that would make the interaction frustrating.

Finally, context is again very relevant, you may find your user group expects different metaphors and behaviour from different actions based on the real world situation which has led to them requiring the app in question. A specialist set of use cases may result in a different group of icons than a general set.

By thinking like this you can minimise the friction for users who are looking at icons without immediately obvious labels and hopefully get some instinctual responses from users and fast learn times.

I would not remove labels altogether though, there are some good suggestions in other comments like to enable and disable labels.

Answer 8

The perfect-for-the-user strategy would be to provide a learning-wheels design where the buttons have both a label and an icon, and a second design with only icons, and let the user switch between them. From an engineering perspective, I would not go this way, because of the cost and complexity of maintaining two parallel designs.

But you can still implement a learning-wheel version with drastically reduced effort. Just dedicate a portion of the screen to a list of the icons together with an explanation (can be longer than what fits on a button if needed, but try to keep it as short as possible), and make this portion hideable. Yes, you are giving up valuable screen real estate for that. But your newb users will be glad to have the help, even if they don't get the efficiency afforded by enough screen space (they are inefficient yet anyway), and the expert users will keep the thing constantly hidden, and appreciate the minimal, memorable interface left over. In most cases, the bottom part of the screen is probably appropriate, unless you have a tiny landscape-oriented display (phone), but be aware that first side-by-side window managers are appearing in the phone world too.

Note that this approach works best for the case of an app with few buttons and a usage profile where the expert users use the application frequently. Else, you might want to drop the whole idea and stick with labelled buttons. The second reason is straightforward - if you are writing a personal tax software, your loyal users will open it once per year and need the explanations permanently. The first reason is somewhat blurrier. If you are writing a complicated software system with dozens of buttons, not even your experts will want to remember all these icons (and besides, the learning-wheel explanation list will need lots of scrolling or search, drastically reducing productivity). But nevertheless, many big names in this situation opt for the icons-with-tooltips solution, just because there is nothing better. This type of application tends to have a huge learning curve anyway (think MS Word, AutoCad, Photoshop) where finding the appropriate button is a small concern compared to knowing what is the right way to do something.