Guard Premium data classification settings: organisation default, space defaults, and related options.

Atlassian · Guard Premium

Data classification controls

A classification calculation model and admin settings for when multiple methods apply to the same data - unblocking delivery of autoclassification and related Guard Premium work.

Role: Product designer
Timeline: 2025-2026
Company: Atlassian

Background

Guard Premium is Atlassian's enterprise security product, used by their most regulated customers to protect the security and compliance of their Atlassian data.

A key Atlassian business objective was migrating enterprise customers from Data Center to Cloud ahead of its planned sunsetting - but Cloud was missing features that made the move a non-starter for these customers. One of the most significant gaps was the ability to automatically classify data by sensitivity.

Progress on this feature was blocked by a foundational problem: the classification system had no conflict resolution logic. Multiple classification methods could apply to the same content simultaneously, with no way to determine which should take precedence or be protected from change.

I devised a customisable classification calculation model that resolved these conflicts, and designed the settings UI that allowed admins to configure it according to their organisation's security and compliance needs.

Working sketch: four classification signals - org default, space default, manual label, and autoclassification - all pointing at one document with no resolution logic between them. — Conflict diagram: four classification signals on a single document before a clear classification calculation model existed.

Conceiving the concept model

I had been working on autoclassification for some time - delivering an initial scoped version for internal testing - when a problem the team had been deferring became unavoidable: with four different methods for classifying data, which should the system use, and who decides?

The prevailing view within the team was to establish a fixed hierarchy across all four methods. But customer calls consistently showed that different organisations needed different hierarchies - a fixed approach would work for some and fail others.

As I worked through how autoclassification settings might sit alongside the other necessary controls, I realised the team had been framing the problem wrong. The four classification methods weren't competing alternatives - they were two distinct types being treated as one. I proposed dividing them into two pairs, applied sequentially, with admins able to set the priority within each pair.

This reframe unlocked a model that was composable, predictable, and flexible enough to meet the range of needs we'd heard from customers.

UI mockup: four stacked settings cards - organisation default, space defaults, manual classification, and autoclassification - with handwritten annotations grouping container methods on one level and content methods on another, with arrows suggesting precedence. — Two-tier diagram: container methods on one level, content methods on the other - the concept in one spare image.

Challenge: Turning a new mental model into shared conviction

The concept model had the potential to fundamentally reframe how we thought about classification, but it was a big shift from the team's existing mental models, and it wasn't yet fully landing.

To make the logic concrete, I translated the model into a set of visual artefacts: each scenario rendered as nested rectangles - pages within spaces within the org - with colour indicating how classification resolved at each level based on different admin configurations. Where the model had previously struggled to gain traction, the visuals gave it a foothold - and the conversation could finally begin.

Scenario artefact: space default states with and without organisation default (working diagram).

Scenario artefact: organisation default and space-level panels used to align the team.

Scenario artefact: document with autoclassification callouts and classification shields.

Diagrams based on the original working artefacts I used to pitch the concept model to my design team, and later the cross-functional team. The originals covered every priority pair, created and presented in a figjam.

The shift from abstract debate to concrete scenarios gave the team something to test, challenge, and refine. What had been a circular discussion became a clear direction - and with it, shared conviction across design, engineering, and product that the model was both feasible and worth pursuing.

Validating the concept model and its technical feasibility

Once the team was aligned on the direction, the next step was to prove the model would hold up in practice. I formalised it into a comprehensive set of configurations, identifying nine distinct patterns and expanding each into detailed setups, concrete scenarios, and expected behaviours, mapped to the kinds of customer models they would best support.

Scenario: space default priority - org Internal, space admin sets Space A to Public; expected floor becomes Public; notes on trusting space admins. — Recreation of two of the scenario-based artefacts created for the Confluence document that became the reference for the whole team. There were 9 scenarios in total.

Scenario: org default priority - same setup; system blocks a default below Internal; Public struck through; notes on organisational minimums. — Recreation of two of the scenario-based artefacts created for the Confluence document that became the reference for the whole team. There were 9 scenarios in total.

This artefact became the basis for a focused engineering spike to stress-test the model against real implementation constraints. The spike confirmed the approach was technically sound and implementable, turning a shared mental model into a de-risked path to shipping.

See the classification calculation model in action, in this interactive calculator I built.

Open calculator in full window

Designing the settings

With the concept model approved, I needed to turn it into a configurable, trustworthy UI for admins. I designed the settings guided by three principles:

Surface the consequences. Configuration changes carry real risk across the org. At every step, admins needed clear, in-context feedback about the impact of their choices - any friction here was intentional, not a design flaw.
Expose the whole system at a glance. Because outcomes depend on how controls interact, admins needed a high-level view of how all settings work together, with the ability to adjust each one individually in a side panel that provides more detail.
Make dependencies visible. Where one control influences another, that relationship needed to be explicit in the interface, so admins could understand not just what they were changing, but what else it would affect.

Together, these principles turned a previously opaque system into one where admins could confidently predict, explain, and adjust classification outcomes.

End-to-end settings UI in Figma: zoom and pan to explore the org default setting, or change pages in the dropdown to see all the settings.

Outcomes

By reframing autoclassification around a clear concept model - and proving it through concrete scenarios, technical validation, and settings design - this work:

Resolved a cross-functional impasse on autoclassification and unblocked the team to move the feature into implementation, closing a critical Guard Premium gap for regulated customers moving from Data Center to Cloud.
Established a shared concept model for classification across design, product, and engineering; the visual artefacts and documentation served as the canonical reference for reasoning about configurations, trade-offs, and edge cases.
Created an extensible foundation for Guard Premium's classification controls, where new classification methods can slot into the model without revisiting the core logic - giving admins a predictable, explainable system and Atlassian a scalable way to meet evolving security and compliance needs in Cloud.