Financial and security-focused apps compete on a currency that's harder to design for than features: whether the user believes the app is protecting them. This page groups my fintech and security-app-adjacent client case and explains the questions this sector tends to raise before you commission research.
What makes fintech/security-app UX problems distinct
Three pressures tend to separate fintech and security-app research from a typical consumer product brief.
Trust. Every interaction with a money or security app is implicitly a question of "can I trust this with something important." Friction that would be a minor annoyance elsewhere (an unclear permission request, a vague error message, a step that doesn't explain why it's needed) reads as a risk signal here. Users don't need to articulate a specific complaint to disengage; a vague sense of unease is often enough, which makes this category of problem hard to see in analytics and easier to see in a moderated research session.
Retention. Many fintech and security apps are designed to be used passively: running quietly in the background, checking in occasionally, alerting only when something needs attention. That makes retention and engagement metrics genuinely ambiguous: a drop in app opens can mean the product is failing, or it can mean the product is doing exactly what it should and the user no longer needs to check it manually. Telling those two situations apart from usage data alone is close to impossible, which is why this category leans on research rather than dashboards.
Regulatory pressure. Financial and security services in Ireland operate under real regulatory attention, and that shapes onboarding, identity verification, consent and data-handling flows in ways a generic consumer app doesn't have to navigate. This page doesn't offer legal or compliance advice (that sits with a qualified adviser and the relevant regulator) but it does mean UX decisions in this sector are rarely "just" design decisions; they usually have someone from compliance in the room too.
Research in practice
The following client case describes the research and recommendations.
Why more app opens were the wrong goal for a security product follows the investigation from install intent and permissions through the payment decision and subscription model. It explains why we considered renewal and refunds alongside conversion.
Which service fits
Fintech and security-app briefs tend to start from one of two triggers, and they point to different services.
If the trigger is a retention, churn or "quiet usage" question (engagement has dropped, or usage patterns don't tell you whether trust is intact) that's a user research question rather than a usability-testing one. Task-based testing can tell you whether people can operate a screen; it can't on its own explain why usage has changed. A proper retention study needs to combine product analytics with research into active, inactive and former users, which is what user research is built to do.
If the trigger is closer to "people are dropping out of signup, verification or a funded action" (a conversion problem inside a trust-sensitive flow) that's a conversion optimisation question. This pairs funnel analysis with hypothesis-led testing to work out where a specific step is losing people and why, which matters especially in fintech, where the drop-off is often a trust signal rather than a usability bug in the narrow sense.
Where the underlying question is genuinely unclear (is this a trust problem, a comprehension problem, or a conversion problem) the brief call is where we work out which method actually answers it, rather than starting from whichever service sounds closest to the symptom.
Working on a fintech or security app?
Tell me what’s changed (a retention drop, a funnel problem, a release coming up) and what you already know. I’ll recommend a method, not a default package.