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.

A side-by-side comparison of an ADG3 product and an Server product
Server products on ADG2 compared to Cloud products adopting ADG3

Bitbucket, Server

Senior designer

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.

A compatibility audit of ADG3 components with our Server products
An audit of our the new design system and compatibility with our Server products

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:

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.

Examples of pages written to document design decisions and assign ownership
Documenting our decisions and assigning owners

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.

A page template to start writing better guidelines for the design system components
Improving how we write design guidelines for the design system components

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.

Screenshots of the communication channels used and what was communicated to our customers
Communication channels leveraged for our Enterprise customers

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).

A screenshot of a team retro with good and bad columns
Retros helped teams improve process

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.

A redesigned pull request in Bitbucket Server
A redesigned branch list in Bitbucket
A redesigned Bitbucket dashboard