Iconography at Atlassian had some history. There was a couple of years worth of ‘signals’ (Jira issues and Slack discussions) that our team had been collecting as well as Confluence pages from previous team members and an embarrassingly longstanding wall of post-it notes with design feedback to fix across our iconography set.
There was obvious work that could be done to address visual inconsistencies, improvements to the system, and resources for contribution. However, I noticed many issues came from a basic misunderstanding of icons and how we, at Atlassian, want to use them. Most of the understanding we had at Atlassian was shared knowledge amongst longstanding members of the Design team. It wasn’t documented. Our team, new and old, was confused by icons because there was little information readily available.
The first step to fixing our icons was to establish the basics – we rewrote our guidelines.
A component is only as good as the guidance that explains how to use it. — Yesenia Perez-Cruz, Expressive Design Systems
Our lack of guidance resulted in a confusing experience for the consumer of the design system icons, and ultimately, the customer using our products. The guidelines we had were aesthetically focussed and weren’t particularly useful when wondering how (or which) icon to use in a product experience.
We gathered insights from interviews and recognition tests, amongst what we already had, into the how our teams use iconography – particularly why our team so often needed new icons and what was tripping them up when it came to using our existing set.
Our guides previously spoke about icon grids, custom curves, radius, and all sorts of confusing terminology that didn’t help with how to actually use our iconography system. Because our current guidelines didn’t address how to use icons – applying the icons that already existed – a new icon seemed like the only solution. We wanted to address the right questions at the right time for our consumers:
The existing guidelines weren’t intentional and, in some cases, were contradictory of how we wanted to utilize iconography in our products.
We paired our best practices and accessibility guidance together to remove a lot of the confusion around iconography – “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.” Where we previously spoke of radius, angles, and curves we now offered how-to’s and do’s and don’t’s for Atlassian.
Our guidelines on iconography are now split across two parts: (1) as a ‘Foundation’ for the design system – what icons are, their make-up, and the system – coupled with (2) as an icon ‘component’ – focused on usage and best practice.
This was a necessary first step to equip our team with a solid shared understanding. Now that our iconography foundations were strong, we could look at addressing some of the design-related issues mentioned that were still prevalent across our iconography set – visual inconsistencies and stylistic/system improvements.
Our icon set was nearing 600. We were able to remove outdated icons from products that no longer existed such as Stride and worked with products to consolidate similar icons. Once we’d removed duplicates or one-offs across tooling and code, we’d cut our library in half!
We gathered our most commonly used icons to start exploring a system – simple shapes to complex forms. We wanted to know that any icon system we established would be able to stand a chance against the complexities of our products and the icons we use; now and in the future. Along with considerations of grid, stroke, radius etc, there were plenty of questions that emerged from our previous critiques and feedback…
Working with Mads Burcharth, we set out to create a unified iconography set that was scalable for our products.
We wanted to get as much feedback as possible. Our Tooling team was able to put together a beta library that allowed products to use the icons for their real-world designs and the Design System team to get valuable feedback during our iterations – the type of feedback you can only get with real application on product interfaces.
Mads and I also revisited how icons work within our brand, with the help of Creative. Our brand’s personality had made an appearance in our iconography (as well as the overall system) – “bold, optimistic, and practical with a wink”. We'd already moved away from “bold”, but do the other brand pillars have a place?
Having already established the fundamentals of our iconography, 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. That’s not to say they’re void of a human element; it’s just more subtle.
2020–2021See the work
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 for future icons.
Our new guidelines and icon system, while still in Beta, saw a huge drop in tickets relating to iconography. Almost all of our new icon requests could be resolved without a new icon at all, but focussing on the guidance, application, and context. There was positive sentiment across our help channels too.
(The new iconography library is in beta, and as a result, there is a staggered rollout of guidelines)