The ‘icon’ic story
At the beginning of my career, I worked at a young tech startup focused on building a web platform for designers. Like any bootstrapped startup, resources were incredibly tight, so I was always looking for ways to optimize speed and efficiency in our workflow. My role was to design experiences while being mindful of these constraints.
One day, a developer colleague pinged me asking for an icon. He already had the icon in PNG format but needed it in a different size. That was the first time I learned we were using PNG icons across our platform — a practice established before I joined the team. This approach had numerous issues, including scaling, asset size, and accessibility.
Over the following week, I worked with our team to replace every PNG icon with SVG. Up until that point, any icon the team needed was either downloaded from the internet or created bespoke. For custom-created icons, the editable version was discarded once the icon was shared with the developers. This meant I had to hunt for deleted assets in the recycle bin or redraw them (which was the more common scenario). It took some time, but I got it done.
Now, as far as icons are concerned, SVGs are a great replacement for PNGs because they were lighter in size, could be infinitely scaled without pixelation, and could be resized or recolored directly in the code. For me, this meant I wouldn’t be asked to provide the same asset in different dimensions and colors, unlike with PNGs. However, since we were always pushing for speed, we often created something quickly, shipped it, and then updated it as needed. Using SVGs directly in the code meant that if an icon needed updating, the developer would have to hunt down every instance of its use and update it — a process that wasn’t scalable at all.
A more sensible approach was to store all assets in a central repository and ‘call’ them whenever needed, just like PNGs. So, I created a repository on AWS (the cloud service we used) and uploaded all the icons we had in SVG format. I devised a scalable naming convention that the dev team agreed upon. However, we soon realized that even the most well-thought-out naming system isn’t foolproof. For instance, what I called a ‘hamburger menu’ icon (☰), a developer might search for as ‘three lines’ or ‘horizontal bars.’ Since there was no thumbnail preview in AWS (not sure if they’ve added it now), the developers had to rely on the name alone.
At that point, I taught myself to code in Angular (based on recommendations from my developer friends) and took it upon myself to create a visual catalog of the icons in the repository.
That internal tool helped developers find assets faster and more efficiently. However, we soon encountered a new issue.
When SVGs are used directly in the code, they can be modified to change color, size, etc. But when you store them in a repository and ‘call’ them, they are imported like images, meaning you can no longer change the color of the asset. It felt like we had come full circle, as I was again being asked to create the same icon in multiple colors. It was disappointing. We also considered using an asset management tool, but nothing fit our budget.
I was convinced that this problem wasn’t unique to us and that someone else might have already solved it. I just needed to find that solution. One day, while reading a Google Material blog, I came across the term ‘glyph-icons.’ It was a eureka moment because it was the perfect solution I was looking for.
The idea is that if you create a font where alphabets and symbols are replaced by icons, you can use icons in the same way as text. This approach allows you to use icons wherever you can use text. You can change the size and color of the icon and apply most of the properties applicable to a text element. This was something Material did too. It seemed like the perfect solution — except that no one around me knew how to create one.
It took me months of Googling to figure out a good way to create my own icon font. It wasn’t easy, especially for a non-developer like me, but I eventually cracked it and wrote down the steps for my fellow designers in another Medium article:
This solution wasn’t perfect — no solution is. I’m aware of potential accessibility considerations and some alignment inconsistencies. However, after carefully weighing the pros and cons of all available options, this approach best suited our team’s needs at that stage. As a final touch, I updated our icon catalog to visually present the icons with their associated symbol codes, leveraging glyph icons. This allowed developers to easily copy and use the icons, further streamlining our workflow.
Looking back, I see this project as one of the key achievements of my career. It taught me the importance of continuous improvement, team collaboration, and the balance between ideal solutions and practical constraints. While we didn’t achieve perfection, we significantly enhanced our process and made it far more efficient. This project pushed me to go beyond my capabilities to improve how we worked. And, I never received another icon modification request after that.
