Redesigning Adobe’s File Type Icon System Language

On the Adobe Design Brand team, we create branding for all of our desktop, mobile, and web products. A branded element can be anything from the two-letter product logos you see on your dock to the splash screen and icons within the user experience of the product itself.

An often overlooked but highly visible feature is the file type icon. A file type is a name given to a specific kind of file that an application can create, such as .DOC for a Word file. The file type icon is the icon assigned to the file type and what is displayed on your screen when you save or open the actual file.

With the newest release of Creative Cloud this fall, users will see that all of our file type icons have a fresh, new look! In this article, I’ll delve into the thinking and process behind our latest redesign of Adobe’s file type icon system, and share insights about the challenges we face with evolving a brand system across a huge family of products.

Identifying the Issue

Many customers might not realize that Adobe has more than 100 products and services across three clouds: Creative Cloud, Document Cloud, and Experience Cloud.

This means that one small change in the design system can create hundreds of changes across the board.

When it comes to file type icons, people often only consider the primary file types of an application, like:

• .PSD for Photoshop,
• .AI for Illustrator, or
• .INDD for InDesign

However, most of our products can import and export a variety of secondary file types as well (for example, Photoshop alone has over 120 different file type icons mapped in its registry).

To optimize for different operating system requirements, our file type icons also need to be manually pixel-snapped at 10 different sizes and then delivered as a set of rasterized .PNGs that get packaged up into .ICNS (Mac) and .ICO (Windows) files.

When we factor in the number of sizes and formats for each file type icon, we’re looking at over 7,000 assets to modify and manage with each release cycle.

At the rate at which Creative Cloud’s product line has been growing over the last four years, it became clear that the amount of effort required for creating and maintaining these file type icons in the existing workflow was no longer scalable.

Step 1: Audit and Investigate

Before we could start redesigning the system, we had to investigate what we’re currently using in our products. We reached out to every product team to help us conduct an audit of all their file type icons.

Inconsistencies were everywhere, and they were likely a result of two factors:

1. Different teams owning each product family and no longer aligning on the design, and
2. As new products and file types come online, individual icons are created as one-off designs.

With the information gathered from our audit, we built a bird’s eye view of the existing file type architecture.

First, we organized the file type icons by product family and cross-referenced them to see which secondary file types were shared between multiple applications so that we could eliminate duplicate icons. By doing this we were able to cut the number of secondary file type icons down to 65%.

Next, we categorized the file types by function, such as “Image,” “Audio,” “Code,” and “3D.” Typically a file type icon will feature a metaphor that speaks to its main functionality (for example, a .HTML file type will use the brackets metaphor </> to convey that its functionality is related to code or coding).

We noticed that some file types were using several versions of the same metaphor, while others had custom metaphors that could be replaced with a more generic icon. We started creating broad umbrella groups of file types in order to assign a single metaphor to the entire family. In doing so, we were able to reduce the number of file type metaphors in our library by more than half.

Step 2: Sketch and Design

Once we had a comprehensive view of the old system, we began establishing the basic organization principles for the new one:

1. Only primary file types would get the product logo color association. For example, .PSD would be blue and .AI would be orange.
2. Create a neutral palette for secondary file types that are supported by multiple applications. For example, Photoshop and Illustrator would use the same .PNG file type icon, instead of each having their own unique version of the icon through brand color association.
3. Create a master library of file type metaphors to keep icons consistent and avoid customizing assets for edge cases.

We started sketching with this new framework in mind.

One of the main drivers behind the redesign was to simplify and remove as many elements on the file type icon without losing its significance. We dropped the tag, and moved the file type mime to the bottom of the icon. We also removed the page curl to flatten the design and create a more modern visual language.

Another important driver was aligning with Spectrum — Adobe’s new UI design language — which is currently rolling out in all our products. Toward this effort, we rounded the corners of our file type icons, and began building a library that either used existing metaphors from the Spectrum database or creating new ones that aligned with their illustration style.

Finally, we incorporated the bright color outline in the file type icon to tie into the existing branding of our product logos. This change not only made for a more cohesive visual system, but the new icons rendered better in dark interfaces whereas our old icons would disappear into the background.

Step 3: Iterate and Finalize

After we decided on a design direction, we tested the new file type icons in context. During the initial audit, we investigated all the areas where file type icons appear in different operating systems and within our own products. We also looked at each context in which the icons were appearing in different sizes and resolutions.

On both Mac and Windows desktop screens, we had to account for the icons being displayed in List versus Grid views at varying scale factors (16px being the smallest size all the way up to 512px at the largest). There was also the issue of light versus dark UI, such as in the “Recent Items” or “Spotlight Search” on the Mac desktop. Then we looked into where our file type icons appear within our own products, such as in the Assets Panel, Media Browser dialog, and the Welcome Screen when you first launch an application.

As one can imagine, this process quickly led us down a rabbit hole of all the obscure and forgotten corners of our system where file type icons live. Still, it was a valuable exercise. We got to more fully wrap our heads around the task.

The last step was to look at the file type icons implemented in the UI of our web and mobile services, such as Adobe Acrobat and Creative Cloud Libraries. Since these services were also managed by different design teams, we had to coordinate with a lot of people about our plan to overhaul the file type design system.

We are proud of the final result, because the new design language is clearer, more consistent, and represents the next evolution of Adobe’s visual brand system.

Step 4: Design a New Workflow

We created a new workflow for production that utilized scripting functionality in Illustrator for compiling and exporting the .PNG files with a push of a button. This new template saved us dozens of hours of painfully slow and manual work.

We also needed a better way to compile these rasterized .PNGs into .ICNS (Mac) and .ICO (Windows) files. In the past, we used the IconBuilder plug-in from IconFactory with our Fireworks templates. However with the new workflow we wanted a more flexible solution that would meet our needs: primarily the ability to drag and drop any set of .PNG files and have the application automatically output both .ICO and .ICNS files in the correct sizes.

After searching for a third-party compiler, we decided that it was better to work with our engineers to create an internal app, customized for our needs. They created an amazing tool we lovingly called Captain Icon, which is the compiler we used to package all of our new file type icons. (While Captain Icon is still in internal beta, our engineers hope to share it on GitHub in the near future so that it can be available for our developer community to use!)

Step 5: Implementation

We are still in this phase, and will probably be for a long time. Each time we ship a Creative Cloud release, we go through a process involving product managers and engineers across many teams, making sure the design carries through everywhere.

Implementation is often a tedious process of communicating back and forth with teams in hundreds of email threads, installing several test build versions to check assets, logging and troubleshooting inevitable bugs, and managing multiple release deadlines.

Our products are also built on different code bases, which means teams might implement the same assets differently and find issues that are unique to each platform. Quality assurance and enforcing brand guidelines is probably one of the least fun tasks for our team, but it is an important part of maintaining an evolving design system.

Small Changes Can Make a Big Difference

On our team, we often use the metaphor of the bonsai tree to describe the work that we do.

Evolving a brand design system that contains hundreds of products relies on a million small, incremental changes along the way — we snip a branch here and there, and guide the tree to grow in our desired direction over time.

While it’s easy to get lost in the details, everything we learn in the process carries us through to the next iteration, and the next one after that.