top of page

< BACK

CVS Icons Library Revamp

May 2025 - November 2025

Problem Statement

 

An Icons Figma library of 400+ icons was created in Adobe Illustrator by the CVS Brand team in 2020 and shared across the entire CVS Digital Enterprise organization. The original Illustrator source files were impossible to locate at that time.

​

Over the course of several years, solution designers consistently reported issues with icon construction and properties. The icons did not meet engineering requirements, and as a result, the Pulse engineering team was never able to deliver a fully coded icon package.

​

At this point, the icon library had become a blocker rather than an enabler. It was time for a major overhaul.

 

Tasks

 

  • Create a unified icon template and establish icon guidelines (principles and creative direction)

  • Gather and compile technical requirements into a clear, actionable checklist

  • Align creative intent with technical constraints at a system level

  • Lead production for a large-scale library (400+ icons)

​

Game Plan

 

  • The icon creative process was led collaboratively by a Brand representative, the Pulse Creative Lead Designer, and a Solution Product Designer

  • Research, analysis, and technical requirements gathering were owned by me

  • Alignment across design and engineering teams was established to ensure production readiness and long-term scalability

 

Discovery

​​​

Before proposing any solutions, I needed to take a deep dive into what was actually wrong with the existing icon library.

​

This is a complete list of my findings:

  • Icon size variants were not set up correctly in terms of outline thickness, which resulted in proportional scaling issues:

    • Small variant stroke — 1 px

    • Medium variant stroke — 1 px

    • Large variant stroke — 1.5 px

  • Icon color was defined using raw HEX values, with no color tokens assigned. When an icon placeholder in a Pulse component was swapped with an icon from the library, the color token reference was lost.

  • Icons did not scale properly when resized, as aspect ratio constraints were not applied.

  • Icon size variants did not swap reliably, leading to inconsistent behavior across components.

  • Some “skinny” icons (where the artwork itself is narrow in width — a left- or right-facing caret is a good example) did not visually align well next to text labels. Because all icons used a square bounding box, the caret appeared too distant from the adjacent text. This broke the Gestalt principle of related elements being perceived as a group and weakened the visual relationship between the icon and its label.

Picture 1 Icon constrained to a 16×16 px bounding box. The resulting spacing breaks the perceived grouping between the icon and the link label.

Picture 2 Icon height is maintained at 16 px while the bounding box is trimmed to the artwork width, improving visual balance and perceived proximity to the label.

In addition, I researched external resources—including Medium articles and YouTube videos—to understand how other design systems approach icon library creation.

​

The most compelling example I found was Font Awesome. Their presentation at Figma Config, “We Drew 30,000 Icons in Figma and So Can You,” stood out in particular. It offered practical, system-level insights into large-scale icon production, governance, and long-term maintainability, and helped inform my thinking around process, tooling, and constraints at scale. 

 

Engineering Take 

​

I had conversations with Web, iOS, and Android developers to understand their expectations and technical requirements.

​

The Web Pulse engineer was already working on a system that uses CSS styling and sizing modifiers to scale icons programmatically. The main technical requirement was to have a single base icon that could scale up and down proportionally to generate different sizes—something that was not possible with the existing icon set due to the issues identified earlier.

​

His approach relied on a single SVG base icon at 16px, from which additional sizes (24px, 32px, etc.) would be generated in code. Icon color would be controlled via CSS styles and design tokens. He also emphasized that, for icons to work seamlessly inside Pulse components, they needed to be cut tightly to the actual artwork boundaries rather than being wrapped in a square bounding box. This would give engineers precise control over icon placement and its relationship to other UI elements within components. The Link component example illustrated this problem clearly. I made a note to bring this requirement back to the creative group.

​

Native platforms (iOS and Android) had their own approaches due to platform-specific constraints and would most likely continue to generate their own icon repositories. While having multiple repos was not ideal, we aligned on the idea that engineering would explore the possibility of consolidating them into a single source over time. The teams were committed to finding the most optimal cross-platform solution but needed additional time to work through the complexity.

​

I brought my discovery analysis back to the creative group to align our approach. Our combined findings led us to the conclusion that Figma was the best tool for building a new icon set that could support both creative intent and engineering requirements.

 

Team Alignment

​

It’s important to note that our icon team was not split into silos during the discovery phase. We were in constant communication, regularly sharing progress and key findings to maintain momentum. Keeping all involved parties informed was essential to avoid unnecessary work and prevent us from running in cycles.

​

For example, once I learned that certain icons needed a tighter crop to work properly within components, I brought this requirement to the creative team as early as possible. While researching the Font Awesome icon library, I came across an approach that I believed could solve this problem. I proposed creating icon component variants:

  • Regular (16×16 px bounding box)

  • Trimmed (16 px height with the artwork cropped to its actual width)

​

Initially, the creative team pushed back, as this approach would increase production effort and potentially slow us down. After several discussions and negotiations, we reached a practical compromise: identify the icons most commonly used within components and create variants only for those.

​

After extensive discovery and alignment, the team arrived at a clear game plan:

  • Figma is the right tool for creating the next-generation icon set

  • Engineers require a single SVG file per icon for their code repositories

  • Each icon will include all size variants to support ease of use and reinforce size standards within the Figma library

  • Select utility icons will include both regular and trimmed variants to work seamlessly within components

 

At this point, it was time to move into execution and focus on my deliverable.

​

Icon Technical Requirements Checklist

​Icon Size and Padding Variants

  • Standard sizes

    • 16 × 16 (small)

    • 24 × 24 (medium)

    • 32 × 32 (large)

  • Stroke

    • 1 px (small)

    • 1.5 px (medium)

    • 2 px (large)

  • For “skinny” icons paired with text, provide both regular and trimmed padding variants.

    • Trimmed variant

    • Frame height = 16 px

    • Frame width = actual vector artwork width

 

Locking Icon Aspect Ratio

  • Lock the icon frame’s aspect ratio to prevent distortion

  • Lock the aspect ratio of the icon vector and set constraints to scale horizontally and vertically (for square icons)

  • Lock the aspect ratio of the icon vector and set constraints to scale horizontally and vertically centered (for non-square icons)

  • Do not use auto layout for either the icon frame or the vector layer

 

Boolean Grouping and Naming

  • Convert final artwork into a Boolean group

This ensures the SVG exports as a single shape object—ideal for engineering workflows—while remaining fully editable in Figma, which is important for designers.

  • Name the vector layer consistently across all icons (e.g., “Vector”) to support smooth instance swapping

 

Vector Layer Color

  • Assign the theme-color-content-default color token to the icon vector layer

 

Component Naming

  • Name icon components in lowercase

  • Use dashes for multi-word names (e.g., arrow-down)

 

Icon Library Formatting

  • Break icon categories into separate Figma pages (in phases)

  • Move redesigned categories to new pages and mark legacy icons as deprecated

  • Name pages to match category names (e.g., the Utilities category lives on the Utilities page)

 

Design Handoff to Engineering

  • Pull 16 × 16 icon instances into a dedicated handoff section

  • Ensure all icons are set to export as SVG

Conclusion

​

What started as an icon cleanup quickly turned into a system-level problem. The existing icon set was heavily used across the organization, but it wasn’t built to support real product work or engineering workflows. Icons looked inconsistent, behaved unpredictably, and were difficult to implement reliably across platforms.

​

Through discovery and close collaboration with both design and engineering partners, I helped turn years of scattered feedback into clear requirements, shared principles, and practical standards the team could actually use. The goal wasn’t just to redraw icons, but to create a library that worked—visually, technically, and operationally.

​

This work laid the foundation for future scalability. The new structure supports programmatic sizing, tokenized color, predictable behavior inside components, and cross-platform adoption over time. Rather than solving isolated visual issues, the icon library became a stable, extensible asset within the Pulse Design System—one designed to evolve alongside the products it supports.

< BACK

bottom of page