Case Study · Research
Reducing the complexity of enterprise authentication setup without reducing enterprise control.
Admins could not tell a failed connection from an incomplete setup. The enterprise depth that won deals had turned into configuration friction.
The ten-area structure I designed ships in the single sign-on product for Atlassian Data Center. Every install is a separate organisation, on listings licensed in tiers reaching 150,000 users.
Atlassian Marketplace, vendor listings, August 2026OAuth and OpenID Connect configuration gives administrators significant control, but that flexibility can quickly become overwhelming when setup, provider management, mapping, validation, and advanced settings compete for attention.
I led a research-driven product revamp that kept the product’s enterprise depth while making complex SSO configuration easier to understand, test, and trust.
Confidentiality note
Due to NDA restrictions, every product interface here is an anonymized, white-labelled recreation. Customer details, credentials, and business data have been removed while preserving the product logic and UX decisions.
Context
The product supported complex enterprise authentication requirements, but important actions, technical fields, provider setup, testing, mapping, and advanced settings competed for attention. Underneath the friction sat one problem: administrators had to think too much before they could act with confidence.
Why This Direction
The direction came from converging evidence, not instinct: several independent sources pointed to the same setup-confidence problem.
Converges to
Validated setup-confidence problem
Reported setup problem
Diagnosed as
Technical failure
Configuration issue
Terminology or discoverability
Missing workflow or capability
Switch products to compare how each one structures the same setup job. Competitors are shown with neutral labels.
Setup architecture
The opportunity was not to copy a competitor. It was to combine configuration depth with clearer task progression.
Pick what the redesign reduces, then apply the audit principles and watch what setup feels like.
OAuth/OIDC provider setup
Data Center · configured by an administrator
Simplification path
The flexibility gives administrators control. Choose what the redesign reduces.
Redesign principles
Each switch applies one principle from the audit.
What setup feels like0 of 6 principles applied
Every enterprise capability is here, but administrators must understand the system before they can act with confidence. Provider setup, testing, mapping, validation, and advanced settings all compete for attention.
This is what the audit found. Apply the redesign principles to change what setup feels like.
The challenge was not reducing the product's capabilities. It was reducing the effort required to understand and configure them.
Organize the product around what administrators are trying to complete, not around how the backend stores settings.
Keep common setup steps visible and move advanced controls into the right context.
Keep provider details, mapping context, setup guidance, and validation visible when decisions are made.
Make system status, required fields, testing, success states, and errors clear before administrators move forward.
Making the case
Enterprise authentication is argued in vocabulary most of the room does not share, which is how a design discussion quietly becomes a seniority contest. Each of these comparisons put the decision back in reach of everybody in it.
A chemist who arranges the shelves by manufacturer rather than by ailment. Every medicine is present, correctly labelled, and perfectly organised, and you still cannot find anything for a headache without asking.
So the product had to
Organise around what an admin is trying to complete, not around how the backend stores settings. Ten task-first areas that follow selection, configuration, mapping, testing, and troubleshooting.
A new gas connection is pressure-tested before anyone lights a stove on it. Nobody wants the first proof that it works to be a person using it.
So the product had to
Make testing part of the setup journey with idle, testing, failed, and passed as visible states. Saving without an error is not the same as working, and the old product could not tell an admin the difference.
The journey
Most admins configure SSO once, under time pressure, with the whole company's ability to log in resting on it. That is the emotional shape the structure had to hold.
The journey, in plain words
4 stages
“If I get this wrong, nobody in the company can log in tomorrow morning. Including me.”
What the design does
Start with choosing a provider rather than with a form, so the first screen is a decision they can actually make.
“I do not know what half of these mean, and the help is in a different tab.”
What the design does
Keep provider details, mapping context, and guidance visible at the point the decision is made instead of one tab away.
Held back
This stage shaped the design but sits too close to the product to show. Happy to walk through it in conversation.
“It saved without complaining. That is not the same as it working, and I cannot tell the difference.”
What the design does
Make testing part of the setup journey with explicit idle, testing, failed, and passed states, so readiness is shown rather than assumed.
Nobody in this journey wants to master the product. They want to stop being responsible for it, which is a very different thing to design toward.
Ownership
I owned this end to end as the Senior Product Designer: the UX audit and competitive analysis, the information architecture, and the interaction design for every administrator task, aligned with stakeholders so the direction held up beyond my own preference.
Before, Settings-first
After, Task-first, 10 areas
Where the disagreement was
The obvious response to a product being called complex is to remove things from it, and that pressure was real.
How it resolved
I separated capability from comprehensibility. The depth was the reason enterprises chose the product, so the target became the effort of understanding it, never the feature count.
Validation, testing, and readiness states promise behaviour the backend has to actually enforce.
How it resolved
States were shaped with the engineers who would build them, so the interface never claimed a guarantee the product could not keep. Feasibility got resolved inside the design rather than after it.
Their evidence arrived as a stream of complaints, which is easy to hear as noise rather than signal.
How it resolved
I routed every reported problem through a root-cause split before acting on it, separating technical failure from configuration, terminology, and genuinely missing capability.
Where things live
One rule decided every placement: follow the order an admin actually works in: choose, configure, decide who gets what, then prove it works.
An admin with no prior context
Why here
This is the only part done cold, usually once, often by someone who has never seen the product. It carries the most explanation because it can assume the least.
An admin making policy
Why here
These look like settings and behave like policy. Scattered across backend groups they were being set by whoever happened to be in the screen, rather than decided.
An admin who has to be sure
Why here
An admin cannot tell a failed connection from an incomplete setup by looking at a form. Proof needed somewhere to live, or it stays a guess.
The same structure, at full resolution. Ten areas, and what lives inside each one.
Browse the ten top-level areas and what lives inside each one.
Give administrators a clear view of setup progress and configuration health.
The setup journey the structure follows
The structure follows the administrator's journey, not the backend's storage model.
Eight administrator tasks I designed, recreated as white-labelled interactive models with fictional data.
Search, filter, and select an identity provider to begin a guided setup.
Switch the application template and watch the form adapt while the structure stays predictable.
Complete the missing value, run the test, and watch readiness change.
Map identity provider groups to Atlassian groups, in bulk or one at a time.
Change sign-in settings and watch the login screen respond in the live preview.
Step through what happens between login and logout, and change the settings that shape it.
Dependent fields block an unsafe save and explain the recovery.
Test, enable, and delete providers, then export the audit trail, with confirmation and undo where it matters.
From design to implementation
From design to implementation
Validation, testing, and error states were shaped with the engineers who would build them, so the interface only promised what the product could enforce.
Each control's states, idle, testing, failed, passed, and blocked, were specified so behavior was unambiguous at build time.
The screens share a single set of buttons, toggles, selects, banners, and lozenges, so patterns stay consistent across the whole setup journey.
Collaborated with engineers to align interaction behavior, reusable components, and implementation constraints.
From evidence to decision
Evidence
Support-driven failure patterns, a configuration audit, and a task-flow review of the existing setup.
Pattern
Administrators could not tell an incomplete configuration from a failed connection.
Design implication
Setup states and a testing checkpoint had to be explicit, not inferred.
Decision
Introduced required-field validation and a guided test step with idle, testing, failed, and passed states.
Evidence
Heuristic evaluation and a navigation review of the settings-first structure.
Pattern
Related tasks were scattered across backend settings groups, so admins lost their place mid-setup.
Design implication
The product needed to be organized around the administrator's journey, not the data model.
Decision
Restructured into ten task-first areas that follow provider selection, configuration, mapping, testing, and troubleshooting.
Evidence
An error-prevention review of destructive and dependent security fields.
Pattern
A wrong save could lock admins out or leave an unsafe state with no clear recovery.
Design implication
Dangerous actions needed to be reversible and to block an unsafe save with a reason.
Decision
Dependent fields block the save and explain the fix, and destructive actions confirm and offer undo.
Impact
The restructure changed the shape of the work, from settings-first navigation to a task-first setup journey administrators could move through with confidence.
Before
After
Before
Settings-first navigation
After
Task-first setup journey
Before
Long, ungrouped forms
After
Contextual sections and progressive disclosure
Before
Unclear system status
After
Visible validation, testing, and readiness states
Before
Manual recovery from mistakes
After
Error prevention and reversible actions
Converted heuristic findings, product flows, and competitive patterns into a clear UX strategy.
Reorganized a configuration-heavy product around administrator tasks and setup progression.
Designed to make required actions, validation, testing, and system feedback easier to understand.
Created an information architecture that could support more providers, mappings, and advanced settings without increasing navigation confusion.
Customer feedback
Direct appreciation for the redesigned interface and workflow clarity of the OAuth/OIDC setup.
Signal typeMeasuredObservedIntendedFuture
A task-first information architecture of ten areas and eight guided walkthroughs, rebuilt as operable recreations.
Explicit validation, testing, and readiness states were designed to let admins know a configuration is ready before they rely on it.
Share of setups that reach a passed test before activation.
Completion rate of first-time setup and the volume of setup-related support tickets.
Judgment
The hardest call was resisting the urge to strip features. The product’s depth was the reason enterprises chose it, so the work was to reduce the effort required to understand and configure that depth, not the depth itself. I used the research findings as a shared rationale rather than personal preference, which kept product and UX decisions aligned.
Mature Data Center ecosystem
Cloud transition announced
Enterprise demand remains significant
Product quality stays commercially important
The product kept its depth. The experience became easier to navigate, validate, and trust.
Next Project
Identity & Access Governance via JSM →