Atlassian

Atlassian make tools like Jira and Trello that are used by thousands of teams worldwide. And they’re serious about creating amazing products, practices, and open work for all teams.

Problem

Atlassian users encountered several challenges when integrating Jira and Confluence with Microsoft Teams, including:

• Complex and lengthy installation processes.
• Information overload in the user interface.
• Confusing calls-to-action (CTAs) to install the Jira and Confluence apps.

As a result, users miss out on: previews of links to provide more context, being notified of updates across their projects, finding/commenting on Jira issues or Confluence pages are shared during conversations in Teams.

Quantitative data revealed an 88% drop-off rate during the installation process of the Jira app.

Goals

We added overarching hypotheses to break down our goals into structured solution statements. This helped us understand: (We believe) What the goal for the project was, (will result) What we expect to happen, (because) Why.

1

We believe improving the Microsoft Teams install experience
will result in more Jira app completions
because users will have an experience that guides through the process of getting Jira app into Microsoft Teams.

2

We believe improving the Microsoft Teams unfurl experience
will result in more sign-ins and request access approvals
because users will have a simpler unfurl experience that will increase user engagement.

Outcome

By redesigning the Teams experience, we addressed the previous 88% drop-off rate during app installation, seamlessly guiding users through the setup and significantly increasing successful installations. Additionally, we refined the unfurling of Jira and Confluence links within Teams, delivering clearer previews and actionable insights that boosted user engagement and encouraged more frequent sign-ins.

To support these improvements, we established user-centric design principles emphasizing clear guidance, reduced decision fatigue, conversational language, and a cohesive integration experience, ensuring a consistent and intuitive journey across Atlassian and Teams platforms.

Here is how I did it 👇

Discovery

I created and ran design activities to collect more qual data before during the discovery phase. We learnt a lot about the usability and customers, all the highs and lows of using Atlassian third-party apps in Microsoft Teams. Here is a summary of each activity and learnings:

PURE evaluation

• 26 / 42 (higher is worse)
• Lack of system status visibility
• Higher recall than recognition
• Limited flexibility and efficiency of use
• Minimalist design with low aesthetic appeal

Empathy mapping

• Average of 12 steps to install Jira Cloud app
• The experience of requesting access varied
• Confusing language
• Absence of process indicators

10x Customer interviews

• Lack of comprehension of what our integrations can do
• Unaware if integration is available or installed
• Long lists of conversations
• Reluctance to move into Teams from Slack

Definition

We took all the information we learnt from our discovery phase and found that Atlassian customers go through cycles of collaboration.

 The sender shares a link to a Jira issue or Confluence page to collaborate, inform, or unblock work. This was shared in a third-party app like Teams. The receivers would then have chats or meetings in the third-party app that drive them back into the Atlassian product, resulting in a deep dive, more collaboration, or being invited into the product.

Archetypes

Using all the qual data we collected, we were able to form two archetypes:

Creator
Typically a Lead or Product/Project Manager focused on ensuring work progresses at a good pace.

Consumer
Typically an individual contributor, such as an engineer or designer, focused on completing tasks.

Principles

We created and applies some principles to keep the multiple experiments and projects on guardrails – allowing the experience to feel consistent and cohesive. Using conversational-style flow that guides users through the different processes (adding an app, connecting with Atlassian ID, setting up notifications, etc.).

Here some principles I developed:

• Add signs – signal what to do, where to go and why
• Reduce decisions – focus on primary actions/options
• Legible and human – conversational language, simplify technical terms and reduce copy
• Coherent experience – connect the dots for the users, focus on recognition over recall
• Match both systems – marry the two design languages/systems so that it feels like Atlassian but inside the 3rd party app

Design

I ran a workshop (one of many throughout the project) to build out solutions and concepts. We used the HMW exercise in this workshop to start to define the possible solutions based on the data we collected and our understanding of it.

During the workshop, we also spent time sketching some concepts based on problems and those HMWs. I also created a specific hypothesis around each concept. With each concept, we ran through a DVF exericse to deteminte which one of these concepts would create the most impact based on our confidence.

Future-state journeys

I took apart 9 existing flows that I documented and rebuilt them around the principles, qual and quant data, and concepts. I followed a modular design methodology so that the experience into broken up into separate steps. This helps users have a conversational-style flow that guides them through any process. It also ensures we can remain agile throughout the design and engineering processes as we might need to chop and change.

We went from 9 journeys to just 5 now, removing about unnecessary 15 steps along the way.

Comprehensive flow – taking into account possible routes and states.

Modular Conversations between the user and app – allowing more modules to be added.

Reducing decisions – adding default values (i.e. what kind of notifications they need) would remove unnecessary steps.

User stories → Feasibility

I separated the future-state user journeys into five main user stories, that I then turned into journeys, all while adding med-fi designs. This process helped the engineers speed up their feasibility checks, as they were able to understand the requirements and scope of work within a single view.

(Med-fi gave the engineers enough detail about the IA and layout)

Atlassian x Teams – Design Systems

One of principles was to "match both systems". We needed to marry the Atlassian and Teams experiences (UX and UI)  into one cohesive system that could be used for current and future projects. This required a deep understanding of each their design languages, the differences, the similarities, and any restrictions. 

I also collected screenshots of an Atlassian product, i.e. Jira Software and I did the same thing for Teams. This helped me understand how the design language was used in a real product. I wanted Atlassian users to feel familar with the design language when they were in Teams and also for Teams users to feel like they're getting a familar experience when using a third-party app. This included bringing in elements that they saw and interacted with every day, using the recognition over recall principle to reduce their congitive load, especially for first-time users.

Components

After several meetings of meetings with the Engineering team, we realised how limited we are by Teams ecosystem restrictions. These are in place for a good reason, Microsoft are running enterprise software that needs to handle secure communications for customers like Mercedes, Bosch, and Boeing (to name a few). This meant we had limited scope to what changes we could make and how we could do them. I focused redesigning existing components rather than a complete rehaul.

Unfurl experience redesign

This experience is content heavy with too many CTAs and takes up a lot of screen space – it also lacks structure and visual langage that resnotes with our customers. Users become disorentated and frustrated. The focus was on reducing content and action density – using several of our principles to guide the design and engineering decisions.

We used adaptive card v2 to help us move away from static card to dyanmic cards that can be updated on the fly. This helped us separate content based on Atlassian permissions.

Install experience redesign

The process to install Jira was also content heavy and lacked strong value props (i.e. how to use the app and its features).

Atlassian outside of Atlassian

It is well know that certain Atlassian products are difficult to use and puts non-technical customers off from using it. But we felt this was the perfect position for third-party apps to take over and allow non-tech customers to interact and utilise Atlassian products without having to venture into the product. We could bring the most used and best features by simplifying them into a product like Teams. So that's what I envisioned next.

Delivery

Oh boy did I deliver. I had a lot of help from other designers along the way including more focused collaboration with our Content Designer for messaging. From spec sheets, animations, Figma libraries, to Looms and Confluence pages. The engineers had the whole package and all within their timelines. This allowed them to hit all their milestones on time.

How was this possible?

Concise qual and quant data, clear principles, lots of workshops, meetings, looms, and safe zones for communication.

I couldn't possbilily show you all the work that the design team delivered for this project but it was a lot. And it's still ongoing. I'm proud to have created this fundamental leap for Atlassian within Teams. This ensured that we showed design value, not only in the results but the way we worked with our stakeholders and peers, and our Microsoft partners (who we got glowing feedback from). 

And once we hit that launch button, the charts for MAU, CSAT, PEU just kept going up and up.

But it wasn't all me, there is a whole team of Engineers, PMs and other Designers who enabled all this great work. Thank you team.