Making identity connections visible, guided and manageable.
Asgardeo users could configure social and enterprise identity providers, but the Connections experience did not clearly show what was enabled, what was merely available, or what required attention. I audited and redesigned the feature for v4—clarifying status, repairing discovery and filtering, guiding setup step by step, and creating a visual bridge for the product's next two interface generations.
Increase in interface and experience issues surfaced through the UX audit
Improvement in user satisfaction after the Connections enhancement
Research, interaction design and implementation support for the shipped redesign
Reusable interaction and component foundation for later product versions
Section 1 of 9Context
Context
An identity platform problem disguised as a card-grid problem.
Asgardeo is WSO2's B2B/B2C identity platform. Its Connections feature lets application teams configure identity providers such as Google, Microsoft, Facebook and GitHub. These integrations are technically complex, but the interface also created avoidable uncertainty before users reached the technical work.
The problem
The original experience hid the information users needed most.
Connection state was ambiguous
Users could not confidently distinguish configured, enabled, disabled and unconfigured providers. A provider's visual presence did not communicate its operational state.
Search and filtering did not support the task
The controls did not reliably help users isolate a provider type or locate a specific connection, leaving them to scan the page manually.
Setup guidance was fragmented
Configuration required users to move between product forms and external documentation without a clear sense of sequence, progress or completion.
Management and destructive actions lacked clarity
Editing instances, reviewing connected applications and deleting a connection were not organised around a coherent management model.
A larger product migration was approaching
An abrupt shift to the next visual system risked forcing users to relearn the interface. The redesign needed to solve today's usability issues while preparing users for v5 and v6.
The challenge was not simply to modernise the screen. It was to make a technically dense workflow legible at every state without breaking the user's existing mental model.
Process
A Double Diamond adapted for a live product redesign.
The work moved from evidence gathering to problem framing, then into a focused redesign and product delivery. The framework provided structure, while release constraints required continuous alignment between discovery, design and implementation.
Discover
UX audit, interaction review, user research and Lighthouse assessment across performance, contrast and accessibility.
Define
Prioritise ambiguity, discoverability, setup continuity, management structure and migration risk.
Develop
Explore status-rich cards, functional filters, progressive setup guidance, consolidated management and safer deletion.
Deliver
Support implementation of v4 and establish reusable patterns that could bridge users into v5 and v6.
UX audit
The audit shifted the conversation from visual polish to operational comprehension.
The review examined whether users could understand the system's state, find the right provider, complete setup, recover context and manage an existing connection. Lighthouse was used alongside the UX review to surface performance, contrast and accessibility issues.
Audit lenses
Could users tell what was available, configured, enabled or connected to an application?
Did search and filtering reduce the effort required to locate a specific identity provider or instance?
Could users progress through an OAuth setup without losing sequence or relying on memory?
Did contrast, content hierarchy and interaction states remain perceivable and understandable?
Did the page and interaction model introduce avoidable performance friction?
Could new interface patterns be introduced without making existing users feel displaced?
Users needed answers before actions.
The page prioritised provider availability, while users first needed to know: What have I configured? Is it active? Where is it used? What should I do next?
Design around lifecycle state
Connections were reframed as a lifecycle—discover, configure, activate, connect, manage and remove—rather than a collection of undifferentiated provider cards.
Recognition failure
The interface required users to remember which providers they had configured rather than making the state visible.
Context switching
Users had to divide attention between Asgardeo, provider consoles and documentation without persistent progress cues.
Change shock
Introducing an entirely new UI language at once could make familiar workflows feel unfamiliar and increase support burden.
Definition
Reframing the design problem around confidence.
The redesign needed to let users understand a connection's state, complete configuration and return to manage it without depending on memory, external explanation or abrupt interface changes.
How might we make every connection's state and next action obvious while simplifying setup and preserving continuity across product versions?
Users should be able to identify configured providers, narrow the list, follow setup in sequence, switch between instances, inspect connected applications and confirm destructive actions with confidence.
Design principles
State before action
Show configuration, enablement and usage status before asking the user to create, edit or delete.
Guidance in context
Bring prerequisites, provider-specific instructions and progress into the setup surface.
One management model
Organise metadata, credentials and connected apps within a predictable tabbed structure.
Progressive familiarity
Introduce the next design system through familiar workflows rather than requiring users to absorb all changes at once.
Before / after logic
| Area | Before | After |
|---|---|---|
| Provider state | Presence implied availability, not operational state | Toggle, configured-instance count and connected-app count expose state |
| Discovery | Search and filters did not reliably narrow the task | Search plus explicit category chips establish a usable taxonomy |
| Setup | External documentation and forms felt disconnected | Persistent guide, progress and provider prerequisites remain in view |
| Management | Connection details were fragmented | General, Settings and Connected Apps form one management model |
| Deletion | Destructive intent was insufficiently gated | Explicit acknowledgement enables the final destructive action |
Redesign
Five redesign moves turned a provider catalogue into a manageable lifecycle.
Each intervention addresses a specific point of uncertainty while reinforcing a shared interaction model across the feature.
Expose state at the overview level
The redesigned cards distinguish configured and unconfigured integrations, show instance and connected-application counts, surface the enablement toggle, and place Create, Edit and Setup Guide actions where the state is visible.
Turn setup documentation into a guided sequence
A persistent side guide gives users prerequisites, a copyable redirect URI, provider-specific documentation and a clear sequence. A progress indicator and previous/next controls show where they are and what remains.
Make multiple configured instances navigable
The instance switcher lets users see which configured connection is active and move between alternatives without returning to the catalogue. The selected item is highlighted, reinforcing current context.
Unify ongoing management
General, Settings and Connected Apps tabs separate concerns without scattering the user across unrelated pages. Credentials, redirect URI, scopes and application relationships remain part of one connection object.
Make destructive intent explicit
The delete confirmation explains irreversibility, requires an acknowledgement checkbox, and keeps the primary destructive action disabled until the user confirms intent.
Delivery
v4 solved the immediate workflow and became a migration bridge.
The redesign introduced new visual and interaction components inside a familiar product task. This gave users time to build familiarity before broader interface changes arrived in v5 and v6.
Lower migration shock
New UI patterns appeared through a task users already understood instead of arriving as an unrelated redesign.
Reusable system
Status cards, setup steps, management tabs and destructive-action patterns could scale beyond one provider.
Contextual documentation
Provider guidance and direct documentation links became part of the workflow rather than a separate discovery problem.
Impact
The result was both a feature improvement and a product-transition asset.
The strongest outcome was not a single screen. It was a clearer connection lifecycle that shipped in v4 and established patterns for later interface generations.
More issues surfaced
The UX audit increased the identification of interface and experience issues, expanding the evidence available for prioritisation.
Reported internship metric. The original denominator and measurement procedure should be added when recovered.Higher satisfaction
User satisfaction improved after the Connections enhancement reached the product.
Reported product outcome. Add the original survey instrument, sample and baseline before publication where possible.Delivered to product
The research and redesign were implemented as the fourth version of the Connections experience.
Shipped outcome supported by the supplied high-fidelity product artifacts.Extended beyond the release
The information architecture and component patterns provided a scalable bridge into two subsequent product versions.
Strategic outcome based on the redesign's continued use as a transition foundation.- Connection status became visible at overview level.
- Search and category filters were redesigned around provider discovery.
- Setup gained persistent guidance and progress.
- Multiple instances became directly switchable.
- Management was consolidated into a reusable tab pattern.
- Deletion gained explicit error-prevention controls.
- New components were introduced through an existing workflow.
- The design supported multiple social and enterprise providers.
- Patterns could expand across later product versions.
- Documentation became easier to find at the moment of need.
- The project linked usability improvement with product migration.
Reflection
What I would preserve—and what I would document more rigorously now.
This remains a useful case study because it demonstrates shipped product thinking, but the absence of the original research repository limits how precisely some historical metrics can be reconstructed.
Evidence retained
- Production-oriented high-fidelity screens across discovery, setup, management and deletion.
- Reported +33% issue-discovery and +20% satisfaction outcomes.
- Confirmation that the redesign reached v4.
- Continued relevance as a bridge for v5 and v6.
- Clear rationale connecting each UI pattern to a known usability problem.
Evidence to recover
- Research participant count and recruitment profile.
- Task-based usability metrics and quotes.
- Original Lighthouse performance, accessibility and contrast scores.
- Definition and baseline behind the 33% metric.
- Satisfaction instrument, sample and timing behind the 20% metric.
- Exact project duration and cross-functional team composition.
State clarity is core functionality
In configuration products, status is not metadata. It determines whether users can make the next decision safely.
Documentation can be interaction design
The best setup guidance is contextual, sequenced and visible while the user performs the task.
Migration is a UX problem
A product version can deliberately teach future patterns, reducing the cognitive cost of later redesigns.
The project taught me to treat a redesign as more than a release. A strong intermediate version can solve today's friction while teaching tomorrow's product.
Need a guided walkthrough of the work and decision-making?
Start a conversation