Data classification space settings

In order to avoid confusion between org and space defaults, the owning designer had split the experience across two screens, whereby a toggle acted as the entry point for the second screen.

Although it was a huge improvement on the existing experience, the toggle itself presented a new problem. When toggled one way, it acted as a gateway to a form with a save button. When toggled the other way, it acted according to standard usage guidelines, and immediately applied the configuration with no further fields or CTA's.

Given that admins needed to feel confident about what they were configuring, the experience needed a rethink; a setting that controls classification defaults across an entire space carries real consequences, and any ambiguity in how it behaved would erode trust quickly.

Due to time constraints, the team wasn't able to wait for the owning designer to return. I picked up where she left off, exploring various alternatives, before landing on a solution that was elegant and minimal scope, given that the engineering team were already in the build phase. The solution was adopted as the final design and is now the experience used by the Jira team for their data classification settings, with Confluence implementation to follow.

Building on my work establishing the classification calculation model, I became the primary owner for mapping how changes made in admin hub settings flow through to space-level settings across both Jira and Confluence.

The question was straightforward to state but complex to fully resolve: when an org admin changes a classification default, what does that mean for every possible space-level configuration state? I documented all key scenarios and exceptions, giving the Jira team a reliable reference for how admins could expect the system to behave regardless of how their settings were configured.