Case Study · UI Revamp
A UI revamp that turned identity lifecycle plumbing into a guided, observable admin console.
SCIM fails silently. A misconfiguration means a new hire waits days for access, or someone who left keeps theirs, and nothing anywhere says so.
The gated, guided console I designed ships in the user provisioning product: setup cannot start broken, and the sync shows its work. Every install is a separate organisation, licensed in tiers reaching 150,000 users.
Atlassian Marketplace, vendor listings, August 2026SCIM provisioning keeps Jira’s directory in step with the identity provider: accounts exist on day one, groups stay current, and leavers lose access the moment they leave. It works best when nobody has to think about it.
Context
The product already had the capability. The old interface simply trusted the admin to prevent the quiet failures: to know the setup order, to find the endpoint details in the docs, and to assume the sync was working. Direct customer access was limited, so I triangulated across the evidence I could reach.
Converges to
Setup-confidence gaps
So I rebuilt the admin console into a gated, guided, and observable experience. Four of its areas are recreated below as working interfaces you can operate yourself.
Confidentiality note. Due to NDA restrictions, the interfaces here are anonymized, white-labelled recreations with fictional companies and data. The product logic and UX decisions are preserved.
Why
When provisioning is misconfigured, nothing crashes. A new hire waits days for an account, or an ex-employee keeps one, and that second failure is a security incident.
Pick a directory event, then switch the revamp's guardrails off and on. The provisioning outcome rewrites itself, quietly.
Identity provider sync
SCIM · keeps Jira’s directory in step
Directory event
Console guardrails
The revamp’s three moves. Switch them off to feel the old console.
Provisioning outcome
Access is removed the moment they leave, so the directory stays right. The request, its result, and any failure sit in the filterable audit log.
Old console trusted the admin to
The revamped console
Nothing in the failure states crashes. That is the point: the console's job is to make quiet failure either loud or impossible.
Making the case
Provisioning is invisible by design, which makes it very hard to argue about. Every time the discussion stalled, it was because people were picturing different failures. Attaching each requirement to something everyone had already lived through ended that.
When someone moves out of a housing society, the guard does not just strike their name off the register. The gate card is deactivated that evening. The register is the record. The card is the actual access, and only one of them stops anybody.
So the product had to
Treat removal from the directory and removal of access as one event rather than two that usually happen close together. A leaver who still has a working account is not a data mismatch, it is an open door.
A passport application will not let you book an appointment until your documents clear a checklist. It feels obstructive right up until you picture the alternative, which is travelling to the centre, waiting, and being turned away at the counter.
So the product had to
Refuse to open application setup until credentials and the site are verified. Blocking the start costs a minute. Discovering the same problem after the sync has silently done nothing for a week costs an onboarding.
Structure
The console has five areas, but only one organising idea. Once that was agreed, most layout arguments answered themselves.
Where things live
One rule decided every placement: the console follows the order the work actually happens in, not the order the features were built.
The admin, once
Why here
An application configured on unverified credentials does not fail here. It fails quietly, weeks later, and by then nobody connects the two events.
The admin, occasionally
Why here
This is where admins actually spend their attention, and where guessing was quietly generating support tickets.
The admin, under pressure
Why here
Trust in automation is rebuilt with evidence, not reassurance. This area exists for the worst day, not the average one.
An admin touches this console a handful of times in a year, usually under pressure, and never becomes an expert in it. That shaped every step below.
The journey, in plain words
4 stages
“I have done this on another tool, not this one, and I really do not want to break logins today.”
What the design does
Hold application setup shut until the credentials behind it are verified, so the first possible mistake is one they cannot make.
“Where do I get this token, and is that the URL they mean or the other one?”
What the design does
Put the endpoint details next to the field that needs them, copy-ready, instead of in a documentation tab.
Held back
This stage shaped the design but sits too close to the product to show. Happy to walk through it in conversation.
“Did it fail, or did it never even try? Those are very different problems.”
What the design does
A filterable log that separates failed from never attempted, because the fix for each one is completely different.
Nobody in this journey wants to learn the product. They want to stop thinking about it, which is a very specific thing to design for.
Ownership
This was mine to shape end to end: the UI revamp, the guided setup flows, the interaction design, and the working prototype. I structured the console as five areas that form one operating loop, and worked through it screen by screen with the product owner and the engineers building it.
Validate prerequisites
Setup cannot start broken
Guide configuration
A three-step wizard
Show sync status
Filterable audit logs
Support recovery
Backup and restore
Where the disagreement was
Gating setup looked like adding friction to a flow support was already being asked to shorten.
How it resolved
I separated the two kinds of friction. Time spent before anything is connected is cheap. Time spent debugging a sync that silently never ran is what generates the tickets.
Surfacing every provisioning request meant designing for failure states that had never been rendered anywhere.
How it resolved
We agreed the log was the smallest honest version of observability, and shipped filters rather than dashboards so the scope stayed proportionate.
Closest to the pain, furthest from the roadmap. Their evidence was anecdotal and easy to discount.
How it resolved
I treated their ticket themes as one of five research sources rather than the only one, which made the pattern harder to argue with than any single account.
The walkthroughs below cover four of these areas end to end, with the same Atlassian-native chrome the shipped console uses. Operate them yourself, in the order the loop runs.
The gate: credentials and site URL are validated here before any application can exist.
Pick a provider, choose an integration method, and walk the three-step wizard to a working application.
Every provisioning request, filterable by status and application.
Move configurations between instances with an export and an import.
Impact
The revamp was designed to reduce setup confusion and give admins automation they could audit instead of assume. Each of the three decisions behind it cost something, and naming the cost was how they got agreed rather than revisited.
Application setup stays locked until credentials and the site URL are verified, so the most expensive mistake becomes unreachable rather than well explained.
Cost: the first run feels slower and more restrictive. Accepted, because the alternative failure surfaces days later as a person without access.
A single long configuration page became three steps per application, each explaining the decision at the point it is made.
Cost: more clicks for an expert who already knows the answers. Accepted, because the console is used a handful of times by each admin, never daily.
Every provisioning request, result, and failure became visible and filterable rather than running invisibly in the background.
Cost: exposing failures makes a working product look busier. Accepted, because silent success and silent failure are indistinguishable, and that is the actual problem.
Before
Setup order left to the admin to guess
After
Prerequisites gated, with a clear path to complete them
Before
One long configuration form
After
A guided three-step wizard per application
Before
Provisioning ran invisibly
After
Every request in a filterable audit log
The admin gate holds back application setup until credentials and the site URL are verified.
Application setup became three steps with copy-ready endpoint details.
Every provisioning request, result, and failure is visible and filterable.
Judgment
Gating setup felt restrictive on the whiteboard. In practice it is the kindest thing the console does: it makes the wrong order impossible instead of documenting it.
The automation was already reliable. The revamp set out to make it trustworthy.