How might we make BHIM the UPI app India chooses, not the one it was given?

AA is where most consumer apps stop, and at AA a screen can still fail the people we were furthest from. We held AAA at component level rather than screen level: the chip, the row, the sheet and the field each fixed for contrast, touch area and type floor before any layout used them. Targets went to 42px because Fitts's Law makes a small target a slow one, and slow is where an unconfident user stops.

BHIM stands for Bharat Interface for Money and had never looked like it, so the system took the mark's own colours: saffron acts, green confirms. Every component was drawn once and specified in both treatments, and no icon ships without its label, which is recognition rather than recall doing the work for someone who cannot afford to guess. One component set, two contexts, nothing to relearn between them.

Copy was designed rather than written last, because the first research finding was about language. Labels are a verb and its object in the plainest words available, which is Nielsen's match between the system and the real world, and each screen carries one filled action so the next step is unmissable, which is the isolation effect. Labels wrap rather than truncate, since truncation tells someone the screen was not written for them.

Settling a shared bill without leaving the app was the proposition NPCI most wanted. We covered both cases people actually have, a spend made inside BHIM and one made anywhere else, and put the running position on every screen so a user sees what they owe before they commit, which is visibility of system status doing the reassuring. Testing went mostly on the settlement moment, where the app has to be unambiguous about money changing hands.

A real-time view of spending by category, with a monthly trend and a budget the user sets, which answers the first problem: a reason to open BHIM when nobody is being paid. The first screen is deliberately plain, one number and five categories, because density reads as complexity to the users we were furthest from, and the cognitive load of that screen decides whether they carry on. Everything else sits a level down.

The home screen took more iterations than anything else we drew, through two changes of leadership. I led the strategy as much as the layout: what earns a place above the fold, what a first-time user has to find, and how the family and personal contexts sit side by side without either being buried. Every extra option at the top costs time to choose, which is Hick's Law, so the bar was set by the least confident user.

A household is the unit money is actually managed in, and no UPI app was built for one. A primary member onboards the family, sees the shared position in one view, and assigns a bill to the person who should be paying it. Family is a context the same components hold rather than a second app: Tesler's Law says the complexity has to live somewhere, and it belongs in the system rather than in a user learning a second interface.

Splitting a bill means talking to people who may not have the app, may not use UPI, and may not be in the sender's contacts. We mapped every combination to a defined channel, message and call to action, with the failure cases written down rather than found in production. That is error prevention moved out to the app's outbound edge, and it shipped as a document product and engineering still extend for each new feature.