All about icons: findability, creating, documenting

Michelle Chin
Michelle Chin
  • Updated

People frequently ask us, “How should we organize our icons?” As with most things in design–it depends! But we’ll cover what you should think of when organizing your icons and the information you should provide to help your team get what they need quickly.

Just another design problem

We tend to take things to heart when crafting our design system. It might feel like we can never develop the perfect solution or process because it’ll never be good enough. But taking a step back (and not adding that pressure to ourselves), icon findability is similar to how we solve findability challenges in the products we design. We can do this! (If it doesn’t work out initially, we can iterate on the solution.)

Understanding your user’s goals

With any design problem, we need to understand our user’s goals. In this case, our users are designers and developers. For this article, we’ll focus on designers. (Let us know if you’d like a follow-up article for developers!)

As a designer looking for an icon, their main goal is to find the correct icon to use in their design. If they can’t find what they’re looking for, they’ll have subsequent goals – finding an icon elsewhere or creating one from scratch. As a design system maintainer, the latter goals might give you anxiety because it can easily lead to icon library bloat and inconsistency. 

Occasionally, adding an icon or creating one for the library might be necessary. So as a maintainer, consider funneling designers through a findability process, where most scenarios are solved early on, and designers only funnel through the other goals when necessary.

If that’s the case, the goal funnel will look like this:

  • I want to find the correct icon to use in my design.
  • If I can’t find an icon and we use a third-party resource, I want to know how I can bring that icon into the library.
  • If I can’t find the icon in the third-party resource, I want to know how to create an icon to add to the library.
  • Lastly, I want to know what I can’t do to avoid making mistakes.

Finding the correct icon to use

Even in a limited icon set, finding the icon you need can be challenging. We recommend only including icons in your library that actually appear in the product. Anything extra can easily lead to library bloat, which makes it harder to find things, so people resort to making their own.

An example of icon grouping from DoctoLib's design system

An example of icon grouping from DoctoLib's design system

Organize your icons for findability

Icons are metaphors that represent actions, things, and statuses. Some examples include 

  • Actions - send, refresh, delete
  • Things - shopping cart, inbox, file
  • Statuses - warning, error, connected

When organizing your icons, we recommend organizing them by actions, things, or statuses. For naming, consider using the metaphor, or intent, they represent, not the object itself. For example, you would label the icon “settings” instead of “gear cog” and “save” instead of “floppy disk.” By using the metaphor/intent represented, designers are less likely to pick an incorrect icon. They’ll confidently know that the “settings” icon is for settings and the “save” icon is for the save action (also helping people young enough not to know what a floppy disk is 😳). 

Depending on your product portfolio and how much you’re trying to align across it, you could further break down the icons into subgroups. For example, within the “Actions” group, you have a group for each product. In some cases, it might make sense to start grouping by product first; then, in each product group, create subgroups for actions, things, or statuses. Again, depending on how much alignment and overlap there is, you could make additional groups based on the device supported (i.e., Web, iOS, Android, TV, etc.).

If you’d like some example of icon groupings, Salesforce’s Lightning Design System has relatively simple groupings, including things like Utility, Doctype and Action. Material UI, however, is a much larger iconset, so their categories are more specific. What works for your design system is probably very specific to your needs. To figure out the right IA, you could run workshops with users to group sample sets of icons together to find the most logical groupings.

As you determine groups and subgroups, ask yourself the following:

  • How many products does your design system currently support? And is there a plan to create more products, support more devices, etc.?
  • Do the teams that support these products work on multiple products, or are they more siloed? If they’re more siloed, it might be OK to keep things separated. If they work across multiple products, it might be better to keep them in one file for easy access.
  • How aligned are your products supposed to be? It might help to have one central set of icons if you're working toward alignment. Then you can create subgroups for icons unique to each product.
  • How frequently is each icon used in the product(s)? You could arrange icons by frequency of use to make things easier to find.

Mirror your library and documentation

Whichever way(s) you choose to organize your library in your design tool, mirror it in your documentation. This includes keeping your naming convention consistent for groups, folders, and component names (having consistent naming conventions for your design system is important). Mirroring the structure and language will make icons much easier to find.

Document usage nuances

In your documentation, note any usage guidelines, which can include:

  • When to use outline vs. punch-out style icons
  • When to use smaller or bigger-sized icons
  • When not to use specific icons

On occasion, there might be icons that products can only use in specific circumstances, which means they’re off-limits to everyone else. For example, one product might have permission to use a third-party logo for an integration, but all the other products aren’t allowed to use it. In this case, you could have a “reserved” section and denote this clearly in your documentation site.

A screenshot of Doctolib's icon usage guidelines from their design system documentation

An example of how to document your icons from Doctolib's design system

Adding icons from a third-party source

Depending on your icon needs, your organization might use icons from a vast repository (Think 100K+ icons!). There’s no way you can or should put all of these icons in your design system’s icon library - no one would know where to find the right icon, nor would the files open promptly (or if at all!). 

This is why we recommend only adding icons into your design system that actually appear in your products. When designers can’t find what they need in the design system, they can search for a new one to bring in. Icon repository sites usually have a robust search engine that allows users to find icons quickly.

Create a vetting process for adding icons to the library

We recommend having some vetting process for adding new icons. The process doesn’t have to be complex, but it should consider the following:

  • Is an icon the right tool for the job? Sometimes a concept is too complex to be boiled down to a simple icon.
  • Does the icon need to be added? Sometimes an icon for the metaphor they need already exists. 
  • Who’s responsible for vetting the icon? Is it the maintainer team, one or two specific individuals?
  • Does the icon need to be altered? Depending on the icon source and your design process, the icon might need to be adjusted. In our experience, we’ve found that icons might not be centered, use strokes instead of compound paths, or aren’t consistent with your system’s icon standards.

Considering these factors, try to keep the process simple and efficient, so designers don’t create rogue icon libraries to skirt the process.

Creating new icons for the library

Similar to adding third-party icons to your library, there should be a process for creating icons. This doesn’t have to be complicated, but you should consider the following: 

  • Does the icon need to be created? Is there another icon that represents the metaphor? Sometimes we’re quick to add things to libraries, but through a design critique or casual conversation, you might find an existing icon is sufficient. (Not to mention, your product’s users can benefit from the consistency!)
  • Who determines if an icon should be created?
  • Who is responsible for creating the icon? While it might seem easier to delegate this to the designer who wants the icon, this can be a unique skill set. At the very least, there should be some quality check before adding the icon to the library.

If you want more detail about how to create the icon itself, we highly recommend the book The Icon Handbook by John Hicks. Not only is it incredibly thorough and useful, but it’s also a gorgeous coffee table book!

Create guidelines for icon design

Guidelines can help ensure consistency for icon creation. We recommend including information about 

  • Sizes
  • Styles - e.g., outlines or punch-out
  • Line weight
  • Layer setup
  • Naming conventions
  • File format for output - eg. do the icons need to be vector? Do they need to scale? Are they to be included as part of an icon font?
  • Design tokens or color styles to use

Guidelines for creation don’t need to be complicated. Giff Gaff and Bold are two great examples of simple, concise guidelines.

Pilot your ideas

Once you come up with some solutions to grouping, naming, design guidelines, or vetting processes, run them by teammates. Try some usability testing to see if they can find icons. Also, check if processes resonate with them and are fairly frictionless. Based on any feedback, iterate and test again if necessary.

Set expectations in your documentation

Having good supporting documentation is just as important as having a method to organize your icons. As you group and organize your icons, document information, including:

  • The thought process behind the organization method and any naming conventions
  • The vetting process for adding icons to the library
  • The vetting process for creating icons
  • Guidelines for icon creation
  • Anything your team should avoid doing
  • Ways people can reach out for questions or help

Pro tip: when writing documentation, keep it concise and informative enough that any new hire can understand the process. Also, include visuals to make the information easy to understand and process at first glance. 

Let us know how you’ve organized your icon library!

We’d love to hear from you if you try this or have used other ways to organize your icons. Let us know what’s been helpful for you and feel free to share screenshots with us. We love geeking out about icons and organizing them! Join our community on zheroes, or hit us up on Twitter!

Was this article helpful?