An iconography system

Case study
A selection of our new icons

My first project on the Atlassian Design System team was to look into Iconography. This was my onboarding into the design system.

Iconography at Atlassian had been overlooked. There was 2+ years of signals that the team had been collecting – issues, Confluence pages, and a longstanding wall of feedback on our icons.

I started by investigating the problems. I conducted interviews across different teams, experience levels, and disciplines. I spent time reviewing our internal and external backlogs then categorising my findings. I also dug into Slack to track down conversations – many conversations never led to a ticket or a ticket had far more context that wasn’t captured before being created.

Speaking to our internal product teams, our primary audience, about their process and how they engage with our iconography helped gather insights into how our teams want to use icons, why our teams so often needed new icons, and what was stopping them using icons in the design system. I discovered our guidelines were sending people down the wrong path.

The insights highlighted that our understanding of how we use icons wasn’t clear. This understanding needed to be addressed first before any work to solve the inconsistencies and visual improvements started.

Feedback from our confused product teams

Atlassian Design System

Lead designer

Guidance is key

A component is only as good as the guidance that explains how to use it.

— Yesenia Perez-Cruz, Expressive Design Systems

Iconography, in Atlassian’s design system, is both foundational and a component. Foundations are the visual elements that give structure to the system and Components are the reusable building blocks. We had foundational guidance – icon grids, custom curves, radius, etc – for creating an icon without any component-level guidance for how to use and apply them in-product.

The lack of guidance resulted in a confusing experience for the product teams using the design system and led to a disjointed product experience for the customer seeing the icons in the products.

To help give our teams a clear path to follow and remove as much unintentional divergence as possible, we wanted to address the right questions in our guidelines:

I rewrote our existing guidance with the new insights I’d discovered. It can be hard to get a sense of how effective guidelines are until they’re actually needed so I used support requests to send the draft guidelines as a first step in the support journey. Working this way helped gain confidence that I had the right information and could iterate with deliberate feedback.

An example of the new iconography guidelines
An example of the new iconography guidelines' practical application

Being intentional about iconography

Where we previously only spoke to the icon foundations of radius, angles, and curves were now coupled with component guidelines for application – how-to’s, do’s and don’t’s, and best practices for Atlassian.

The opening paragraph, before and after, are great examples of the updates: “They should be simple, yet bold enough to grab attention, and leave a lasting impression.” now read “Use icons in a purposeful manner to maximize comprehension and reduce cognitive load when you need to call attention to a particular action, command, or section. Use them infrequently – if you’re questioning an icon’s use, it probably doesn’t need to be used at all.”

The old guidelines were unintentional and, in some cases, contradictory of how we wanted to use iconography in our products. I prioritised the guidelines to address the behaviours of our teams rather than changing the visual inconsistencies and hoping for behaviour to change with it. These guidelines were the front door for understanding and applying icons in the Atlassian way. As a design system team, we were still figuring out how to measure success across our resources and guides. I didn’t have quantitive data to show success but as a result of these changes we tracked signals – the drop in tickets and support requests relating to iconography to practically nothing, along with the majority of our new icon requests being resolved through guidelines rather than icon creation. These resolutions were now reached through low-touch support or even self-service, rather than high-touch, individual efforts. We had plenty of qualitative feedback around the guidelines too.

Positive feedback from our product teams about the new guidelines

The team were now more confident that our consumers had support around icon usage – when to use, how to use, and accessibility guidance… but the longstanding wall of visual feedback still lived on. Our clearer guidelines gave me confidence to address the visual design of our iconography.

Our longstanding wall of visual feedback for icons
Our longstanding wall of visual feedback for icons

Redesigning our icons

Our iconography set consisted of almost 600 icons. This was too many icons to need, especially considering icons' new role as support rather than being the star of the show. An important element of any design system is knowing there is a single source of truth. To add insult to injury, our codebase and design libraries were out of sync so that number was even higher.

I sorted through every single icon, with the help of my design team, identifying duplicates and deprecation candidates. I worked with product designers to align on these deprecations/duplicates, and when necessary, paired to consolidate their icons, keeping track on a page to keep everyone in the loop.

With a smaller number of icons to deal with, I generated a small list of our most commonly used and most complex icons (product-specific) to start working with. Upfront, I wanted to know that any icon system we established would be able to stand a chance against the intricacies of our products and the icons we use. I created a brief and engaged a professional iconographer to execute the set and work with to address issues of congruence, sizing (and re-sizing), flexibility, and stylistic questions.

Filled vs. stroke iconography

Fill vs. stroke

Stylistically, this is a decision about visual weight but dig deeper and it becomes a question about recognition. For example, does an icon, filled or stroked, indicate “active” or “inactive” to people? At Atlassian, this convention has not been established bar a few interactions across key products. We opted to use stroke whenever possible, as filled icons are often too heavy in our UI.

Different execution of the same calendar icon concept


Some icons are the same in intent, but not consistent in look. Icons that are used as the same action, such as leaving a comment or adding a date, but look quite different. Whenever possible, considering our new guidance, we’d consolidate these into one account and use text labels to make that intent clear and icon consistent.

Our brand emerging in the camera icon

Practical… with a wink?

A question that we also revisited was icons and our brand. Historically, our brand personality had made an appearance in our iconography (as well as the overall system) – “bold, optimistic, and practical with a wink”. Our icons have gone back-and-forth between functional and friendly and we wanted the new icons to have an opinion. While our icons have always erred on the friendly side, we wanted to ensure our icons were “used in a purposeful manner to maximize comprehension and reduce cognitive load”. We wanted to keep these icons as simple and as useful as possible.

For example, our camera icon felt too plain. After adding extra detail, we stripped the icon back and used asymmetry to add some subtle personality. That’s not to say they’re void of a human element; it’s just more subtle.

Throughout the creation process, the iconographer and I worked through multiple rounds of sparring and feedback. We worked with products and our Brand team to check-in and get our icons into real-world situations. Our Tooling team was able to put together a beta library that allowed (1) products to use the icons for their real-world designs, and (2) the Design System team to get valuable feedback before shipping – the type of feedback you can only get when you allow explorations for products on real interfaces, with clear examples to show where they do and don’t work.

No clear measurement

Cross-functional teams might have helped better measure the success of this work, such as Content measuring how useful guides are – the efficacy of the guideline itself rather than the consequences of them.

Atlassian’s new iconography set

The new iconography set

Looking at iconography holistically, our design system now had clearer guidelines speaking to structure, application, and accessibility to pair with a manageable, consistent icon set to work with. I’d reduced the number of icons in the system to ~250, down from ~600, with an established style and system. The paths of our icons are reusable to help with consistency and conformity to the set. Where possible, we’ve used established paths from existing icons, like building blocks — they make creating a new icon more straightforward, but more importantly, create a cohesive iconography system.

The congruence of the iconography system

With the new designs, almost all of the visual feedback issues from the crit wall and backlogs were completed and questions around iconography ceased. Products were excited to start using them, and our Brand team initiated a project to refresh their Marketing icons using our new set as the base.

On the side

Along with the design updates, I needed to consider the workings of the wider system. I borrowed time from my team when they could spare to help inform the creation of naming conventions and metadata usage across Figma and our icon explorer as well as depreciation plans, estimations, and readying the work.

Lessons learned

The new icons were not fully integrated into the system due to some re-prioritisation. The icons not being in the system meant that adoption of them was low, however, there are more products making use of the icons and the icon system when our current set no longer meets their needs.

As an introduction to the team, I investigated this work in isolation. There were a couple of key factors driving this – my skillset coming into the team, competing priroities for engineering who were heads-down on an engieering-wide initative for the business, and budgets to be used. As the work progressed, it became imperative to onboard and work with developers which didn’t happen until it was too late. When weighed against business priorities, work such as this often lose out. Evangelising the benefits at scale for this work while driving home the small amount of work we'd estimated might've helped our team get this work roadmapped.

(Coincidentally, one of our Atlassian Design System principles reflects this learning, bringing people on the journey before helping for the moment. You can read about the creation of our principles here ↗.)

The Atlassian Design System team are in the process of overhauling the Foundations of the design system, and iconography is being addressed within that initiative. While I’m no longer on the team, it’s exciting to know the work can still be utilized and have an impact.