Today we’re all in for a real treat, as we switch up our Q&A format and interview @Bryan about his recent blog on Why Financial Products Work but Still Lose Trust. While the qualitative data generally revealed strong usability, he digs into the disconnect between the functional success of financial tools and the emotional friction users experience while using them.
You highlight the emotional disconnect between the quantitative data and the direct feedback of participants who sense a lack of meaning in the experience. This is a deep topic for us to mine in this discussion.
Let’s jump into the discussion
While we’ve seen an increase in user testing and inquiry into product UX, we’ve also seen many patterns harden into boiler-plate templates with high usability/accessibility that are taken for granted. We’ll likely see this trend continue with AI as a force multiplier.
And many teams are more focused on building the thing than they are communicating the meaning behind the thing.
As a starting point for our conversation: how do you convince engineering-driven teams that a functional, bug-free app is failing users?
Excited to dig into providing meaning for fintech users @Bryan!
Designers, on the other hand, often operate in a much fuzzier space. That ambiguity can quickly become a problem when teams are trying to align, prioritize, and make decisions. Those differences are baked in from the start, and they naturally create tension.
The common ground for each is that they want to build and make things for people. That agreement can be solidified by actually showing how users are experiencing problems. Show the problems. Reproduce the problems.
That’s a great starting place to start the conversation.
I’d like to propose a scenario. Let’s say one of the FinTech products featured in the article were to take the findings to heart, how might they have investigated or even anticipated the miss-alignment in their product? How would they begin to surface other issues in the wider application?
Start from common ground: a quality product. Then argue from the user’s needs.
Most of the issues I run into come from problems being left vague or unclear. No one has articulated or quantified the cost, both to the user and to the business. Without that clarity, engineering can’t see the weight or priority, and the work turns into a careful dance where nothing truly gets tackled.
Momentum doesn’t come from solving everything at once. It’s built by addressing one clear issue at a time. Visualizing the customer struggle helps to create some amount of urgency and empathy
A good team will want to solve these problems. Priority becomes thing to address.
So if we’re focusing on the first thing, Trust is a major issue for financial institutions. Previously, @vadym_grin talked about targeting Delight and Trust as primary feelings for optimization (What feeling does your product create?). Do you see the lack of meaning in products impacting trust primarily? How do delight and trust interact?
Yep. When a business offers 37 services and everyone is accountable for driving their slice of revenue, trust starts to break down. Nothing feels prioritized. The brain struggles to accept any single solution as the right one.
I’m guilty of this in our own business too. It usually comes down to misalignment, structuring offerings around internal goals instead of around what actually supports the customer.
When everything is for sale, nothing feels designed for you.
So I would argue that delight will only emerge from solidifying trust. And trust can be lost very quickly.
There’s a clarity to the findings that are presented in blog. Data to support the story. How do teams socialize and build good will across silos to begin to address these issues?
I think leaders do want to hear about these problems. What they need is a clear story that connects them to business goals. Without that connection, these issues get deprioritized in favor of all the other activity competing for attention.
Mapping user outcomes directly to business outcomes is what changes the conversation. A clear leading indicator, such as a UX metric tied to comprehension, creates a pause.
It slows a leader down just enough to reconsider direction before more effort gets invested.
Yes! There’s an interesting dynamic where the data becomes a trojan horse to talk about emotions.
Speaking of emotions, why do you think there is generally a lack of ‘meaning’ behind things like Dashboards and Notifications? How do teams discuss when ‘objective presentation’ is not enough?
They demand systems thinking at the development level, because the customer problem usually lives two layers deeper than what’s on the screen. A dashboard isn’t just showing information, it’s organizing and shaping work that happens elsewhere.
Because of that, teams have to be clear on customer priorities before the design can have meaning. I’ve been in enough of these types of projects.
Most teams struggle to define those priorities in concrete terms. When that foundation is missing, bringing emotion into the work feels forced or subjective.
More emotions in the work only works when the team understands the customer’s challenges well enough that the information actually helps them decide what to do next.
This brings up another question I had meant to ask; is there a moment you can remember when you first encountered a disconnect between product functionality and the meaning for a team?
There’s a real chicken and egg problem that’s emerging here that makes these problems so difficult. Bringing data in from the beginning to build a framework of trust and understanding, for project teams and users, that will establish goal and guardrails.
AHHH! Amazing dialogue here @Bryan & @EricZ - how fun to have BZ in the hot seat!
My question is for both of you perhaps… It seems friction can also come from bringing in data “too late” (perhaps corrective), in reality is there such a thing as bringing in data “too late” and if so, how should teams try to avoid that?
I think my biggest concern is when a team would decide to start a data-gathering practice mid-project. The setup and learning would require weeks to implement, potentially delaying the project, but it would also be tempting to begin testing at the perceived stage of the project once ready.
Without a clear guiding framework supported by data from the start, it could be difficult to influence decisions with stakeholders who don’t understand how it all fits.
I don’t think there’s ever a time when user perspectives are too late. In fact, if there’s no desire to incorporate it, it creates internal pressure to revisit it when people realize the implications.
feel free to jump in!