Case Study — Atlassian / Trello

Helping Trello find its
new identity

How research shaped one of Atlassian's boldest product bets — pivoting a 50M-user tool away from project management and into personal productivity, with a tight timeline and high organizational stakes.

RoleLead UX Researcher
CompanyAtlassian / Trello
TimelineJune 2024 – Sept 2025
MethodsUsability Testing · JTBD · SEQ Benchmarking
50M+Trello users affected by the pivot
33Jobs to Be Done mapped across 3 research waves
5.5+SEQ score maintained across all core flows
30kAnnual MAU increase from benchmarking work

Trello needed a new direction

Trello was acquired by Atlassian in 2018 for $500M and had grown to 50M+ users — but most were on free accounts, and the product's identity had become muddled. In early 2024, Atlassian leadership made a decisive call: Jira would own all project management use cases. Trello needed to pivot.

The new direction was personal productivity — helping individuals manage their own tasks, routines, and goals. A suite of new features was already in development: Inbox, Planner, Jira Lists, Mirror Cards, and Quick Capture. In June 2024, Trello's Head of Product brought me back specifically to answer the research questions that would determine whether this pivot would succeed.

Early 2024
Atlassian leadership decides Trello must pivot to Personal Productivity
June 2024
I re-join the Trello team — joining a product in motion with a tight deadline
Dec 2024
New Trello released internally to all Atlassians
Jan – April 2025
Closed beta, then open beta
September 2025
Full General Availability — research delivered on all fronts

Four objectives, one tight timeline

Joining a product mid-sprint means everything is moving fast and the questions are changing week to week. I structured my work around four objectives that ran in parallel, not in sequence.

01
Answer critical questions
High-stakes design decisions needed fast, credible answers — particularly around navigation and the new Split Screen experience.
02
Build confidence
Leadership needed evidence that new features were ready for beta. Research had to move fast enough to inform decisions, not just validate after the fact.
03
Iterate and improve
A scalable, repeatable framework for measuring usability across 6 feature areas — so teams could keep improving right up to GA.
04
Build foundational knowledge
A long-term JTBD program to ensure the whole org understood what personal productivity users actually need — not just for this release, but for the roadmap ahead.
Case Study 1 of 3

Settling a high-stakes design dispute

Inbox and Planner are only useful if users can easily navigate between them and their existing Trello boards — the solution was Split Screen. But how that navigation should be built split the organization in two.

Design 1 — Trello's preference
Revolutionary
  • Floating "island" button navigation
  • Personal Productivity-forward layout
  • Signals a new identity for Trello
  • High risk — unfamiliar to existing users
Design 2 — Atlassian's preference
Evolutionary
  • Traditional sidebar navigation
  • Project Management-forward layout
  • Familiar, consistent with Atlassian tools
  • Low risk — but low signal of change

"Can Design 1 support Split Screen for Personal Productivity, while still supporting current Project Management use cases — and also change perception of what Trello is?"

The real business question was harder: can Trello convince Atlassian that Design 1 is the right call? This wasn't just a usability test — it was research designed to resolve a genuine organizational disagreement under time pressure.

The research design

I couldn't afford a long study. The research had to be fast, credible, and persuasive enough to settle strong opinions. I designed a 3-phase comparative study.

1
Existing tasks
Participants completed familiar Trello tasks in each design, based on their screener responses.
2
Split Screen tasks
Participants navigated between Inbox, Planner, and a board using Split Screen in each design.
3
Overall perception
Participants reflected on their overall preference and what each design communicated about what Trello is.

Participant strategy — minimizing risk

The biggest objection to Design 1 was that existing project management users would reject it. I designed the sample as a risk/reward matrix to address this head-on.

5
S1 — Low Risk, High Return
Trello used only for personal productivity. Most likely to embrace Design 1.
6
S2 — High Risk, High Return
Trello used for both personal productivity and project management. The critical swing segment.
5
S4 — High Risk, Low Return
Trello used only for project management. Most likely to resist Design 1.

Results & impact

The initial assumption was that S4 (project management-only users) would strongly resist Design 1. The research showed otherwise.

Key findings

  • No strong preference between Design 1 and 2 for existing tasks — Design 1 didn't hurt current workflows.
  • Most participants preferred Design 1 for Split Screen tasks — it made the new features feel more natural.
  • Even S4 (PM-only users) showed less resistance than expected.
  • Design 1 clearly communicated that Trello was different — giving the product the identity signal it needed.

Organisational outcomes

  • Trello leadership approved Design 1 based on research findings.
  • Design 1 presented to Atlassian's senior Product leadership — approved.
  • I presented findings to Design leadership — approved.
  • Presented at the Trello Town Hall to build org-wide buy-in from all Trellists.
  • Design 1 shipped as the navigation for the new Trello — live for millions of users.
Case Study 2 of 3

A scalable quality bar for an entire product launch

Trello was releasing six feature areas simultaneously. With a hard deadline and a small team, I needed a method that was scalable, fast, actionable, and repeatable. The answer was a standardized SEQ-based usability framework.

What is SEQ?

The Single Ease Question (SEQ) is a validated 7-point scale created by Jeff Sauro at MeasuringU. After completing a task, participants answer: "On a scale of 1 to 7, how would you rate that task?" Scores below 5.5 signal a feature needs improvement before shipping.

1 – 5.4Needs improvement
5.5Target
5.6 – 7Performing well

The process

I worked with 6 PMs to align on 36 actions to test across all feature areas. Rather than 36 separate sessions, I combined related features to run 22 sessions total.

1
Align on actions
Worked with 6 PMs to define 36 actions — what needs to be testable before beta, accounting for web vs. desktop and iOS vs. Android.
2
Write realistic tasks
Tasks had to be broad enough for varied users but specific enough to test the right interaction — harder than it sounds.
3
Build a dummy environment
Created a realistic Trello environment so participants experienced features as real users, not as testers.
4
Collaborate with engineering
Worked directly with engineers to access dev tools and test unreleased feature states before production.

Actionable findings

📥

Inbox & Planner discoverability

Users didn't understand these surfaces are private and not tied to boards. Added copy to make this explicit.

🪞

Mirror Cards affordance

No visual signal that a Mirror Card had been created. Added confirmation affordance to close the feedback loop.

📋

Jira Lists setup

Users expected to see the "Reporter" field when setting up a Jira List. A missing field with a straightforward fix.

🔁

Repeatable framework

Created a step-by-step guide so PMs and designers could independently run SEQ studies on future iterations.

Research outcomes

  • Gave Trello leadership evidence that new features met the 5.5 SEQ bar before beta — a first for the team.
  • Product teams had specific, actionable fixes to ship before launch, not after.
  • Built a repeatable evaluation framework that teams could run independently — making research scale beyond my bandwidth.
  • SEQ scores held at or above 5.5 through GA, contributing to a 30k annual increase in monthly active users.
Case Study 3 of 3

The foundational JTBD program

The navigation study and the SEQ framework answered urgent questions. But as the team moved toward GA, a deeper question emerged: what do Trello's personal productivity users actually need to accomplish? Without a shared answer, every roadmap conversation would start from scratch.

I designed a 3-wave qualitative research program to map the full landscape of personal productivity goals — producing 33 Jobs to Be Done that became the foundation for product decisions, AI feature direction, and cross-team alignment at Atlassian.

What is a Job to Be Done?

A Job to Be Done describes why someone uses a product — the goal they're trying to achieve, not the task they're performing.

JTBD statement format
When _______ (situation),
I want to _______ (motivation),
So I can _______ (outcome).

For easier scanning across the program, I simplified statements to just the motivation and outcome — keeping the full format available in the detailed reports. This made the JTBDs immediately usable by PMs, designers, and engineers without needing to read an entire research report first.

Three phases, three waves

Personal productivity isn't a single moment — it's a cycle. I structured the research around the three phases of Trello's Feedback Loop framework, running one research wave per phase.

Wave 3
Capture
Create · Refine · Build Habits
J1 – J11, J30 – J33
Wave 1
Organize
Prioritize · Manage Time
J12 – J21
Wave 2
Get Shit Done
Complete · Track Progress · Reflect · Access Past Info
J22 – J29

Selected JTBDs from each wave

Capture phase — Create & Refine
How people gather and shape their tasks before acting on them
J1
I want to immediately capture thoughts or tasks to plan for them later so I don't lose focus on what I'm currently doing.
J3
I want to label tasks by categories to stay organised and avoid overwhelm.
J4
I need a clear way to mark urgency and importance for effective time prioritisation.
J7
I need help summarising and prioritising tasks and next steps from meetings or document reviews so I can act on them efficiently.
J9
I need to break work into subtasks to clarify the steps needed to complete something.
Organize phase — Prioritize & Manage Time
How people decide what to focus on and protect their time to do it
J12
I want to plan ahead so I can focus on what matters and maximise productivity.
J15
I want to rank work and household tasks by urgency to use my time effectively and ensure nothing is overlooked.
J17
I want to focus on what matters without burning out — balancing productivity with personal wellbeing.
J18
I want to protect my focus time to complete tasks without interruptions.
J21
I want help sticking to routines during disruptions to improve productivity and wellbeing.
Get Shit Done phase — Complete, Track & Reflect
How people execute tasks, stay motivated, and learn from what they've done
J23
I want to track progress to keep tasks moving and maintain momentum.
J24
I want to shift tasks across days so I can maintain a consistent workflow and adapt to changing priorities.
J25
I want a bird's-eye view so I can see how different parts of my work connect.
J28
I want to identify successful strategies and learn from mistakes so I can improve over time.
J29
I want a reliable way to find past information fast so I can make better decisions now.

How the JTBD program was used

The 33 Jobs to Be Done weren't filed away — they became the team's shared language for every product conversation that followed.

Program outcomes

  • AI directionThe JTBD knowledge base directly informed which problems AI in Trello should be built to solve — giving the AI team concrete user goals to design against rather than a blank canvas.
  • Recruiting toolJTBD statements became screener questions for future studies, ensuring participants were recruited against real user goals rather than demographic proxies.
  • Usability testingSEQ studies were structured around specific JTBDs, making scores directly interpretable: not just "this is hard" but "this fails to help users achieve J18."
  • Roadmap alignmentPMs and designers used the JTBD map to prioritise features — moving from "what should we build?" to "which jobs are we not yet solving?"
  • Knowledge basePublished as Trello's internal reference on Personal Productivity, synthesising JTBDs with academic literature and competitive analysis — referenced by teams across the product org.
  • Ecosystem mappingJTBDs were mapped against Atlassian's Teamwork Collection to identify where personal and team productivity intersect — informing Trello's place in the broader Atlassian ecosystem.

What I learned

Speed is a research design constraint

The question isn't just "what do users need?" — it's "what do we need to know, by when, with what confidence?" Designing for velocity changed every study.

🎯

Research that settles disagreements needs different design

The Split Screen study had to be persuasive to stakeholders with strong opinions — which shaped the participant strategy entirely.

🏗️

Scalable systems outlast individual studies

The SEQ framework, JTBD program, and self-service templates kept delivering value long after individual studies ended. Infrastructure is impact.

🌉

Research bridges strategy and execution

The pivot decision came from leadership. The validation that it was feasible, usable, and desirable — that came from research. Neither works without the other.