Case Study · Research
Reducing the complexity of enterprise authentication setup without reducing enterprise control.
OAuth 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.
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
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
Customer SSO for Jira Service Management →