Introduction
Financial behavior is one of the subjects users are least willing to talk about openly. Asking direct questions about income, debt or saving habits usually produces misleading or socially acceptable answers rather than honest ones.
That makes user research in fintech products an area demanding a more careful methodology than in other sectors. In this article we look at concrete research approaches for working around those difficulties.
In SameUp's research practice, we sometimes see clear gaps between the answer given to a direct question and the actual usage data on the same subject — a sign that a research method should never rest on a single source.
The Challenges of User Research in Fintech
Financial behavior is one of the subjects users are least willing to talk about openly. Asking direct questions about income, debt or saving habits usually produces misleading or socially acceptable answers.
The reason behind that reluctance is generally privacy concern and fear of judgement. A user may hesitate to share their real spending habits with a researcher, which means the data collected reflects how they want to present themselves rather than what they actually do.
One way to reduce privacy concern is to frame research questions around a general "what do people usually do" rather than the user's own situation; this indirect approach can produce more candid answers without putting the user on the defensive.
Prioritizing Behavioral Data over Stated Preference
In fintech products there can be a marked gap between what users say and what they do. Survey and interview data should therefore be read alongside in-app behavioral data — clicks, drop-off points, session length.
A user might say in an interview that "the budget tracking feature is really useful", while behavioral data shows the feature isn't opened even once a month. Contradictions like these require the researcher to interpret stated preference together with behavior, never on its own.
A contradiction between behavioral data and stated preference is not a problem for the researcher but an opportunity; understanding why it exists usually surfaces the most valuable design insight available.
Realistic Scenarios in Usability Testing
Since real money and real account details cannot be used in test scenarios, the test environment has to be built as close to real conditions as possible. Fake but realistic data sets raise the reliability of the results.
It matters that the test scenario feels emotionally realistic to the user as well: something like "your rent is due and there isn't enough in your balance" surfaces a far more realistic behavior pattern than an abstract instruction to "make a transfer".
The fake data sets used in usability testing should be realistic but stripped of personally identifiable information — a requirement on both ethical and data security grounds.
A Segment-Based Research Approach
The young retail users of a banking app and its corporate account representatives have entirely different needs and mental models. Structuring research separately for these segments produces sharper design decisions.
A general research approach that ignores differences between segments risks producing results that reflect an average while representing no segment accurately — leading to design decisions that are optimal for no user group at all.
When running segment-based research, defining segments by behavioral as well as demographic criteria ("active investor" versus "passive saver", say) produces more accurate design decisions.
Connecting Research Findings to Product Decisions
Rather than leaving research outputs sitting in a report, they need connecting directly to design decisions and the prioritization process. Otherwise the investment in research disappears without any concrete effect on product development.
A practical way to secure that is matching every research finding to a backlog item. The finding "users get confused at step X" risks slipping off the product team's agenda unless it turns into a concrete design or development task.
When connecting findings to product decisions, weigh each finding's impact against its implementation cost; a finding may look striking but still fall down the priority list if it affects very few users.
Common Mistakes and How to Avoid Them
A common mistake is recruiting research participants only from current active users; the perspective of people who tried the product and left, or never used it at all, then goes entirely unseen.
Another is sharing research findings in a presentation without writing them into the backlog as concrete tasks; the investment in research is then forgotten over time.
Frequently Asked Questions
What is the biggest risk in fintech user research?
Users giving socially acceptable but untrue answers on financial matters is one of the biggest methodological risks.
Can behavioral data replace stated preference?
No — the two complement each other; behavioral data helps you understand what happened, stated preference helps you understand why.
How often should user research be run?
Rather than a one-off activity, it should be built into the product development cycle as a practice repeated at regular intervals.
Why does research with users who left the product matter?
Users who leave point directly at problems that current active users either don't notice or tolerate; research limited to active users therefore gives an incomplete picture.
Conclusion
Working with our fintech clients, SameUp positions user research not as a one-off activity but as a continuous practice embedded in the product development cycle.
If you would like to set up a research program for your own product, we can arrange a planning session with the SameUp team.