Atlassian Change Pipelines
Helping admins review and promote app updates across environments
Role
Senior Product Designer
Team
Lead Product Designer, PM and engineer
Outcome
Positively received at Team ’26 Europe; research confirmed the pipeline model and the impact view
Summary
Change in Atlassian admin was becoming continuous, but the experience wasn’t. I designed a pipeline that shows where a change is, what it means and what to do next, starting with Atlassian app updates. I did the hands-on design, the user research and functional prototypes. The first release isn’t available to customers yet.
How I helped turn a broad change-management vision into a focused first release.
Change was becoming continuous. The experience wasn’t.
For administrators, change can come from different directions — product updates, configuration changes, and the work of moving changes safely across environments.
The opportunity was bigger than automating promotion. It was about helping teams understand what was changing, why it mattered, where it was, and what to do next.
What I focused on
Creating a clear mental model for change across environments.
Turning release information into something actionable.
Designing a first release that could grow as the underlying capabilities evolved.
Pipeline setup starts with a short overview of how stages work, so admins understand the model before configuring anything.
From a broad vision to a focused first release
I approached the problem from the structure of the experience rather than from individual screens.
The pipeline needed to answer three questions:
Where is the change?
What does it mean?
What can I do about it?
Creating the pipeline
The creation flow established the essential structure without turning the first step into a configuration exercise.
Choosing the production site and apps, with a recommended Jira family selection, then defining the stages, each one a separate sandbox.
The pipeline canvas: Dev → Staging → Production. Selecting a stage narrows the list to the app updates relevant there, grouped by impact.
Change detail: why an update has high impact, what it affects and where it sits in the pipeline, with promotion as the next step.
Selecting app updates to promote together to the next stage.
A pipeline became the user's mental model.
The canvas made the progression of change visible:
Development → Staging → Production
Selecting an environment narrowed the experience to the changes relevant to that stage.
Instead of treating the pipeline as a transport mechanism, I designed it as a place to understand change before acting on it.
Exploring interactions through functional prototypes
I used Replit and Cursor to explore interaction models and build functional prototypes. Working iteratively with AI tools helped me try out different approaches and understand how the experience behaved beyond individual screens.
From release note to promotion decision.
The pipeline becomes useful when users can connect a product update with the environment where they are testing it.
For App Updates, the experience connects release information → impact → pipeline context → promotion.
The goal was to turn a release note into an operational decision point.
Designing for the decision, not just the information.
The change detail brings together the information needed to decide whether an update is ready to move forward:
• impact
• context
• rollout status
• current environment
• promotion state
The result is a clearer decision point: understand the change first, then decide whether to promote it.
One pipeline, different kinds of change.
The first release focused on Atlassian App Updates. But the broader concept explored how the same pipeline model could support different kinds of change, including organization-controlled configuration changes.
Each required different information: App Updates needed impact, release context and rollout status; configuration changes needed detailed diffs, dependencies and affected scope.
The goal was not to make them identical, but to give them a coherent place in the same operational model.
The broader model depended on reliable configuration-diff capabilities. For the initial release, those capabilities weren't ready enough to support the experience we had designed.
Rather than forcing them into the first release, we focused on what could be reliably delivered: Atlassian App Updates.
The technology changed the timing, not the direction.
Where it stands
The first release was shown publicly for the first time at Atlassian Team ‘26 Europe in October 2026. It isn’t available to customers yet, and the team is working on the next iterations.
How we’ll know it works
The pipeline is meant to help admins understand a change before they promote it. So success is less about how many updates move through it, and more about whether they move with confidence:
More app updates reviewed in a test environment before reaching production.
Less time from a release note to a promotion decision.
Fewer rollbacks and support tickets caused by unexpected changes.
What research told us
I tested a more advanced prototype that already combined Atlassian app updates with configuration changes coming from the customer’s own organisation. Three findings are shaping the next releases:
The source of a change has to be obvious. In the prototype, the difference between Atlassian updates and the organisation’s own configuration changes wasn’t clear enough. Every change needs to say plainly where it came from.
Freeze windows belong on the canvas. Participants raised the need to see freeze windows in the pipeline view. The team was already planning this, so research confirmed the direction rather than changing it.
Showing impact works. Seeing the impact of a change and what it affects was one of the most positively received parts of the experience.
What I learned
• The hardest part was defining the right abstraction. The product wasn’t just about moving changes between environments.
• Constraints can sharpen a first release. The goal isn’t always to fit the whole vision into version one, but to preserve the right foundation for what comes next.
• Designing for growth starts with the model. A focused first release can still preserve a broader direction.
More from the setup flow and the pipeline, including the review step and the full app update page.
Previous project
Next project