Creating an icon library
A comprehensive guide
Why icons
The design team at Plaid has spent the second half of 2020 reinvesting in our foundations. We thought it would be valuable to reflect on some key learnings and share with our growing design team, as well as the greater design community. I chose to focus on icons given my personal journey with them while at Plaid. Plus, their nuanced layers of detail and unique ability to stretch team collaboration make them extra fun to deep-dive into.
Plaid relies on iconography as a core visual element across its user experiences. Icons provide intuitive usability for our users and enable them to easily navigate our site and products. Our icon library aims to instill confidence and clarity, while unifying experiences.
Dare I reach to say, our icon library offers bite size servings of delight? Of course, it wasn’t always this way. In fact, our history with icons was unsurprisingly complicated.
Ship it
With rapid design and development of new Plaid product experiences, we didn’t want to get hung up on the details of designing new icons every other day. Many projects were concepts meant to be tested, and iterated on frequently. We relied, instead, on a mix of out-of-the-box icon suites including SS Standard, SS Glyphish, and Streamline, depending on the use case.
Not it
So, we got hung up in other ways. What icon from which suite is most appropriate for which experience? Should we select from the limited SS Standard set, and begrudgingly ship an experience using an imperfect icon used differently on another screen? Or, should we spend hours digging through the overwhelmingly robust, yet dysfunctionally organized Streamline set, now boasting 30,000 unique vector icons?
Neither option was good.
This is aside from the obvious point that these icons weren’t constructed in a way that considered our type hierarchy or illustration system. We still had to size them once we placed them in our product experiences. They just didn’t fit in, and, in some ways, the clunky little buggers may have created a team-wide avoidance of icon use altogether.
We realized there were opportunities to improve icon use across our products and communication channels by investing in an icon library. At the same time, we could empower our team to use icons more efficiently and effectively.
Out with the old
We believed we were better off building a new library from the ground up than trying to patch up the dis-jointed icons we’d cobbled together. Aside from finding the best icon for the experience, we also would need to better define weight, size, spacing, padding, and filetype required for each instance. So, in four phases, we set out to create a better path forward.
- Phase 1: Audit (more thoroughly) icons in use throughout Plaid experiences, and anticipated to be needed in the near future
- Phase 2: Explore a generative range of styles and converge on direction based on contextual needs
- Phase 3: Define our rules to more efficiently reconstruct the icons identified in our audit and new ones as needed
- Phase 4: Organize a centralized library of all outputs, and share rock-solid documentation and guidelines for future contribution
Phase 1: Audit
The audit was conducted to understand how and where we were using icons. Aside from getting a sense of the total scope, we also wanted to get a better understanding of the patterns in fit and finish, where we were using the same icon to represent something different on another screen, and how we could improve metaphors in core user flows.
Specific steps of the audit
1 Plucking out icons from our different surface areas, including Plaid Link (our core product), our developer dashboard, our consumer portal, and plaid.com to name a few.
2 Labeling the icons with their intended use(s)
3 Grading how effective the icons were in communicating their intended metaphor and exploring potential icons that might work better
4 Comparing stylistic treatment like stroke weight, overall size, and color
Phase 2: Explore
As we moved from the audit into the exploratory phase, we established principles to help us better guide and evaluate our work.
Iconography principles
Accurate
Icons depict the content they represent intuitively
Simple
Reduce icons to the simplest form, and omit superfluous details unless necessary for aesthetic purposes
Global
Not dependent of American cultural references, icons are usable for everyone and country agnostic
These principles were developed as a team, and then shared with our contracted icon designer, Zach Roszczewski, along with a sample of core icons used across experiences to test different approaches. We examined the tests in context by creating symbol variations in Sketch. We then presented the variations to other members of the design team for their directional feedback before making a decision on what would become the skeleton for our icon system guidelines.
Phase 3: Define and construct
With our direction in place, we took a polish pass at the core icons used to establish our visual style and further refined key details to set us up for icon production. In doing so we defined our composition, strokes, and corner radius treatment. More details around these guidelines are included below.
It is worth noting we chose to use Illustrator as our production tool, due in part to its proven svg export quality, plus Zach and I were both most comfortable with the pen, pathfinder, and shape builder tools it offers. We’ve since migrated to Figma, but these guidelines still apply.
Composition
Artboards
In our audit and exploration we closely examined the sizing of the icons. We wanted them to be small enough to pair nicely with our body text and menu lists, but large enough to be distinguishable representations of the content they supported without being overly constrained on the inflexibility less pixels may cause. We landed on the following details:
- 24px x 24px artboards (aligned to grid)
- 2px padding all around
- Leaving a 20px x 20px live area to play in
We created guides based on geometry; created for optical alignment. We noted in some cases we can work outside of the guides, but never outside the live area. Sizing was determined as follows:
- 12px x 16px rectangular guides
- 14px x 14px square guides
- 16px x 16px circular guides
Containers
With the artboards defined we made sure to also include a layer called icon-container the same size as the artboard with null stroke or fill and sent to back. This is critical for maintaining grid adherence during export and for placement in designs and implementation. If not for this detail, svg exports would be sized according to their artwork size (variable based on the art of the icon) and positioned top, left (often off-set from the pixel grid).
Strokes
Stroke weights
Stokes are an important stylistic detail we wanted to make sure to do diligent exploration and testing on. For our system, we landed on a stroke weight of 1.5px. At first mention it seemed like a cardinal sin for an OCD grid stickler like myself. But in further examination and feedback sharing from the team, it really felt like the right choice. It fit nicely with the type it accompanied in most instances, where 1px felt too fragile, and 2px felt too chunky. Our solution felt like a sophisticated middle-ground.
[Optional geek out session]
The key to making 1.5px stroke weights work is to use the pixel grid lines for stroke alignment, instead of aligning edges of shapes to the pixel grid. Placing line segments and points directly on the grid allows for the distribution of the 1.5px stroke to be equally shared, centered in the span of 2px. In other words, instead of having 1 full pixel and 1 half-full pixel (which results in a light grey blurry effect when rendered) we would split the half-full pixel between the 2px span, making each side of the line segment .75px. Because this can be confusing, and you’ll probably never really grasp what I’m talking about without a visual reference, you can see examples of pixel previews for each scenario below.
Stroke details
Other stroke details we considered were the treatments for caps and corners. We decided to use square stroke caps flush with the edge of a line segment, also called butt caps in Illustrator. We also toggled align stroke to center and miter join for corners. The butt caps give us more precision and less blur for edges, and the miter join allows us to customize strokes using the transform tool with more control.
Corner radius
Rather than relying on the preset algorithm the out-of-box rounded corners effect offers in stroke settings, we defined our own. Rounded corners are set up to be 0.5px, Illustrator settings shown below. This allows for a square counter shape (negative space) and a rounded edge, for a subtle roundedness that echoes our buttons. We edit the corners as the final production pass since it can be somewhat redundant if still being generative in construction.
Arrow vertices
Arrows, chevrons, reset, and other icons using directional shapes use sharp pointed directional vertices. This detail helps reinforce the sentiment of precision to our developer audience, and is more closely related to the Plaid logo. Demonstrations shown below
Exporting
For best results while exporting, we used the export for screens option and unchecked the create subfolders checkbox to keep our library flat. Artboard grid alignment and the invisible icon-container layer play a critical role in ensuring intended positioning for the exported assets. If your assets export 1px larger than intended, it is likely because the artboard is not aligned to the pixel grid, or not positioned on a whole x or y coordinate value.
Phase 4: Organize
With the construction and production details in place we moved on to flesh out the next major pieces critical in creating a salable icon library; organization. In these regards, we’ll focus on nomenclature and mapping, specifically. While this section might not seem as sexy at the surface, organization is what unlocks adoption of the system we as designers work so hard in perfecting. Without thoughtful consideration in organization at Plaid, we could have ended up with some of the same problems we had sought out to solve.
Nomenclature
Nomenclature and organization go hand in hand. Really, how we name things is a key piece in any design and development collaboration, and icons are no exception. We consulted our development partners early on, since they would be implementing the icon system in our React component library for web based experiences, as well as iOS and Android for mobile experiences.
Together, we chose to name icons based on what they are rather than what they represent. For example, instead of naming the representation of a list used for transactions transactions, we name it list. This allows list to be more versatile, possibly used to represent a table, a list, or a transaction. If we find that we need more distinctive representation we can create more specificity in the art and name as needed.
With that being said, we’ve also made judgement calls for more ubiquitous icons. We decided using search and close would be simpler and more discoverable than magnifying-glass or x. While the logic can be somewhat blurry, shared consensus across teams is more important than striving for bulletproof theory. Ensure you’re aligned with dev partners by sharing libraries in dev tools like Storybook.
At Plaid we use lowercase letters and hyphens for all imagery (illustrations, icons, photos) in our design system. The hyphen may be used for names with more than one word or for variations. Some examples:
icon/arrow-left
icon/arrow-right
icon/bar-graph
icon/sidebar-hide
icon/sidebar-show
icon/trash
While this works for us, it’s not more or less valid than other ways of naming. Different platforms may require different conventions, and so we have to give in to the demands of the system requirements in iOS, Android, and React within their respected repositories.
To serve all platforms, you can either duplicate, batch rename, and re-export within Figma, or create scripts to get a similar result if you’re more technical. Because that’s not my expertise, and a bit of a rabbit hole, I’ll just end this section by acknowledging potential paths and leave it to my more savvy sidekicks to cover in a future post.
Mapping
Our icon library artwork originated in Illustrator, stored with an exported asset repository on Dropbox, was imported to our shared Sketch Cloud Icon Library, documented in Zeroheight + Storybook, added to our React component library, included in our iOS and Android development kits, and has since been migrated to our Threads Foundations design system in Figma –deep breath– all within the past several months.
This isn’t to say that every team could or should put their icons through this kind of tour, but making an icon library available for designers and engineers in the exact structures they require is bound to cause some dizziness, especially at a fast paced company. Setting up your icons to nimbly adapt and scale in multiple environments is the key to a successful icon library.
Below is a map of the current (transitional) state of our icon organization. Compare that to the map of our ideal state, where we are heading.
Archiving the original artwork for icons has proven to be valuable. We’ve maintained an archival icon library file in illustrator with all of the strokes intact from the beginning. If we decide to one day change our stroke weight or border radius, it is much easier to edit the archival art than reworking expanded art or starting from scratch. As we are migrating our design system to Figma, our sample tests have proven the archival imports remain editable with no quality degradation in their new home (YAY!).
For the Sketch library and shared assets, we kept a separate flattened icon library in illustrator, including outlined strokes and cleaner, combined shapes that allow for simple overrides. Less shapes usually means less fussiness in code from what we’ve experienced.
Since we’re migrating our design system away from Sketch, we can now construct, export, and share our Figma Icon Library in one place. If designers constructing the icons choose to use Illustrator, that’s okay, as long as they migrate the archival asset into our Figma Icon Library. Testing archival vs flattened exports out of Figma into code remains as a checklist to-do item.
By removing the two Illustrator libraries (archival and flattened) we drop maintenance costs while simultaneously providing one centralized source of truth in Figma. This, hopefully, will empower contributors to add to the library without additional friction, while there is no sacrifice in quality.
Cue the music
So, if you’re still with us, wish us luck while we round the corner of the last lap of our icon journey. We would love to hear from you and lend a helping hand if you’re stuck somewhere on your journey. We will likely post a follow-up more geared towards the magic of scripts for icons in development, along with a few other technical tidbits. Until then, friends, have a healthy and restorative end to this crazy year.
Special thanks to Elena Gil-Chang and Liana Dumitru for your thoughtful contributions to this article. Shout out to Oliva Luo, Rick James Chatas, and Jeremy Tribby for being amazing teammates in this journey.
Want to hear more from the Plaid Design team? Follow our Medium publication or Dribbble. Want to hear more from Plaid? Follow our Twitter, or our main company blog. Want to work with us? We’re hiring!
