Designing for Users You Haven't Met

Designers often design from the closest available mental model: their own. That works when users share similar vocabulary, devices, confidence, and context. It fails when they do not.

Collect’s users included business owners running daily finance work through ledgers, WhatsApp, and memory. Their relationship with technology was not worse than mine. It was different, shaped by different constraints.

The danger is thinking a label like “low digital literacy” explains the user. It does not. Labels flatten the real workflow into something too simple to design from.

Interviews tell you what users can describe. Field research shows what users actually do when the shop is busy, the phone is shared, the network is weak, and the customer is waiting.

That is where the useful contradictions appear: screenshots shared with staff instead of role-based access, WhatsApp records kept as backup, search used as navigation because it feels faster than menus.

These are not edge cases. They are design requirements hiding in everyday behavior.

Financial products are full of internal vocabulary: mandate, reconciliation, receivables, NACH, UPI Autopay. Teams use these words because they are precise. Users may not use them at all.

In Collect, “auto-debit setup” was often clearer than “mandate” because it described the thing in the user’s terms. The technical term was not wrong. It was just not the best interface word.

Every unexplained word is a small tax. The more unfamiliar the user, the more expensive that tax becomes.

A 44px touch target may be a minimum, but it is not always enough for a shop floor, a budget Android phone, or a user whose attention is split. Larger targets felt oversized in Figma and correct in the field.

Text size has the same problem. What looks readable on a designer’s display may fail on a small phone held at arm’s length.

Network tolerance also matters. A product that assumes reliable connectivity creates failure at exactly the moments where users most need confidence.

When you design for users under more constraints, you usually create a clearer product for all users. Plain language, larger targets, explicit loading states, and specific confirmations are not niche accommodations.

They are signs that the product respects real human context instead of idealized product context.