Atlassian

Atlassian is a software company that builds platforms and tools for businesses. You might have heard of Jira Software, Confluence, Trello, and the most recently acquired Loom. Well, they build these apps. They have over 260k customers, which is around 10 million active users.

Problem

Customers often have ongoing collaborations with external companies, but most of our products don’t allow them to collaborate within the same workspace. Current workarounds are difficult and less secure. The ExCo project was created to allow Atlassian to empower companies to effortlessly collaborate beyond organizational boundaries and build Atlassian’s product-led, viral land funnel.

Outcome

Design led on a three-month project focused on enhancing external collaboration capabilities. Over 250 hours of research, including 47 customer interviews and competitor analysis, were conducted to identify key user needs such as security, privacy, control, and scalability. Working with eight designers in four cross-functional and international teams, we employed the double-diamond process to develop solutions addressing these needs. This was project was successfully handed over to Confluence team. This pillar (public sharing) project increased sharing by over 25% across Confluence – allowing more people to collaborate and get more work done.

Here is how we did it 👇

Process

We used the double-diamond process to ensure we followed a process that constantly allowed us to evolve our understanding and approach to the project. These checkpoints are based on the confidence level summarised through business and customer impact metrics and feasibility.

From a design point of view, I split the activities based on each diamond, like so…

Defining the problem

We carried out extensive research internally using a third-party agency to help us analyse existing desk research as well as reach out to existing external customers. Our main objectives were to: 

• To capture primary use cases, goals, archetypes, and real-world situations
• Interpret any privacy, ownership, data residency, and access concerns
• To understand the concerns and attitudes of admins

We conducted 5 moderated research studies covering various industries and company sizes, which spanned around 200 hours of research with a team of 6 involved. This covered 47 individual customers who were a mix of admins and users. We also did competitor analysis across a range of different competitor products to understand what their products offered and how they worked within the external collaboration.

What we learnt

We listed out the top three ways that users have to workaround the problems to help us and stakeholders have a good sense of the current landscape.

Using Google or Word docs because they’re shareable

• Need multiple products for a job
• Causes scattered information and no “source of truth” between products

Downloading and emailing PDFs

• PDF feature breaks some content
• Lack of “live” collaboration causes “final.final.final.pdf” situation
• Difficult to leave feedback
• Email is not the preferred way to collaborate

Locking everything down and using complex groups

• Does not work with Open By Default
• Significant admin overhead
• Users who are closer to the work aren’t empowered to add the users they need
• Security issues (external users can see directory etc.)

Top user needs

It was important to showcase the top needs of our users as this surfaced the current requirements we'd need to design for and build.

Security

Permissions and settings that are clear and relatable

Privacy

Clear boundaries of ownership

Control

Keeping track of user access, updates, and usage

Scale & Flexibility

Software matches their collaboration needs

Use-cases

Separating how users think about and use external collaboration helped us understand how we'd categorise, design, and prioritise their needs.

External guest

• Contractors for specific projects
• Temp cover contractors
• Clients (mostly individuals)
• Small external teams

Companies collaborating

• Agencies working on multiple projects
• Deep collaboration over longer periods of time
• Collaborating with a sub-contractor

Customers sharing

• Less-tech savvy people
• One-off pages
• Lower security pages
• Shallower collaboration

Collaboration models

These models added further insights into how our users collaborate with external parties. They allowed us to map out our taxonomy and IA while aiding us during stakeholder conversations.

Project-based

Most agencies treated their workspaces as projects. Permissions tend to be full access to that space/project.

Role-based

Based on what they were hired to do, typically a contractor who also gets a company email address. Permissions were similar to a full-time employee.

Service-based

External teams provide a service to either multiple departments or localised to a single project.

Problem statement

We settled on a single problem statement to outline our understanding of what users lack.

"Customers often have ongoing collaborations with external companies, but most of our products don’t allow them to collaborate within the same workspace. Current workarounds are difficult and less secure."

Pillars

We created three pillars based on the research to divide the work between several teams and roadmaps. So they could work autonomously but also stay connected to ExCo as a whole. Once the research was finished, we allocated a designer per pillar. At this point, I moved onto Public sharing.

External guest

Collaborating with external guests like contractors.

External company

External trusted orgs can collaborate with organisations.

Public Sharing

Permissions to share, read, comment, and edit content publicly.

Understanding Public Sharing

I worked within a quad structure (Analytics, Engineering, Design, and Product Management) to define our problem and solution statements. This exercise allowed us to define what is the actual problem that we'd be looking to solve and help us stay on course during the longevity of the project.

Problem statement

Our customers' needs have grown and their need to collaborate with anyone makes our products a blocker.

Customers also need to share information with an array of people and teams outside of their circle of trust, which currently involves messy workarounds in our products.

These problems cause time delays, cognitive load, and exporting to PDF or transferring content to other tools.

Solution statement

We want to unblock collaboration and sharing of content across all our products by allowing customers to set permissions to anyone so they can read, comment, and edit content in objects and containers.

We want to make our customers, admins of their own content.

Empathy mapping

The primary purpose of empathy mapping was to create a shared understanding of public sharing users. So that we are thinking and referring to them similarly, we’ll also use them to help us make decisions.  I aimed to map the personas across two use-cases: 

• Customers looking for shallow collaboration on specific pages or spaces
• Customers looking to share specific pages or spaces.

We used FigJam to help us collaborate remotely. I spent the first half of the workshop explaining why empathy mapping is important and the relevant research we collected. The second half looked to define the three persona types we identified. We put together three personas across our two use cases.

Use cases

We concluded through our research that there were two specific use cases that required Public Sharing functionality.

Shallow collaboration

Customers usually want to 1:1 or async collaboration with a few people to unblock them on specific tasks.

Sharing content

Customers share content to external teams/users or to internal teams to help them with their JTBD.

Experience Gap Analysis

We documented the current state of our products so that we could understand them and identify the impact of Pillar 3. We then mapped solution and research questions (HMWs) against the gaps we observed in Confluence and JSW and applied this across a matrix of:

• Altitude
• Experience moment
• Problem space

to understand the touchpoints, scale, and complexities of each gap.

Exploring Public Sharing

We want to combine current features in existing products to create a uniform platform solution.
We are doing this to simplify and align our mental model with how our users understand public sharing.

This will reduce cognitive load for our users, allowing them to use a single URL for sharing and viewing. This will also reduce friction for admins as we reduce the number of touchpoints for content.

Future state user flows

I started to map future state journeys across all our known personas for Confluence.

The plan was to extend this to other products once we complete the Discovery phase for each of them.

View

View-only experience for any container or object. Customers can share these with the following recipients:

• Members of the org
• Anyone with a link
• Atlassian accounts

Comment

Read & Comment experience of shared container or object. Customers can also:

• Approve comments
• Mark comments as spam
• Delete comments

Edit

Read, Comment, & Edit experience of shared container or object. Customers can also:

• Approve edits
• Reduct edits

Collab model

We discovered that the Pillar 3 collab model extends across a wide spectrum of users.
We’ll look to extend the current user roles we have with anonymous access and guest by introducing two new user roles:

• Internal consumer
• Known consumer

These roles will give customers greater flexibility and fulfil their current needs. We applied this collab model to our share modal.

Huge for me

I also worked across the whole of the ExCo project all while within a specific quad that was focused on a single pillar. This quad was based in the US, so I had to shift my hours and use async methods such as recording looms, using FigJam boards to continue collaboration during offline hours, lots of Zoom meetings during cross-over times, and using Slack to communicate the progress of the project across a multitude of leadership teams including the C-Suite.

I learnt that I was nature leader and showing not telling become a powerful tool for me. I learnt that I could command a room of high-class designers by being calm yet passionate. I learnt that I could work on huge scale projects across mutliple timezones. I learnt a lot in this project.