Designed for Low Confidence
A fintech concept that helps people understand risk and choose their next step before a high-stakes transfer
Fintech
Low confidence moments
Role
Product Designer
Timeline
8 weeks
team
Me
platform
Desktop and Mobile
Help people assess a transfer before they commit
Exploring how a banking interface could support someone who is unsure about an unfamiliar transfer. This started when i observed my mother hesitate before sending money. That moment caused me to do some research and find out how users feel when making strange transfer
Overview
AVID is a fintech concept for people who feel unsure before making an unfamiliar or unusually large transfer. The starting point was observing my mother pause before confirming a payment. That moment helped me identify a high-stakes interaction.
I spoke with six people and ran a qualitative research, the benchmark was for them to to use fintech products often. In this research, their biggest concerns were about about scams and sending money to the wrong person, especially when paying a new beneficiary or transferring an unusually large amount.
The decision
I explored a text-first interface and a transfer warning that explains the risk before the user confirms. The warning gives the person a clear choice to continue or pause and get help. I also explored destination-specific forms, confirmation summaries, masked identifiers, and a chart that distinguishes ordinary activity from unusual activity.
The trade off
A warning can support a careful decision, but it can also interrupt a legitimate transfer so I proposed different guidance levels and a short delay for higher-risk actions hoepfully to make the system more flexible and cause less interruptions
Make important actions easier to find
I used full-width, text-labeled actions and made “Talk to someone” a top-level destination. The goal was to reduce reliance on small icons and make help easier to reach. This trades visual compactness for clearer labels and larger targets.
I also explored a text “Go back” control. Early versions were too large or too close to the primary action, so I reduced its height and aligned it with the familiar back-control position. The iteration image shows how that decision changed.
Warn at the point of risk
The concept considers three transfer signals: a new beneficiary, an unusually large amount, and an unusual time. When a signal is present, the warning explains what triggered it and offers two choices: go back or continue. At the highest proposed risk level, I added a spoken confirmation and a ten-second delay before continuing.
The warning gives more weight to the cost of an incorrect transfer than to the few seconds needed to pause. That is a design rationale, not a validated risk model. The thresholds, spoken guidance, and delay still need testing.
Make identity checks easier to follow
For ID capture, I used camera-style framing and a short instruction video to show what the user needs to do. The concept also masks BVN and NIN details after verification. These are proposed clarity and privacy choices; they have not been validated with users.
When a chart has to be accurate
This is my proudest moment on this project because i had to channel my inner data visualization designer and got things wrong 3x before i got it right
The inflow and out flow dashboard has to show weekly totals and for the most part, there is no problem. However imagine a situation where a user has a super active week to tune of ₦100,000,000 and another week where their activity is very low, say ₦10,000. There is no linear chart that can represent these tow values clearly on the same axis.
First iteration:
Logarithmic scale can solve this range problem but it also introduces another problem, the chart stops being intuitive and for a chart that's meant to help users compare spendings, a logarithmic scale is just not worth the stress so i had to think of a simpler solution
Second iteration:
Round the axis to cleaner intervals starting from 0, 500k, 1M … instead of whatever irregular numbers the data produced and it fixed a real but smaller problem. Uneven gridline spacing made bar heights genuinely hard to compare, but it did not touch the actual issue, there isn't enough space to keep going to represent these vast ranges
Third iteration:
Cap any outlier bar at the top of the chart, visually indicate it and call out the real number separately in text and it worked fine for exactly one outlier but it stops working he moment I imagined a month with two large weeks. There is no honest way to cap two different bars at the same height and still show which was actually bigger. I built a fix for the one case in front of me but the real problem was bigger than that.
Again, i took a step back and found the common denominator. The axis, he's the one always breaking, always, so i said it's time to go. The moment the bars carry their own value themselves, the burden stops falling on the axis to give that value. No matter how extreme the range goes, as long as each bar prints its own value, the height stops being so important
After solving this, i looked at the axis and still kept it for the months where the user's transactions can be easily represented. If the user's transactions are below 50 to 1 ratio, they get the shared axis chart however if they're having an outlier month, they get the self labelled chart
This also means a user in their history can get the two different charts as long they can easily read their chart, my job is done
What i would validate next
I would ask people to review an unfamiliar transfer, explain the warning in their own words, and choose whether to continue or pause. I would check whether they understood what triggered the warning, whether the guidance level is clear, and whether the delay feels protective or obstructive. I would revise the concept based on what participants do, not assume the warning prevents fraud.