Loom · Atlassian · 2023–2025

Two products, one front door

Atlassian acquired Loom in 2023. I was a design owner for the work that moved 40 million Loom users onto Atlassian’s identity, billing, and admin platform without losing them at the threshold.

Role
Senior Product Designer, design owner for migration
Timeline
Two year phased rollout
Scope
Signup, billing, admin, and the end-to-end migration sequence

What happened

Fastest
integration in Atlassian’s history, launched 24 October 2024
+38.7%
over ARR forecast
40M
users moved onto the new platform

“It is really difficult to overstate how complex plugging in an entirely new backend system across our most critical user journeys of sign up, provision, and billing is. Truly the most cross-functional of efforts across Loommates and Atlassian broadly.”

Joe Thomas, Loom CEO

How it got there

The problem

Move 40 million Loom users onto Atlassian without disruption, deprecate 700,000 free roles, and remediate prices for 85% of paying customers. Every existing Loom customer would be impacted by this, and each cohort was high-stakes.

Two admin cultures

Loom admins tend to be senior individual contributors managing small teams. Atlassian admins are IT professionals managing thousands of users in a complex admin hub. We were moving the first group into a system built for the second. Most of the design decisions on this project were guided by this fact, including the settings handoff.

Deciding where to spend

Data Science analyzed the business-critical flows and graded them by churn risk against a benchmark of less than a 5% drop in conversion. That gave us permission to hone our focus:

  • Invest in Loom-branded signup, because it sits at the top of the funnel
  • Change nothing about the upgrade flows, and instead measure and learn
  • Invest in admin and billing, because churn risk was concentrated

Cohorting

We kicked off with a week-long workshop at Atlassian HQ in Sydney with the User Access Admin and Commerce teams. I facilitated at the whiteboard and produced artifacts afterwards. The plan was to start with lower-risk customers to test the migration scripts, sub-cohort by churn risk determined by size of price change and free role reduction, and handle the outliers in snowflake cohorts at the end. Atlassian Commerce’s earlier platform migration had run to more than fifty sub-cohorts, which indicated how granular this needed to get.

Cohort diagram public/images/case-study/cohort-diagram.webp landscape · 16 : 9
The plan everyone worked from Which customers moved when, across four quarters labelled by how much confidence we actually had in the estimate, against five parallel workstreams. Sales, Marketing, and Support planned against this.

Bridging two settings systems

The gnarliest problem was structural rather than visual. Two products with completely different settings information architectures now had to behave like one. I led a group of designers to map which setting lived where, audit the redundancies, design the handoff points between them, build a repeatable pattern for bridging, and argue for the investments in them.

Sequencing the communications

Loom’s free Creator Lite role was deprecating, which meant users had to go through packaging changes as well as a new account system. I worked with product and marketing to map the full sequence: timing, channel, and content for each touchpoint. Design timelines made the sequencing legible by showing the experience as a customer would receive it rather than as a list of sends.

Deprecation timeline scenarios public/images/case-study/deprecation-timeline-scenarios.webp landscape · 4 : 3
Three ways to sequence it Deprecate the role before the migration, during it, or after. Each option drawn as the customer would receive it, with the risk it carried flagged on the timeline: change fatigue on one, bundled release complexity on another. This is the artifact that got the decision made.

What it took to ship

This project required work beyond the typical scope we consider to be product design:

  • Influencing platform teams to adopt changes they had not planned for, including a new cancel flow and per-seat pricing
  • Serving as a subject matter expert on Loom’s billing and monetization flows during the commitments process, when the Atlassian Commerce team decided which capabilities they would build for us: trial skipping, mid-cycle true-ups, and scheduled downgrades
  • Building processes. There was no process for staying current on Atlassian’s admin and commerce roadmaps, so I set up 1:1s with their designers and monitored their channels to anticipate releases that affected our users.
  • Coordinating across Atlassian Admin team and Commerce team divisions in both Sydney and India, Data, and UXR, which is roughly sixteen hours of time zones on a standing basis
End-to-end journey comparisons public/images/case-study/journey-comparisons.webp landscape · 16 : 9
Three ways in, one source of truth During migration users had three different routes into a Loom account: loom.com, the new Atlassian identity flow, and Atlassian’s own front door. This board put all three side by side and compared them screen for screen, from onboarding, emails, billing, upgrade, and downgrade. It served as an important product artifact for the team on the current states of the flows across product, marketing, data, and engineering.

What I took from it

Begin small, measure, and iterate

We left real things out of the initial launches: upgrade optimizations, role deprecation tooling, admin onboarding. Getting a baseline first meant the later investments were based on data and more strongly justified.

Compromise was the job

With this many teams and this many moving parts, holding out for the best version of any single flow would have cost the launch. Aligning on shared goals and accepting progress over perfection was a critical part of the success of this project.