Bad bank app reviews need a diagnosis before a redesign
Fintech and banking
Published Updated 4 min read
“The app is broken” can mean several things. A customer cannot sign in. A transfer is still processing. A new phone has triggered an unfamiliar verification step. Another customer simply cannot find a feature that moved.
Those complaints may sit beside each other in the same app-store review feed. They need different owners and different fixes. A bank considering a mobile app redesign should turn the reviews into a map of failed customer tasks before commissioning new screens.
The aim is to decide where design can help, where engineering or operations must act, and what evidence would show that a customer can recover.
How should reviews become useful evidence?
Start with a bounded review period and retain the date, app version, platform, and market when those details are available. Keep missing details marked as unknown. A complaint about an old release should not automatically become a requirement for the current one.
Classify each review by the task the customer was attempting. Separate sign-in, account recovery, payment submission, payment tracking, card controls, and other relevant journeys. Keep the customer’s language alongside the classification so the original problem does not disappear into a spreadsheet label.
Reviews are a self-selected sample. They can expose a serious failure without establishing how common it is. Check the pattern against support conversations, incident records, and product events before estimating its scale.
In particular, avoid treating several descriptions of the same outage as several independent design problems.
Which complaints should the team tackle first?
Consider this illustrative set of findings:
| Customer’s problem | Question to investigate | Likely partners in the fix |
|---|---|---|
| Cannot sign in after changing phones | Is the recovery route understandable and working? | Identity, support, design |
| Cannot tell whether a payment went through | Is the displayed state current and specific? | Payments, engineering, design |
| Repeats an action after a timeout | Can the system determine whether it already succeeded? | Engineering, operations, design |
| Cannot find a familiar feature | Did navigation or terminology change? | Product, research, design |
The last column identifies people to involve, not a diagnosis. Establish the cause before assigning the work.
Prioritize by the consequence of failure, the evidence of recurrence, and the ability to make a useful change. A confusing card-freeze flow deserves attention even if the home screen attracts more comments. Avoid turning the ranking into a precise score when its inputs are still guesses.
What should the prototype prove?
Take one painful journey all the way through recovery. For account access, begin with the customer’s actual situation: a replaced phone, an expired document, or a lost credential. Let the bank’s policy and technical owners establish the permitted routes.
Then test whether people understand the choices. Can they identify what they need? Do they know whether leaving the app will lose progress? Is the support handoff usable when the normal route fails?
The GOV.UK service research planning guidance recommends choosing research questions and participant groups explicitly. Applied here, that means including the people who experience the failure, rather than testing only with staff who know the process.
A successful test ends with the customer reaching a supported outcome or understanding a real next step. “They found the help button” is only an intermediate observation.
How can a bank choose the right redesign agency?
Ask for a case walkthrough of a live financial product, including constraints and failure states. Establish whether the agency’s contribution was research, product UX/UI, visual identity, or implementation. Those are different kinds of evidence.
Humbleteam’s fintech practice is one place to examine product work. Its retail banking design-partner guide offers a broader way to assess delivery scope. Use the same evidence requests for every candidate; a logo alone does not explain what a team did.
The proposal should name the bank-side owners the agency needs and explain how findings reach the release backlog. An audit that identifies an account-recovery problem but leaves the identity team out of the project has not closed the loop.
What is worth measuring after release?
Track the specific journey that changed: successful recovery, time to a verified status, repeated attempts, or related support contacts. Preserve the eligible population and the observation period. Compare app versions where possible, and record outages or policy changes that could affect the result.
App-store ratings can provide context, but they combine experiences across the whole product. A rating movement cannot tell the team whether one redesigned flow worked.
Bring the next review meeting one customer task, its supporting evidence, the current failure, and a proposed recovery test. That is enough to begin a focused redesign without pretending every complaint has the same cause.
