Design thinking for Pakistan mobile app problems

Use design thinking for a Pakistan mobile app by studying a specific service failure, such as a shopkeeper waiting to confirm a Raast payment. Interview buyers and merchants, define the trust gap, create several mobile-screen prototypes, and test whether people can complete and verify payment without assistance.

Key takeaways

• •Start with one observable Pakistani service problem, not a broad idea for an app.
• •Treat identity, payment trust, language, device sharing, and connectivity as research questions rather than assumptions.
• •Use floow.design during ideation to generate competing mobile-screen hypotheses before committing engineering time.
• •Test tasks with realistic payment amounts, names, network conditions, and participant routines.

What's on this page

• •Choose one Pakistan problem to investigate
• •Define the user persona and the real constraint
• •Ideate screens before choosing one solution
• •Prototype and test with realistic Pakistani routines

Choose one Pakistan problem to investigate

A useful design thinking exercise starts with a narrow moment of failure. For example: a customer has sent a Raast payment, but a small merchant cannot quickly tell whether the transfer has arrived. Raast belongs to Pakistan’s national digital-payment infrastructure, so the opportunity is not to invent another payment rail; it is to improve the mobile experience around confirmation, status, receipts, and recovery when a customer says, “I have paid.” The State Bank of Pakistan documents Raast within its payment-system work at sbp.org.pk.

Frame the fieldwork around behaviour. Observe how the merchant currently checks payments, records sales, resolves disputed confirmations, and handles a weak signal. Interview customers who pay with their own phone and people who rely on a family member’s device. Ask what proof each person trusts: a success state, a reference number, an SMS, a transaction history entry, or the merchant’s own acknowledgement. Do not begin by asking whether users “want a better app.” Ask them to replay the last awkward payment.

Define the user persona and the real constraint

Turn research into a concise problem statement: “A neighbourhood merchant needs an unambiguous, fast way to verify an incoming payment because a customer’s success screen alone does not always settle the sale.” Build a user persona from evidence, not demographics alone. Include the person’s payment routine, phone ownership, confidence with transaction states, fallback behaviour, and what a failed sale costs them.

Identity should be handled with equal care. Pakistan’s public digital identity infrastructure is associated with NADRA, but that does not mean every app concept needs to collect identity details or present itself as connected to NADRA. First decide what information is necessary for the task, what can remain optional, and what users must understand before sharing it. NADRA’s official information is available at nadra.gov.pk. A good definition phase distinguishes a genuine identity-verification need from a simpler need: recognising a returning customer, retrieving a receipt, or resolving a payment dispute. That distinction prevents an intrusive onboarding flow from becoming the default answer.

Ideate screens before choosing one solution

Generate several mobile-screen hypotheses for the same payment-confirmation problem. One flow may prioritise a large “payment received” status with the amount and time. Another may show a merchant-facing activity feed with recent incoming transfers. A third may focus on a shareable receipt and a clear pending state. Each is a hypothesis about what reduces uncertainty; none is the answer until users attempt the task.

Use floow.design during ideation to create these alternative screen sets quickly: payment request, customer confirmation, merchant verification, pending status, failed-payment guidance, and receipt history. Keep the differences deliberate. If every prototype has the same information hierarchy, testing cannot reveal which hierarchy people understand. Make copy concrete and avoid unexplained banking shorthand. Show the amount, transaction time, and a plain-language next step. Consider how the screen behaves when connectivity is interrupted: it should not imply that money has arrived merely because a request was submitted. This work supports the wider direction of the government’s Digital Pakistan initiative, a policy programme launched in 2018; official ministry information is published at moitt.gov.pk.

Prototype and test with realistic Pakistani routines

Build a tappable prototype that covers the entire task, including uncertainty. Give participants a realistic scenario: a customer pays at a counter, the merchant needs confirmation, and the connection becomes slow before the sale is completed. Ask them to show what they would do, rather than explaining the intended flow. Measure task completion, wrong taps, hesitation around status labels, and whether the participant can state what happened to the payment.

Recruit across the routines that matter to the hypothesis: merchants and customers, users who transact frequently and infrequently, people using their own device and those who share access. Test in the language participants naturally use; translated labels are only successful if they are understood in context. After each session, separate findings into comprehension problems, trust problems, and technical constraints. Then revise one screen decision at a time and retest. A prototype should also make its limits clear: do not display a fabricated balance, impersonate an official payment service, or claim NADRA or Raast integration unless the product actually has it. Honest states build more trust than polished but misleading ones.

Research checklist for a Raast payment-confirmation prototype in Pakistan

Common mistakes

Starting with a full financial-app feature list.

Limit the first cycle to one payment-confirmation task and one measurable user outcome.

Treating a customer success screen as proof a merchant will trust.

Prototype a merchant-verification view and test the exact evidence merchants use to complete a sale.

Adding identity fields because a public identity system exists.

Request only data required for the task, explain why it is needed, and never imply NADRA integration without it.

Testing only a happy-path payment flow.

Include pending, interrupted, and failed states, then observe whether participants know the next safe action.

Frequently asked questions

How do I use design thinking for a Pakistan app?

Use design thinking for a Pakistan app by choosing one real user task, interviewing people who perform it, defining the main friction, creating alternative mobile-screen prototypes, and testing them in realistic conditions. For a Raast-related payment flow, test how customers and merchants understand confirmation, pending status, receipts, and recovery after an interrupted transaction.

What local problem should I prototype first?

Prototype a narrow, repeated problem first, such as a merchant confirming that a customer’s Raast payment has arrived. It has a clear task, two user perspectives, visible trust decisions, and meaningful failure states. Avoid starting with a complete wallet or banking app; test confirmation, receipt retrieval, and pending-payment guidance before expanding scope.

How do I test ideas with Pakistani users?

Test ideas with Pakistani users by recruiting participants who actually perform the target task, giving them a realistic scenario, and asking them to act through a mobile prototype without coaching. Include relevant routines such as merchant and customer roles, shared-device use, differing transaction frequency, and interrupted connectivity. Record completion, confusion, trust cues, and the language participants use.

Should a Pakistan app use NADRA information in onboarding?

A Pakistan app should use identity information in onboarding only when it is necessary for the user task and the product has a legitimate, implemented verification arrangement. Pakistan’s public digital identity infrastructure is associated with NADRA, but designers should not imply NADRA connection merely through labels or visual cues. Test whether a simpler account or receipt-retrieval flow solves the user need.

Where this leaves you

The strongest Pakistan mobile-app concepts begin with a specific moment of uncertainty, not a generic digital-service ambition. Research the routine, define the trust gap, use floow.design to compare screen hypotheses, and test the difficult states before building the product.

---

Design the screens first

Describe the app in plain language and floow.design draws the iOS and Android screens for you, ready to refine and hand off.

Start designing free →

---

Sources

• •State Bank of Pakistan
• •National Database and Registration Authority
• •Ministry of Information Technology and Telecommunication