Case Study · UI Revamp
A UI-first rebuild of a dense SSO plugin into a Jira-native admin console for customer identity.
A dense SAML and OAuth plugin that read as bolted onto Jira, configuring sign-in for customers who have no internal help desk to complain to.
The six console areas I rebuilt ship in the customer single sign-on product for service management. Every install is a separate organisation, licensed in tiers reaching 100,000 users.
Atlassian Marketplace, vendor listings, August 2026Context
Jira Service Management help centers serve customers, not employees. I rebuilt a dense SAML and OAuth plugin into a Jira-native admin console that covers sign-in, organizations, portal access, and branding in one structure. Six 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
Admins here configure sign-in for people outside their company, so whatever they get wrong, a customer finds first. Break the same sign-in below for an employee and for a customer, and watch who absorbs the failure.
One sign-in configuration, two people who might hit it. Choose who signs in next, break the setup, and watch where the failure lands.
One sign-in configuration
Set up by an admin · fictional model
Who signs in next
The configuration
The admin ships it. Whoever signs in next inherits it.
What happens next
Help center SSO breaks outside the company. The customer gives up. Whatever the admin got wrong, a customer found it first.
No IT desk stands between this mistake and a customer. That is why the stakes are different.
Workforce SSO fails inward, toward an IT desk. Help center SSO fails outward, toward a customer. Every screen in this console lives with that difference.
Customer and vendor support conversations, support tickets, and stakeholder input were triangulated to separate identity-provider configuration problems from Jira configuration, portal access, mapping, and terminology confusion. That distinction is what shaped the more coherent, Jira-native administration experience.
Making the case
Identity work is abstract, and abstract arguments get settled by whoever is most senior rather than whoever is most right. These are the comparisons I used to move each decision out of opinion.
If the staff entrance jams, someone walks around to the front and mentions it. If the customer entrance jams, they go to the shop next door and you never learn their name or why they left.
So the product had to
Treat prevention and preview as the primary job, not recovery. Workforce sign-in fails toward an IT desk that will tell you. Customer sign-in fails toward someone with no channel to reach you at all.
A courier sorts on the pincode. The address decides which depot the parcel goes to long before a human reads the rest of it, and anybody can check the rule by looking at it.
So the product had to
A customer's email domain decides where they land, and the rule is legible at a glance rather than reconstructed from configuration fields. An access rule you have to derive is an access rule nobody audits.
Structure
Twelve console areas across three groups. They are grouped by the question an admin is answering, which is the decision that made the rest of the console arrangeable at all.
Where things live
One rule decided every placement: group by the question an admin is answering, never by the protocol underneath it.
Admins, during setup
Why here
SAML and OAuth are two answers to one question, so they share a structure. Grouping by protocol would have made the second setup feel like a new product.
Admins, before rollout
Why here
Signing in is half the job. The other half is whether the thing they arrive at looks like the company they thought they were contacting.
Admins, under pressure
Why here
The person who finds a broken customer sign-in is a customer, and they do not file tickets. So the admin has to be able to find it first.
The admin's side of it, followed end to end. The last step is the one the whole console is built around.
The journey, in plain words
4 stages
“This is the third provider we support. Why does each one feel like learning the product again?”
What the design does
SAML and OAuth share one console language, so the second setup is recognisably the same job as the first.
“If I get this wrong, someone sees another company's tickets and I will hear about it from them.”
What the design does
Make the rule readable at a glance rather than inferred from configuration fields, and flag a portal nobody can open.
Held back
This stage shaped the design but sits too close to the product to show. Happy to walk through it in conversation.
“I have no idea who this person is, whether they tried again, or whether they just gave up.”
What the design does
Preview and troubleshooting exist so the admin finds the break first. There is no support desk on the other side of this failure.
Every screen in this console is shaped by one fact: the person who suffers a mistake here does not work for the company that made it.
Ownership
Working one-on-one with product owners and alongside the developers who shipped each screen, I led the UI craft, the console structure, and the interaction design. Every control is keyboard-reachable and every state announced, so an admin using a screen reader can configure identity as confidently as anyone else.
Configurations
Portal settings
Status
Where the disagreement was
Every section had an owner with a different idea of what native meant, mostly at the level of colour and component.
How it resolved
I sat with them section by section and moved the definition from how it looks to how it behaves, which is where the actual work was and where the disagreements stopped.
Console patterns that look native are considerably more expensive than a form that merely works.
How it resolved
They were in the room while screens were still taking shape, so feasibility got resolved inside the design far more often than after it.
Complaints arrived as terminology confusion, which is easy to dismiss as documentation debt.
How it resolved
I separated identity-provider problems from Jira configuration, portal access, and mapping. Once split, most of the confusion turned out to be structural rather than verbal.
Impact
Before
After
Before
A plugin that looked bolted onto Jira
After
A console that follows Jira's patterns and chrome
Before
One identity provider assumed
After
Search, filters, and pagination for a fleet
Before
Access rules hidden in configuration fields
After
Organization and portal access readable at a glance
The product stopped reading as a third-party tool, following Jira's patterns, chrome, and behavior.
SAML and OAuth share the same console language, so the second setup already feels familiar.
Organization rules, portal access, and branding decide what each customer sees, previewable before rollout.
Customer feedback
Direct appreciation for the interface and workflow clarity of the Jira-native customer SSO console.
Judgment
The hard part was what native actually means: matching Jira’s look took a component library, matching its manners took most of the design work. Product owners sat with me one-on-one for every section and developers were behind each screen while it was still taking shape, so feasibility was resolved in the design far more often than after it.
The plugin already had the depth. The new console made it operable.
Next Project
OAuth/OIDC SSO for Atlassian Data Center →