What should a banking app UX audit check before a redesign?

Which complaints belong in the audit?

Collect recent app reviews alongside support contacts and known incidents. Tag each usable report with the task, app version, device, language, and approximate time. Keep unknown fields marked unknown. A complaint about transfers after an update needs a different investigation from a recurring difficulty finding transfer history.

A review is a starting point, not a verified diagnosis. Check whether support saw the same issue, whether telemetry recorded failures, and whether someone can reproduce the journey. Remove customer identifiers from the working material and follow the bank’s approved research and data-handling process.

Separate interface problems from outages, identity-provider failures, and account restrictions. Several causes can coexist. An unavailable service may need an engineering fix while its vague error message needs a design fix. Assign both instead of expecting new navigation to solve the outage.

How should the team decide whose tasks matter?

List the user groups and jobs the app must support before ranking complaints. Frequent users, occasional users, and people recovering account access may need different routes through the same interface.

NN/g’s Vanguard mobile app case study describes research used to prioritize a diverse audience’s needs during a redesign. It is an investment-app example, not a banking benchmark or a Humbleteam project. Its useful lesson here is to examine important tasks across user groups before letting the loudest feedback set the roadmap.

For each proposed priority, record the affected audience, evidence, consequence, and confidence in the diagnosis. A less frequent failure that blocks account access deserves explicit consideration alongside a common but minor inconvenience.

Which journeys should reviewers walk through?

• Login and recovery: Can a customer understand the next step after a failed sign-in, changed phone, or interrupted recovery attempt?
• Balances and transactions: Is the distinction between available funds, pending activity, and completed activity understandable?
• Transfers: Can the customer check the recipient, amount, fees, and timing before confirming, then find an accurate status afterward?
• Card controls and support: Can someone find the relevant control and reach an appropriate support route when self-service fails?
• Accessibility and localization: Does each critical journey remain understandable with larger text, assistive technology, longer translations, and the supported reading directions?

Record the starting condition and expected outcome for every walkthrough. A screenshot alone rarely explains whether someone was signed out, waiting on another service, or looking at old data.

NN/g’s heuristic evaluation guidance treats expert review as a structured way to find usability issues. Use that review to form questions for research, then observe customers attempting the important tasks. Expert judgment and observed behavior answer different questions.

What should a useful finding contain?

Use a consistent record: journey and starting condition; observed behavior; expected behavior; supporting evidence; possible cause; affected users; proposed change; dependency; accountable owner; and a test for completion.

Illustrative finding: after an interrupted transfer, the app returns to a blank form while the payment service still reports processing. The proposed change is to restore the existing transfer’s status and explain what happens next. Engineering must first confirm how that status is retrieved. The acceptance check is whether a returning customer can identify the existing transfer without submitting another one.

This example is a proposed audit record, not a reported customer result. Its value is that design and engineering can agree on the problem before either team estimates the work.

How does the audit become a release plan?

Group fixes by journey and dependency. Address service defects with the responsible teams, test revised flows with representative customers, and release in stages where the delivery system allows it. Define rollback conditions before rollout, particularly for access and payment journeys.

Keep a baseline for the outcomes each change targets, such as task completion, recoverable errors, and relevant support contacts. Compare like-for-like periods and audiences after release; an outage or a change in traffic can distort the result.

The brief sent to a banking product design partner should include this evidence, the unresolved questions, and the decision owners. Teams comparing regional suppliers can use the Middle East banking UX agency guide alongside it. Ask each candidate to explain how the audit will change its proposed scope.