Banking, Finance & Insurance

* This project is presented in anonymized form, under corporate confidentiality agreements.

When the project walks into a meeting and comes out turned into a budget-burning machine

When a corporate organization starts a digital project, the problem walks into a meeting and comes out turned into a huge structure of resources, platforms, and months of development. Not because it’s really necessary, but because the industry’s incentives are set up that way.

Software factories bill for project growth: more teams, more hours, more complexity. Never less. In this case, the organization started meetings with a conclusion already made: “we need an App.” Users called to inquire about information on their financial products and didn’t use the existing website, which “had gotten old.”

Faced with this request, agency salespeople rubbed their hands: “Of course you need an App!” And it has to be for iPhone, Android, and tablets. With a modern backend, QA, DevOps, multiple teams, and several months of execution. In minutes, an idea had turned into a team of 12–14 people.

We did something different: we reduced the problem before scaling the structure. Because executing the first interpretation of the problem quickly is not agility: it’s waste at high speed. And avoiding it took us just one hour.

A single meeting is enough to untangle the project

Applying our XDM (Experience Decision Making) methodology, we worked by separating three layers that in most projects appear mixed from the start: facts, interpretations, and solution proposals.

That analysis revealed a piece of data no one had considered: the frequency of user inquiries was between six months and two years. That invalidated the hypothesis of developing an App: the data showed that users’ phones “filled up” every three months… suggesting they delete the Apps they didn’t use.

The project then had to contemplate a first stage of strategic UX research to understand why users rejected the existing site and preferred to call. Without that information, any initiative was a blind bet.

The client thought the site was “old” and “ugly.” Perhaps they were right. But the real answers were in front of the screens.

While the interface (UI) lives inside the screens, what users experience (UX) is what happens in front of them.

That was the focus of the strategic research that, in just two weeks, revealed the underlying problem: the site showed less than half of the information users needed for their decision-making processes. That’s why users called.

The interface wasn’t failing for technological or aesthetic reasons.
It was failing because it didn’t answer the questions clients had.

Something no agency had set out to address, perpetuating the trap of every RFP.
After 4 to 6 months, the client would have received exactly what they asked for. But it wasn’t what they really needed.

Reduce complexity and uncertainty before starting execution

Our methodology starts from a fact: large projects don’t fail for technical reasons. They fail because complexities are revealed and addressed only when the whole structure is already in motion.

That’s why we work by clearing UX, institutional, and technological complexities from the start of the project.

Because true agility is not executing the first plan that seems to make sense in a hurry: it’s having the flexibility to change direction when new evidence appears.

1. UX complexities: the distance between the Business and people

To identify and reduce this distance, we work by surveying real decision-making processes, understanding what information users need, how they interpret it, and what processes or support tools they end up turning to.

That allows us to redefine the information architecture, visualization criteria, and product priorities before crystallizing UI design and development decisions.

2. Institutional and political complexities

In corporate projects, much of the friction appears when the solution is already advanced and internal rejections begin: branding, marketing, compliance, stakeholders.

That’s why from day one, we create a political map of all affected areas. We incorporate them early into the project in parallel tracks, clearing all risks (such as inconsistencies between manuals and internal criteria) before they impact the project.

Our result is projects without political rework or endless approval cycles.

3. IT complexities: technical feasibility

In the Banking, Finance & Insurance industry, there is a critical technological layer of legacy systems, whose owners must be involved from the very beginning. In this case, the amount of financial information involved generated waits incompatible with the experience the product needed to deliver.

Our solution was to build an intelligent, agnostic front-end engine, capable of reusing information already obtained, reducing unnecessary roundtrips, and performing progressive data loading without blocking navigation and use of the system.

That allowed us to solve performance without degrading experience, nor adding more architectures to an already highly complex stack.

Results

While agencies proposed huge and expensive structures to “fulfill the request,” Kambrica exceeded the goals with a small team, strategic focus, and clear direction.

Because our incentives are not set on placing people or selling hours, but on solving the right problem.

In this case, the project didn’t need an App, nor a cutting-edge technology platform. It needed to understand what was failing between the organization and its clients.

Without diagnosis and direction, speed only scales the error.

Most organizations don’t need more speed.
They need better diagnoses before scaling structures, budget, and complexity. That’s what we do.

If you’re responsible for the success of products or projects and suspect that the problem at hand is being misinterpreted, let’s talk.

We can help you see it before cost, complexity, and political risk keep growing.