04 · Diners Club Ecuador · Mobile banking
30% fewer steps in a mobile banking self-service flow
A flow buried two menu levels deep and limited to a single product type. I unified it into one journey, with business rules aligned across four teams and decisions backed by field research.
About confidentialityThis project is under a confidentiality agreement. The case focuses on the problem, my decisions and what changed.
Content protected by confidentialityDiners Club · Confidentiality agreement
30% fewer steps in a mobile banking self-service flow
The problem
Access sat two menu levels deep, covered a single product type and everything else was solved in account settings or at a branch.
My role
Field research, flow redesign and alignment of rules with Product, Engineering, Legal and Marketing.
Outcome
30% fewer steps, 17 customers interviewed and 50+ frictions prioritised as roadmap input.
30%fewer steps in the main flow
17customers interviewed, plus branch advisors
50+friction points prioritised
4teams aligned before closing decisions
01
Context and problem
The feature lived two levels deep in the menu and covered only one product type. For the rest, customers had to dig through account settings or go to a branch.
The team knew there was friction, but hadn’t mapped it. That was the first question to answer.
02
Field research
I interviewed 17 customers and branch advisors, who see every day what the app doesn’t solve, and mapped 50+ friction points prioritised by severity and number of mentions.
- Silent failures: the app didn’t explain why something failed, so customers blamed themselves or gave up.
- Advisors are de-facto product support: their workarounds and complaints are a direct source of gaps.
- Distrust, not digital clumsiness: some customers avoid self-service out of fear of fraud.
- “I don’t know if it went through or not, I’d rather go to the branch.”
03
Design decisions
01Move the feature to the first level
Access went from two menu levels to a direct shortcut.
Decision
An occasional-use feature gained visibility: I negotiated that space against daily-use features.
02One journey for several products
Instead of one flow per product, a single journey that recognises what the customer holds.
Decision
More states to cover in design and QA, in exchange for a single mental model.
03Rules from a service, not hard-coded
Institutional limits vary by customer segment; I agreed with Engineering that they load from a service.
Decision
It avoids redesigning every time a rule changes.
04One error pattern for digital procedures
Limited retries and a clean exit, applied to the five procedures in scope.
Decision
Less freedom per screen, more consistency and fewer cases to build.
04
How I worked with the team
Before closing each decision I validated scope, rules and feasibility with Product, Engineering, Legal and Marketing, and aligned new components with the Design System team.
I also spotted that one name meant two different scopes for two teams, and brought it to a decision before designing.
05
Outcome
The redesign cut the main flow by 30% and left the friction points prioritised as input to the engineering roadmap. The project is still in development and not yet public.
What created the most value wasn’t the redesign, but showing with evidence which part of the problem was worth solving first.
06
AI in the process
I use AI to speed up, not to decide. This is what I did with it and what I kept deciding myself.
I used AI for
- Claude: organising transcripts and mapping pain points into a sheet with severity and mentions.
- Verification: where the automatic transcript lost parts to dropped calls, my field notes took precedence.
What I decided myself
- What to ask, whom to ask and how each friction is prioritised.
- What each team sees and the flow’s design decisions.
07
Learnings
- Branch advisors spot gaps before any metric does.
- A single error pattern speeds up design, development and QA together.
Next case