Tips for Icon Usability

If you’re considering using an icon in any of your designs, here are a few tips to ensure good icon usability.

The first thing is that you always need a text label. A text label is really needed to clarify the meaning of an icon because universal icons are rare and further. Some icons are used in multiple different ways on different websites and apps. And so when users encounter an icon, they can’t be sure that any single meaning is going to be the right meaning for that context.

You should also design icons to be schematic and not realistic. You want to avoid adding too many visual details because this adds to our visual processing and slows users down when they’re trying to determine what that is. So you need just enough visual detail to ensure that you captured the essence of that object and that’s recognizable to people.

By minimizing the amount of visual detail in your icon design, it not only reduces that visual processing, but it also helps your icon scale more easily. And that’s important as we’re designing for a ever increasing number of devices and screen resolutions. If you’re going to use that icon as a way of differentiating between certain things, say items in a list on an e-commerce site, for example, you want to vary both color and shape. If you rely on something like color alone, you run the risk of failing. You’re color blind users. And also color is more ambiguous because people may not be sure what that color is really supposed to mean. If you’re, of course, using that icon and something more like a toolbar or a menu, you can go ahead and introduce that visual clutter and maintain a consistent color.

Just ensure that you’re using a unique shape that has a good information set. When you’re trying to come up with your design for that icon, consider adopting a five second rule. And no, I’m not talking about that sad piece of cookie on the floor. What I mean is if it takes you longer than about five seconds to come up with an object that would represent that idea or concept, then it’s less likely that your users would see that design and associate it with that object. There maybe just isn’t a visual that strongly associated with that concept or idea. And of course, you always need to run a usability test with your users. So test your icons for recognition as well as information set. So show users these icons out of context, just the picture on its own without a text label and ask if they can figure out what that object supposed to be. That’ll show how well your design actually made that object recognizable and further ask them if they can decipher what might happen if they were to click on that icon in a certain context, say if they’re on their account page for a banking institution, what might happen by clicking on that graphic? And again, that just shows if they are able to associate that image or graphic with some sort of functionality. Right. Or whether or not it has a good information sense. So the next time you’re designing an icon, remember these tips in order to ensure that that design is going to be as usable as possible for your users.

The people responsible for design and user research usually report to either a centralized UX team, a product team or a hybrid of these, there are clear benefits and drawbacks to doing you under any of these with a centralized UX group, there’s a UX manager and you people report to him or her, and the practitioners work on the various products and efforts as needed, basically as consultants. Common benefits of a central UX team approach are a UX manager or executive level person is highly invested in UX and he or she understands the discipline that person can describe, champion for and defend you X and B the budget and resource custodian. Also, in a central UX team, individuals gain a wide breadth of knowledge about the various products that the organization and often connect product teams who otherwise would not work together. View X team shares design and research intelligence and cultivates UX expertize, processes and growth. There are drawbacks to having a centralized UX group like if the central group is also a chargebacks center, UX is tasked with not only convincing teams to do X, but also with paying for it. Another drawback to a central U.S. team is that product teams can forget that UKCS resources exist and are available and they may not involve you and planning and other important meetings. The foil to a centralized UX team is a decentralized UX team, or you reporting directly to a product team and a decentralized model. The product team has budget and you work comes from that budget. Advantages of a decentralized model are that UX is part of the team. So there may be more trust, more opportunities for you people to become expert in the product and demonstrate that and higher chances that the product team will involve you at the right time. But if the product team has low UX maturity, a huge weakness of a decentralized UX model is that it’s very difficult for one or two people to hold their own against many developers and other team members. In these cases, selling, convincing and educating can take most of the UX team’s time when they should be spending that time doing research and design. Also, rarely is there infrastructure that makes it easy for you X people to do research and design activities, so they need to create everything from scratch. Now, a hybrid of the centralized and decentralized UX models is a Matrix UX team in which you X people report solid line to the Central X group and dotted line to the product team or vice versa. A disadvantage to a Matrix arrangement is that you people can sometimes feel pulled in multiple directions by two managers. But this can also be the greatest matrix advantage as two managers may take responsibility for that individual success and thus the success of you in general. Other advantages are that the person stays with the same product team for some amount of time, so the team members think of her or him as part of the team. A Matrix UX model provides the best of both the centralized and decentralized worlds as long as the team leader and product leader are in sync with their UX goals.

When we are doing usability testing, we are hunting for usability problems, trying to identify the design flaws that need to be improved. This is very similar to information fighting theory, which says that the way humans search for information is similar to the way that wild animals hunt for food in nature. So let’s take an example. We have a forest with a lot of rabbits in it, and there is a two areas, patch A and Patch B, and in Petchey, let’s say there are four rabbits and in pet B there two rabbits. Where should the fox gone? Hunt. But clearly the fox will go and hunt and petty with this more game.

Now, after a while, they say that the fox has caught and eaten three unfortunate bunnies and as one lucky one left and there’s two over here, what should the fox do? Keep hunting that last rabbit here or go to the rich hunting grounds? The fox should go to the witch hunting grounds. And that’s a fact, in fact, what biologists find when they study these things. Similarly, when we are doing our usability studies, we should not hunt to extinction every last year to build a problem in version one of our design.

Rather, we should stop after a while, typically after five test users and say we’ve found a lot and now it’s time to move to richer hunting grounds, which in our case will be version two of this design custom version two. That’s going to be a lot of new things. More rabbits for us to discover because we have hopefully identified and removed a lot of the showstoppers in version one of the design, meaning that users can now engage more deeply with the user interface, do more interesting behaviors, and that leads us to discover new, interesting usability problems. Also, I said that we were going to fix legibility problems found in the testing, the first design. Now, sometimes what you think is a fix is not a fix. And the problem remains other times in making an improvement in one area, you introducing a new usability problem in another area. And that is something that we can then find in testing version two. Lastly, in terms of usability problems in a usability problem that was present in version one that was not found and therefore not fixed, will still be there in version two for us to discover. And that’s one case where we’re kind of like better off than the fox because any rabbit that was surviving in Petchey is not going to follow the fox over to Pet B and be hunted there because only a suicidal rabbit would do that. So we are better off than the foxes, and that means even more so. We should follow this principle of not hunting to extinction in one area when the other things we can do and spend our resources that will lead us to better prey or to better results.

Leave a comment

Your email address will not be published. Required fields are marked *