Icons

Open sourcing the design process

As the lead designer, I created a cohesive iconography style that could be seamlessly applied across our various products and platforms.

Background

VS Code’s iconography originated as a fork from Visual Studio, the sister product of VS Code, and had evolved over the years to include third-party icons from GitHub (Octicons).

This introduced a lot of inconsistencies as there were different styles, weights, and colors. Our customers started noticing these inconsistencies, and there wasn’t anyone actively maintaining our icons. I led the initiative to begin cleaning up the iconography and creating a cohesive style that fits across our platforms.

Iterations

After getting leadership onboard, I partnered with our visual designer to create several variations of styles we wanted to explore that matched our product branding. We explored a wide range of styles from solid and outline to rounded and playful. Below is a preview of our first rounds of iterations.

As we narrowed down the styles, we knew we needed to get customer feedback for this to succeed. In embracing the open-source culture, we opened the design process and invited the community to participate and provide feedback. We were surprised at what happened next.

Better feedback

As we went through the feedback, we realized it was great for first impressions, but we wanted to get these into our customers’ hands to see how it would impact their workflows. So I created a custom build of VS Code with the new icons and asked our community to try them out. The community continued to surprise us by being active build testers and providing more feedback.

Once our customers had a sample build, we started receiving a flood of feedback, which felt amazing and terrifying. There was feedback around first impressions between the solid and outlines, glitches we missed, and even other areas needing updating. We worked around the clock to update the build as we iterated on the feedback.

Shipping it

After several months of iterating on the new icons, we finally shipped them and set them as the default. We did a lot of back and forth trying to determine which icons to use, as the feedback was very split. After several tests, we landed on the outline version because it resonated with most of our users and looked more “modern.”

Automating it

Once we updated the icons, we also wanted to update how icons are referenced in the source code. I created a command line interface (CLI) tool to auto-generate an icon font from our svgs. We named the icon library Codicons, paying tribute to our previous icon library (Octicons).

Open sourcing it

Once we shipped the icons, I knew it was time to give back to the community and open-source them, which Microsoft hadn’t previously done for design. So we published microsoft/vscode-icons on GitHub, published them to the Figma community, and created a plugin for Figma.

Impact

Previously, to reference icons you’d need to provide 3 different files for the various themes (Dark, Light, High Contrast) and add them in a separate file in your code. They would then be added as background images and lose any scalability benefits. With the new icon font, Codicons, we could define a dictionary of icons and then reference them in the code.

We also shipped the icon library as an npm package for anyone wanting to use them in other projects outside of VS Code or as part of their extensions. It currently has an average of +20k installs.

Scaling for the future

During our research studies, we saw a new theme arise where customers wanted to customize the icons to match their aesthetic preferences, as not everyone liked the outline styles. After we added support for icon fonts in the source code, it was easier to use different versions of icon styles, which is where product icon themes were born. Partnering with our engineer, I helped introduce a new API for product icon themes.

Collaborators