A UX CASE STUDY • Solo academic project
Scaling Design at Atlassian
Designing the systems, standards, and shared infrastructure that help distributed product teams work consistently at scale.
Atlassian’s products span interconnected workflows across Jira, Confluence, Loom, Rovo, and more. I explored what it takes to support that complexity from a DesignOps perspective, from organizational structure and team practices to design system foundations and reusable components.
PROJECT SNAPSHOT
ROLE
Product Designer & DesignOps Strategist
TIMELINE
9 Weeks
TOOLS
Figma, FigJam, Confluence, Jira, Loom, Rovo
Organizational research, operating model design, design principles, career ladder development, design system audit, foundations, component design, documentation, and AI strategy
RESPONSIBILITIES
PROJECT TYPE
Solo academic DesignOps project
As Atlassian grows across products, teams, and AI-enabled workflows, design decisions become increasingly distributed. Without strong shared systems, that flexibility can lead to inconsistent patterns, duplicated work, and fragmented experiences across products.
PROblem statement
How might we help distributed product teams work from shared standards while preserving the autonomy they need to solve product-specific problems?
Design question
Understanding How Design Operates at Atlassian
Research
I started by looking at Atlassian from three angles: the company’s strategic priorities, how product teams were staffed, and how design resources were organized around those teams. Enterprise, AI, and the System of Work were pushing Atlassian toward more connected products, while day-to-day decisions still happened within embedded cross-functional teams.
The research showed that Atlassian already relied on embedded teams, so the opportunity was not to redesign how those teams worked. Instead, I focused on strengthening the shared systems around them so teams could stay flexible without creating unnecessary inconsistency across the organization.
Defining What Should Be Shared
Operating model
I translated that research into a hybrid operating model. Designers remained embedded with product and engineering, while a central DesignOps core supported teams through shared systems, documentation, accessibility, tooling, and design standards
The model kept product decisions close to the teams with the most context while centralizing the resources that became more valuable when they were shared across the organization.
Design principles
Turning the Model Into Guidance
The operating model clarified where support should live, but teams still needed a shared way to make decisions. I developed four principles to guide how designers could work across products while still adapting to the needs of their own teams and users.
Together, the principles gave teams a common starting point without prescribing one process. They emphasized visibility, connected workflows, reuse before reinvention, and building quality into the systems that other work depends on.
Career ladders
Understanding Roles, Responsibilities, and Growth
Career ladders make expectations clearer across roles and levels. Atlassian’s design ladder separates growth into a P track for individual contributors and an M track for people managers, giving designers two ways to advance as their scope and influence increase. Progression does not require moving into management, so designers can continue growing as individual contributors while the M track supports those who choose to lead through teams.
What stood out to me was how much clarity the ladder created around expectations that can otherwise feel vague. Making those expectations explicit gives designers a clearer sense of what they are working toward, where they can grow, and how progression can happen without relying only on tenure or title changes.
Design system audit
Auditing Where Consistency Breaks Down
After looking at how Atlassian supports design at the organizational level, I moved into the product experience itself. I audited Jira and Confluence workflows to see how shared components and patterns were being used in context, looking closely at hierarchy, spacing, iconography, component intent, and cross-product consistency.
The audit showed that shared patterns still varied across products and that component intent was not always communicated clearly. I also noticed that Loom and Rovo entry points often relied on users recognizing the brand rather than clearly communicating what would happen next.
Foundations
Building A Stronger Foundation
The audit gave me a clearer sense of where inconsistencies were showing up, so I moved into the foundational rules behind those interfaces. I defined and documented color, typography, spacing, radius, iconography, and elevation to create a more consistent base for the components that followed.
Components
Building Reusable Patterns
With the foundations in place, I used them to build a reusable component library. I focused on the patterns that appeared most often across the workflows I had audited, defining states, variants, accessibility behavior, and usage guidance so they could be applied more consistently.
Version notes
Iterating the System
As I moved through critique, I used the feedback to revisit the system rather than treating each comment as an isolated fix. I updated typography, spacing, icon guidance, component behavior, documentation, and several interaction details so the library became more consistent as a whole.
AI strategy
Scaling the System with AI
As AI becomes more embedded in design workflows, the quality of the system behind it becomes even more important. Clear foundations, reusable components, and structured documentation give AI stronger constraints to work from and help keep generated work aligned with the broader product system. As production gets faster, designers can spend more time on problem framing, context, critique, and deciding when the system should adapt.
Reflection
What Scaling Design Actually Requires
What stood out most was how connected each layer became. Organizational choices shaped how teams worked, shared guidance influenced how decisions were made, and the design system turned those decisions into something reusable. I came away seeing DesignOps less as a collection of processes and more as the connective layer that helps people, practices, and products work together as an organization grows.
This project changed how I think about scale. I started by looking at team structure and shared resources, but the work made it clear that scaling design depends on much more than organization alone. It also depends on clear principles, visible expectations, strong foundations, reusable components, and documentation that helps teams make better decisions.