Choosing a design partner for retail banking transformation

A retail bank should evaluate design partners through a defined customer journey, a map of its legacy dependencies, and a plan to test accessibility in working software. A transformation pilot should show what the bank can implement and how it will judge the result.

“A better banking app” leaves too much open for procurement. Replacing account navigation, improving payment recovery, and consolidating several banking brands are different assignments. Each creates a different research workload and requires different access to internal teams.

What makes a retail banking app design partner suitable?

The selection team should inspect evidence of work on everyday banking tasks. Relevant examples include locating available funds, finding a transaction, changing a payment instruction, and recovering access. For each case, the agency should explain the customer problem, its own contribution, and what reached implementation. A concept study and a released service can both be useful evidence when their scope is clear.

Humbleteam’s fintech portfolio describes work with ING on small-business banking: the team developed and user-tested prototypes for a new banking approach. That supports a discussion about research and prototyping. It does not establish delivery of a bank’s core-system migration or a completed retail transformation.

The bank can use a payment-detail journey to make the review concrete. A customer sees a transaction, questions its status, and contacts support. The candidate should explain how the account balance, transaction history, and support view stay consistent. Engineering must identify which system supplies each value and how the interface behaves when information arrives late.

An illustrative pilot acceptance list could include:

• Customers can distinguish available money from amounts the bank has reserved.
• A delayed response preserves the last confirmed status and explains how to retrieve an update.
• Support can locate the same transaction using a durable reference.
• Customers who use assistive technology can complete the journey.
• The implementation team can trace every screen state to a supported service response.

The agency should turn such goals into testable criteria with the bank. It should also explain the evidence it would collect. A portfolio rating cannot answer those delivery questions.

How should the bank scope a transformation pilot?

The first engagement should cover enough of the service to reveal dependencies. A payment redesign may require changes to mobile and web screens, contact-center procedures, notifications, and shared components. Procurement should name those surfaces rather than assume that an app proposal includes them all.

The bank’s product owner should bring engineering, security, operations, and compliance into discovery. Their job is to distinguish fixed requirements from habits that the institution can change. If a confirmation arrives through a batch process, the designers need that fact before proposing an immediate success state. If a document requires a particular approval, the schedule needs the responsible reviewer.

A practical statement of work records the selected journey, access requirements, research participants, and decisions due from the bank. It also identifies the intended implementation team and the person who can accept the work. A presentation can mark a research milestone; release acceptance needs evidence from the actual product.

Migration deserves a separate discussion. Some customers may use the previous app while others receive the new experience. The pilot should identify the shared account data, saved instructions, and support procedures that must remain understandable during that period. The bank should agree how to limit or reverse a release if a critical journey fails.

An agency can help expose these dependencies through a design system migration plan. The proposal should explain how research findings become component behavior, implementation tickets, and release checks. That connection is more informative than a promise of frequent design workshops.

What accessibility evidence should the bank require?

The European Accessibility Act covers consumer banking services within its defined scope, and its application date was June 28, 2025. The bank’s legal team should establish the national rules, applicable services, and any transitional provisions for the project. The directive is the legal source; a design agency’s accessibility checklist cannot settle those questions.

WCAG 2.2 is a technical web accessibility standard. It can inform the bank’s design and testing requirements, but claiming conformance to it alone does not establish that every legal obligation has been met. The brief should specify the required standards and platforms, including how the team will evaluate native mobile interfaces.

A candidate should show how it annotates behavior that a static mockup cannot demonstrate: focus movement, control names, error announcements, and enlarged text. Shared components need those decisions built in, with an owner for maintaining them. The complete banking journey still requires testing after components are assembled.

Authentication is a useful interview example. W3C’s accessible authentication guidance explains mechanisms such as password-manager support and pasting that reduce memory and transcription demands. The bank can ask the agency to examine login and recovery with its security specialists, then demonstrate the agreed experience in working software.

Procurement should request a sample accessibility finding with its reproduction steps, affected users, proposed remedy, and retest result. The project plan should combine technical checks with research involving people with disabilities. The final acceptance record should identify what passed, what remains unresolved, and who owns each remaining issue.