I used to think that once I had tested the prototype and run usability sessions, my job was done. The design was clear, the team had signed off, and development was in progress. But one project changed my thinking completely.

When I Realized I Had to Test Again?

We were building a B2B fintech app for field agents who could withdraw money, apply for loans for customers, and pay utility bills. I had already tested the clickable prototype with agents, gathered feedback, and refined the flows. Everything seemed ready.

Then development started. In the very first week, developers kept coming back with the same questions: “What should happen after the loan steps are completed?” “Should we tell users that E NACH and E Mandate steps are still pending?”

At first, I thought I had documented everything properly. But when multiple developers kept asking me the same thing, I stopped and thought, did I miss something?

That was the moment I decided to test the staging build myself, step by step, like I was an agent standing in a shop with a customer waiting.

What I Found During My First Post-Build Test?

Running through the loan process, I immediately saw the problem. Our interface clearly showed three steps: customer KYC, loan details, and document upload. After that, we showed a big success screen. But the process was not actually complete. The customer still had to finish E NACH or E Mandate authorization, which meant:

• Authenticating through net banking or debit card?
• Waiting for the bank to verify and approve the mandate?
• Waiting hours or even days for final confirmation depending on the bank?

Because we did not show any of this, agents believed the loan was done when it actually was not. Imagine being in the field and promising a customer that their loan was approved, only to have them come back frustrated because nothing had moved forward.

I documented everything, recorded a quick video of the flow, and shared it with the team the same day. It was obvious we needed to redesign this journey.

How I Made Testing Quick for Everyone?

I kept the process fast and easy so I would not slow down the sprint:

• I focused only on the loan flow since that was where the confusion was?
• I shared short screen recordings with notes explaining why this gap could hurt trust?
• I worked side by side with developers to add a visible step telling users their bank authorization was still pending?

This approach let the team act immediately and kept development moving forward.

What Changed After the Fixes?

We redesigned the flow so that users always knew where they stood:

• Added a clear fourth step labeled “Bank Authorization Pending”?
• Displayed expected timelines so agents could set realistic expectations with customers?
• Sent an SMS once the mandate was approved so agents knew exactly when the loan was confirmed?

After we shipped the update, agents told us they finally knew how to guide customers properly. Customers stopped asking why their loans were delayed, and the support team saw fewer calls.

Closing Thoughts

This experience taught me that testing after the build is not just about catching small visual bugs. It is about catching gaps between what users think is happening and what is really happening. If I had not tested, this confusion would have gone live. Now I always ask myself before release: “Will the user understand what stage they are in at every step?” If the answer is no, we fix it before it ever reaches production.