Modernising a Legacy Banking Portal for 120M+ Users
A consulting engagement on the Backbase platform restructuring information architecture, rebuilding trust through design consistency, and reducing the operational cost of avoidable support calls.
↑ The redesigned portal homepage surfacing the tasks users need most, in the moment they need them.
The brief was to "modernise the UI." The real problem was deeper.
HDFC's banking portal had been built over a decade, shaped by internal org structure more than by user needs. What started as a request to refresh the visual design quickly surfaced something more serious: users couldn't find critical features when they needed them most. "Block my card" required 4 clicks from the homepage. Tax certificates were buried under an acronym-heavy menu that meant nothing to users. Support call volumes were rising.
This was a Backbase platform engagement meaning our design decisions had to work within platform constraints, be feasible for engineering, and scale across a product being used by over 120 million customers.
My role was to push the project from surface-level visual refresh to a structural redesign and to build the evidence that would convince stakeholders to go deeper than originally scoped.
HDFC Bank serves many people with different mental models and urgency levels. The challenge of designing one interface for multiple roles under time pressure is exactly what this case study demonstrates: how to simplify complex multi-user workflows without stripping away the control that power users depend on.
What I owned on this project
I joined as Lead Product Designer on a consulting engagement, embedded with the client's product and technology teams. I was responsible for the end-to-end UX from discovery through to prototyping and stakeholder sign-off.
Research & Discovery
Heuristic analysis, ROT audit, NLP sentiment parsing of 500+ App Store reviews, 15 user interviews across demographic segments
Information Architecture
Card sorting (unmoderated), tree testing, IA restructure, sitemap, content hierarchy definition
Design System
Token-based design system aligned with Backbase component architecture colour, typography, spacing, and interactive states
Stakeholder Alignment
Impact/Effort prioritisation workshops, service blueprint to justify operational cost savings, executive-ready prototype walk-throughs
Three compounding failures making users call support
Users couldn't complete critical tasks independently
High-value, low-frequency tasks blocking a lost card, downloading a tax certificate, transferring via RTGS were buried 4 to 6 navigation levels deep. Users in urgent situations couldn't find what they needed, so they called support instead. Analysis of 500+ support tickets showed that a significant share of inbound calls were for tasks that the portal was already capable of handling.
Evidence: Support ticket analysis + moderated usability sessions (n=15) where users failed to locate "Block Card" within 3 minutes.
The information architecture was organised around the bank's internal structure, not user needs
Navigation menus reflected the bank's internal department names, not how customers described their own tasks. "RTGS/NEFT" meant nothing to a user who just wanted to "send money to another bank." Features were grouped by product team ownership, not by the user's goal. Card sorting sessions with 12 participants revealed that users had fundamentally different mental models from the current navigation hierarchy.
Evidence: Unmoderated card sorting (n=12), tree testing, NLP analysis of 500+ App Store reviews surfacing "can't find" as the most common complaint cluster.
Outdated visual design was eroding trust, particularly with younger users
NLP sentiment analysis of App Store reviews showed a recurring pattern: younger users equated the aged UI with poor security and broken functionality. One phrase appeared repeatedly, "looks like it hasn't been updated since 2010, doesn't feel safe to use." This wasn't a cosmetic problem. It was a trust deficit that was affecting engagement and retention.
Evidence: NLP sentiment analysis of 500+ App Store reviews, "trust" and "looks outdated" as co-occurring negative sentiment clusters.
How might we redesign a banking portal serving 120 million users so that anyone regardless of digital literacy, can complete a high-stress financial task in seconds, not minutes, without picking up the phone?
If we restructure the IA around user mental models, not internal org charts, elevate emergency tasks to the first level of navigation, and establish a consistent token-based design system, then we will reduce time-on-task for critical flows from minutes to seconds and measurably reduce avoidable support call volume.
Building the evidence before touching a single pixel
Before any design work began, I ran a multi-method discovery phase. The goal was to quantify the usability problems, understand user mental models, and build an evidence base strong enough to justify a full structural redesign not just a visual refresh.
Heuristic Analysis
Evaluated the existing portal against Nielsen's 10 heuristics. Identified 23 critical violations primarily around error prevention, recognition over recall, and consistency.
ROT Content Audit
Catalogued every feature against Redundant / Outdated / Trivial criteria. 34% of top-level menu items were surfacing features used by under 3% of users monthly.
NLP Sentiment Analysis
Parsed 500+ App Store reviews using NLP clustering. "Can't find," "confusing navigation," and "looks outdated/unsafe" emerged as the three dominant negative sentiment clusters.
User Interviews · n=15
15 moderated sessions across age groups and account types. Task-based format: "You've just lost your card. Block it." Observed failure patterns and emotional responses in real time.
↑ Multi-method research synthesis quantifying where users were failing before any design decisions were made.
What the research told us that changed the direction
Support tickets are the real usability report
Analysing 500+ tickets before interviewing a single user gave us quantitative proof of failure points. The top 3 categories card blocking, transfer queries, certificate downloads became our primary redesign targets. Data arrived before assumptions.
Users grouped features by goal, not by product category
Card sorting revealed that users grouped "Mobile Recharge" with "FASTag" as "top-up tasks" a category that didn't exist in the current navigation. This validated a new "Quick Actions" hub that cut across product silos.
Emergency tasks need a different design contract entirely
When a user is panicking about a lost card, they don't browse, they scan desperately for one thing. Placing "Block Card" inside a nested "Card Management" submenu was a category error. Emergency functions need permanent, prominent placement at the root level.
The rules we designed by, and why
1 · Structure around the user's goal, not the bank's org chart
Derived from card sorting data showing users organise by task type, not product category.
→ Navigation rebuilt around user intents: Send, Receive, Pay, Protect, Access.
2 · Elevate emergency tasks to the top level always
Derived from observing users fail to locate "Block Card" under time pressure consistently triggering a call to support.
→ "Urgent Actions" module permanently surfaced on root dashboard.
3 · Use progressive disclosure not information dumping
Derived from heuristic analysis showing 34% of top-level menu items were for features used by <3% of users.
→ Secondary features collapsed by default, surfaced on demand with contextual logic.
4 · Consistency is a trust signal, not just an aesthetic preference
Derived from NLP analysis showing visual inconsistency was interpreted by users as a sign of poor security and neglect.
→ Token-based design system enforcing consistent colour, type, and spacing across all modules.
How we got from insight to structure
We ran two structured ideation phases before committing to any high-fidelity design. The goal was to explore structural options, not visual polish and validate them with real users before investing in execution.
Card Sorting → Sitemap → Tree Testing
Before sketching anything, we ran unmoderated card sorting to build the new IA from user behaviour data. The proposed sitemap was then validated through tree testing measuring first-click accuracy and time-to-target on critical tasks.
Card Sorting Output
Tree Testing
↑ Card sorting output informed the new navigation structure. Tree testing validated it with a 78% first-click success rate on critical tasks (vs. 42% on the original structure).
Crazy 8s Workshops → Prioritisation Matrix
We ran Crazy 8s sessions with PMs and engineers to generate layout concepts rapidly without default assumptions. Outputs were then mapped on an Impact vs. Effort matrix to define Q1 scope vs. phased roadmap.
↑ Crazy 8s output rapid ideation session with PMs. The prioritisation matrix separated Q1 delivery (Unified Transfer Widget, Emergency Actions) from phased roadmap items (AI Recommendations, Predictive Dashboard).
Service Blueprint → Prototype → Usability Validation
Low-fidelity wireframes were tested iteratively before high-fidelity execution. A service blueprint mapped every front-stage design decision against back-stage API constraints making the operational cost case visible to stakeholders.
Wireframing Progression
↑ The service blueprint made the "20% operational cost reduction" case tangible for stakeholders showing exactly which support call types would be eliminated by self-service flows.
The choices that shaped the outcome
Decision 01 · Full IA restructure vs visual refresh only
Tension: Stakeholders initially wanted a UI polish. A full IA restructure meant more engineering effort and more risk.
Choice & trade-off: We pushed for structural redesign, backed by ticket data and tree testing results. Trade-off: longer timeline. Outcome: the redesign addressed root cause, not symptom.
Decision 02 · Persistent "Urgent Actions" vs a smart contextual assistant
Tension: Engineering proposed a context-aware AI assistant to surface tasks dynamically. More sophisticated, but higher delivery risk and unproven for high-stress scenarios.
Choice & trade-off: Shipped persistent "Urgent Actions" in Q1, deferred AI recommendations to Q3. Trade-off: less personalisation initially. Outcome: reliable, predictable experience for edge-case stress scenarios.
Decision 03 · Token-based design system vs bespoke component styling
Tension: Bespoke styling per feature would have been faster for designers in the short term but unsustainable as the platform scaled.
Choice & trade-off: Invested in a token-based design system aligned with Backbase's component model. Short-term overhead, long-term velocity. Established a single source of truth across 40+ components.
The redesigned portal, built for humans under pressure
High-fidelity designs were tested in moderated usability sessions before handoff. Each screen iteration was validated against our primary success metrics: time-to-task on critical flows, and SUS score improvement.
↑ State 1: Dashboard default Urgent Actions always visible at top, personalised Quick Links module, clean account summary with clear CTAs.
↑ State 2: The "Block Card" emergency flow, reduced from 4+ navigation steps to a persistent top-level action. Task completion time: 240s → 38s in prototype testing.
↑ State 3: The Unified Transfer Widget combining RTGS, NEFT, and UPI behind a single "Send Money" entry point with plain-language guidance. Transfer success rate: 85% → 100% in prototype testing.
↑ Token-based design system ensuring visual consistency across 40+ components. Colour, typography, and spacing tokens aligned with Backbase component architecture.
Design doesn't happen in isolation
This project required navigating between the client's product team, engineering, and external stakeholders while working within the constraints of the Backbase platform. Several moments required deliberate cross-functional effort to keep the redesign on track.
Convincing stakeholders to expand the scope
The original brief was a visual refresh. Moving to a full IA restructure required presenting the support ticket data and usability session recordings making the cost of inaction visible. The service blueprint was the turning point: it showed stakeholders exactly how the redesign would reduce operational overhead.
Engineering constraints shaping design decisions
Working within Backbase's component model meant some design patterns I initially proposed weren't feasible without significant custom development. We ran working sessions with engineers early adapting designs to work with existing components, not against them. This is where the Impact/Effort matrix paid off: it made the trade-off conversations concrete.
Involving support team agents (late, but valuable)
We used support ticket data extensively, but interviewed support agents too late in the process. They surfaced nuances that raw data couldn't - specific phrasing users used when confused, common misunderstandings about feature names. I'd involve them in week one on future projects.
Prototype testing results validated before production
All metrics below are from moderated and remote prototype usability testing (n=15). Production measurement was not in scope for this consulting engagement, but the service blueprint established a projected operational cost case.
Honest reflections from someone who'd do a few things differently
What Worked
Tickets before interviews, data before assumptions
Running the support ticket analysis before any user interviews gave us quantitative proof of failure points. When we walked into stakeholder conversations, we weren't asking for research budget, we were presenting evidence that a structural problem existed. That changed the dynamic.
The service blueprint as a stakeholder tool, not just a UX artefact
Using the service blueprint to make the operational cost case visible showing exactly which support call types would be eliminated was the moment the project scope was extended. It translated design work into business language.
Platform constraints as design parameters, not obstacles
Working within Backbase's component model early before any high-fidelity work meant the designs that reached engineering were already feasible. Running "Engineering Feasibility Reviews" after each design phase saved significant rework.
What I'd Do Differently
Involve support agents in week one, not week six
We used ticket data extensively but brought support agents into interviews too late. They held pattern knowledge that data alone couldn't surface specific phrasing users used when confused, recurring misunderstandings about feature names. Earlier involvement would have sharpened our insight phase significantly.
Push harder for production measurement instrumentation
Our impact metrics are from prototype testing which is credible, but not the same as production data. On future consulting engagements I'd advocate strongly for instrumentation scoped into the delivery plan from the start, so the business case can be validated post-launch, not just asserted.
Design for low-digital-literacy users from the start, not as an afterthought
Our initial interview cohort skewed toward digitally confident users. Adding 3 sessions with lower-literacy users mid-project changed some navigation decisions significantly. Those sessions should have been week one, not week five.