ADG3 in Server
Case study
In 2016, a third iteration of the Atlassian Design Guidelines (ADG3) was revealed to coincide with Atlassian’s Cloud-first approach. This was the first time that the design system did not account for on-premise products, Server & Data Center, by focusing only on our Cloud products.
Server customers started asking about the new design system and questioning the company's investment in these products.
Reframing the question
Considering previous efforts, my Design Manager and I reframed the question – instead of asking how long would it take for a full-scale adoption, we asked what we could start adopting from ADG3. We wanted to leverage the ADG3 and start receiving the benefits of a design system – mainly time saved on common design decisions – to allow more focus on the core product experiences. By doing so, we hypothesized we could demonstrate the company investment to our Server products and customers.
Bitbucket, Server
Senior designer
2018–2019
I ran a week-long spike, based in Sydney, working with our other designers across three timezones: Sydney, California, and Gdańsk.
The goal of the spike was to determine how much of the ADG3 could be adopted by Server to connect our products in a meaningful way with our Cloud offerings, mainly through matching behaviour and functionality. Through this, the experience of Cloud and Server products become harmonious and allow seamless switching between products to fuel the transition to Cloud. The designers and I finished the week with plenty of screens, a solid understanding of the new design system (and opportunities for contribution), and a great idea of what parts could be applied to our Server products. Foundational elements such as typography and colours took our products a long way towards the harmony we were looking for. Heavily used components such as buttons, text fields, and system messaging were clear priorities.
More art than science
Due to limited access to customers, finding harmony was somewhat subjective. I used the core product journeys with the most commonly used components and patterns, then identifiyng which of these held the most value in recognition and behaviour, e.g. a primary button is solid blue, consistently applied to the same behaviour, and carries our brand heavily.
A new mission
The spike gave us the confidence, as a Server Design team, to embark on a mission – “80% of all user-facing changes will employ revitalized ADG Server design and copy patterns so that customers feel confident we're investing in Server products.
We wanted:
- Revitalized and aligned interfaces – cross-product and across Atlassian. These should include improvements to the accessibility, usability, behavior, and performance.
- Concentrated efforts on predictable enterprise experiences through producing components and patterns that meet our customer's needs and scale.
- React as the standard front-end library to improve velocity for front-end development and, ultimately, to make it easier to improve our UIs for our end-users.
I worked with each product’s designer in Server (Jira Software, Confluence, Jira Service Desk, and Bitbucket) to determine a quality bar – the minimum viable experience for products with an expected number of ADG3 components and patterns, as well as stretch goals for teams to reach for.
For on-premise customers, a seemingly small change can have huge effects on costs and time, so this meant we needed to be cautious for large experience changes. We wanted to avoid affecting customers' workflows as much as possible while trying to set reasonable expectations about when something will change.
Because ADG3 was designed for Cloud products, we had to drive design decisions for our Server products. As a design team, we shared our product context and particular use cases, then worked to consolidate decisions or, at the very least, assign owners to drive the work forward to consensus.
Progress > perfection
The size of our design team for on-premise was small. This allowed us to make decisions quickly, unanimously, and apply them in our work with very little friction. Some of our decisions weren't perfect, but great outcomes for the sitatuion we were in.
A single source of truth
With the visual changes and decisions we were making, a small team of us (myself, another designer, and content designer) took the opportunity to review our documentation. Our guidelines were out-of-date, but more importantly, didn't address the questions we were asking of the components. Through sparring sessions with our teams, those questions would surface and overall themes that were being asked regularly could be addressed in the guidelines. Minor questions, such as the different usages of toggle vs. checkbox, to larger questions, such as how to make a component for enterprise-scale. We built on the existing ADG3 guidelines for Server-specific support.
We engaged the community through Early Access Programs and presented to our third-party developers at App Week 2018, a conference for our Ecosystem with a particular focus on experience and performance. During the week, I was able to gather insights, feedback, and help the ecosystem understand what was coming. Through these channels, I could have a dialogue with our customers, which can be difficult given the nature of enterprise and on-premise security and privacy concerns.
Play, as a team
As we were digging into this work, we uncovered plenty of opportunities to contribute back to the ADG3 that could support all of our product teams support enterprise customers. I worked to keep communcation open with the ADG3 team, letting them know what we were doing and finding ways to contribute what we could back to the ADG3 to evolve it.
On-premise customers can have firm expectations about releases. To avoid messing with every Server product's release cycle, each product could ship on its own schedule as long as it met our MVE. We didn't need strict consistency as the goal wasn't full-scale adoption so products were happier to do the work when it suited within a reasonable timeframe. After a product shipped, the team would run a retro to see what worked and what didn't to improve our process for the next product to work with. This incremental rollout meant the team could learn from others' wins (and failures).
Foot of the mountain
We shipped our new visual language, leveraging the ADG3, to the Server products.
Along the way, our cross-functional teams all joined to help with our mission and our customers stopped raising concerns about investment. We'd save significant time by being able to leverage the new design system guidance and resources as well as codifying our own decisions to reference, allowing our product teams to focus on their products.
After successfully shipping, the Server Design team started on a new mission that bulit on the previous mission – “We have envisioned and shipped a compelling experience for administering and deploying our products at scale, based on a deep understanding of customer needs.”
The ADG in Server continues to support that mission by concentrating efforts around predictable admin experiences by producing server-wide components and patterns that meet our customers needs and scale.
