Cutting cognitive load in business banking flows users were actively avoiding.
Capitec's legacy business banking portal had a clarity problem. Finance officers, bookkeepers and owners of small-to-medium enterprises were making large, irreversible payments on an interface that overwhelmed them with choices and used patterns that contradicted themselves from one screen to the next.
I worked as part of a three-designer team on the portal's rebrand and rebuild. My focus landed on two of the highest-stakes flows: beneficiary group creation and multi-payments. The goal was not to ship something prettier. It was to rebuild trust at the exact moments users were most likely to make a costly mistake.
"Users were paying beneficiaries one by one because they didn't trust the bulk-payment feature enough to use it. Fear was eating the feature's entire value."
Insight from Ipsos user testingThe portal was overloading users at the worst moments.
Ipsos testing surfaced confusing navigation, terminology that did not match how users thought about their work, and unhelpful iconography. The most damaging finding was behavioural: users were choosing the slower path on purpose.
Paying one at a time
Beneficiaries paid individually rather than in bulk, because the bulk feature scared them.
Avoiding group payments
The feature skipped entirely, because the interface did not feel safe to use.
Falling back on the branch
Branch staff used for tasks the portal was built to let people do themselves.
In regulated fintech that is a business problem, not just a usability one. A feature nobody uses costs money to maintain and earns nothing back.
Three problems on the beneficiary group screen
When we annotated the original beneficiary group screen with the Ipsos team, three distinct issues separated out cleanly:
The multi-payment flow had its own problems
The highest-stakes screen in the portal, and the one users avoided most.
The legacy multi-payment screen, with a red callout we added during research to mark one of the most-confused interactions. Users described the layout as "too many decisions per row to feel safe."
Pay one by one
Ten individual payments felt safer than one mistake sending the wrong amount to the wrong account.
Too many actions per row
Account, amount, reference, narrative and deletion all competed in the same horizontal row.
Misleading icons
Icons did not carry the meaning users expected, and clicking to find out felt risky.
Ipsos testing first, then iteration in the open.
Testing with Ipsos surfaced what people said about the portal, and more usefully what they did despite saying it. People said they trusted the bulk-payment feature, then used it once and went back to single payments for the rest of the month. That gap between stated and observed behaviour is where the real work lives.
Brainstorming the alternatives in the open
The three of us on the design team worked through alternatives in InVision Freehand, annotating screenshots directly until we converged on a direction.
The Freehand board where we worked out the redesign in real time, marking up screenshots with crossed-out actions, redirected entry points, and proposed new patterns. Three designers, one whiteboard, no slide decks.
Fewer decisions, presented in order.
The original screen asked users to do everything at once: name the group, see current members, see every available beneficiary, add, remove, save. All on one page, where the same checkbox meant different things depending on where it sat.
The focused view. The screen now answers a single question per visit: who's in this group? Adding and removing are entry points to separate flows, not on-screen competitors.
The Add Beneficiaries modal. A clear stepper sets expectations. A search field handles scale (these tables can run to thousands of rows). And the Continue button only commits to the next step, not the final action. Users can change their mind cheaply.
01Fewer actions on screen
Only what the current task needs stays visible. The page became a focused view, not a control panel.
02Destructive actions in their own flow
Add and Remove each became a modal with a numbered stepper, so attention stays on one task.
03One pattern, one meaning
Less visible than a new layout, but it is where trust lives. Predictable components stop users second-guessing.
Building trust through structure.
The multi-payment flow was the screen most users were avoiding. Mistakes here meant real money moving to the wrong account. The redesign needed to make the right action feel obviously safer than the workaround.
Two structural changes did most of the work. The hero image at the top of this case study shows the result.
01Steppers to phase the task
Payment Options, then Beneficiaries, then Confirm. One decision at a time, and stepping back costs nothing.
02Tables with named actions
Every row shows what is being sent, from where, with which reference. Remove and Edit are labelled, not hidden in icons.
"The redesign wasn't about making it prettier. It was about letting users do the right thing without a knot in their stomach."
What changed for the people using it.
I don't have hard before-and-after numbers from this project. Capitec's instrumentation didn't surface the metrics we'd have wanted, and the rebrand-and-rebuild ran on a timeline that didn't allow for proper longitudinal comparison.
What I do have is the qualitative side, from follow-up testing and the client experience team.
Avoidance faded
The "I would rather pay one by one" pattern dropped away once the stepper made the path obvious.
Fewer worried calls
The client experience team reported fewer "I think I made a mistake" calls after rollout.
Patterns got reused
The modal stepper and three-step confirm became reference implementations elsewhere in the portal.
Running this today, I would insist on success metrics being instrumented up front.
What this project taught me.
01Consistency is invisible, until it isn't
The biggest wins were not new patterns. They were the same pattern applied everywhere. When every checkbox means the same thing, users spend their attention on the task instead of the interface.
02Enterprise UX is invisible work
Analysts, developers, account managers, and a rotating cast of stakeholders, sometimes with no product owner in the room. The design was only ever as good as the documentation and the handoffs.
03Testing is the cheapest honesty
Testing with Ipsos meant I could not argue my way past a pattern users could not parse. It also settled debates with stakeholders who wanted to move faster than the evidence allowed.
04Instrument up front, or accept the qualitative story
This shipped without success metrics in place, so I tell its story qualitatively. Today I would insist on baseline instrumentation before redesigning a single screen. The qualitative story is real, but harder to defend in a review.