Beyond Translation: 10 Principles for Designing Health Products for Real Life in Asia and Africa
A product that travels well on paper can struggle in practice, because it carries assumptions about how people live, communicate and receive care. Ten principles for designing with local context in mind.
Suhina Singh
Founder & CEO, Jonda Health
October 12, 2026
·
9 min read
In short
Health products often travel well on paper and poorly in practice, because they carry assumptions about how people live, communicate and receive care.
Those assumptions fall into four layers of context: language, devices and connectivity, family and community, and local systems and rules.
The ten principles below cover all four layers, each with a “do this, avoid this” example.
Translation is necessary, but it is only the beginning. Real localisation starts with research in the setting where the product will be used.
A product launches in one market and does well. The same product, carefully translated, launches in another and struggles. Patients download it but do not return. Clinic staff keep their paper registers. Family members call the clinic instead of using the app built for them.
The design was not wrong. It was designed for a particular context, and it carried that context with it: assumptions about which language people read, which phone they own, who helps them manage their health, and how information and records move through the health system.
This guide is for health app teams, clinics and hospital groups, pharma teams running patient support programmes, and companies taking products into new markets across Asia and Africa. It sets out ten principles for designing with local context in mind, grouped into four layers.
Layer 1: Language
1Treat language as design, not translation
A direct translation can be accurate and still feel unnatural, too formal or confusing. Clinical terms are especially difficult: some have no everyday equivalent, and a literal translation may mean something different, or nothing at all, to a patient.
DoWork with native speakers who understand health, test key screens with local users, and keep a reviewed glossary of clinical terms for each language.
AvoidMachine-translating clinical explanations and shipping them without review, or translating only the interface while results stay in another language.
2Support people who switch languages and scripts
Many people move between languages in everyday life, reading a laboratory report in English, speaking to their doctor in a local language and messaging family in a third. Scripts vary too, and text in some languages runs much longer or needs more vertical space than in others.
DoLet people change language easily at any point, test every layout with the longest language and with non-Latin scripts, and keep clinical terms searchable in more than one language.
AvoidLocking the language at sign-up, or designing layouts around short English labels that break in other languages.
3Write for health literacy, not only for language
Being able to read a language is not the same as being comfortable with health information in it. Health literacy varies widely within every population, and a good translation of complex text is still complex text.
DoUse plain language, short sentences, and visuals that support the words, and check understanding with real users, as we describe in The Patient Results Design Guide.
AvoidAssuming that professional or academic wording becomes clear once it is translated.
Layer 2: Devices and connectivity
4Design for the phones people actually have
Product teams often design and test on recent, high-end phones. Many of the people they are designing for use older or entry-level devices with limited storage, and in many households a phone is shared between family members.
DoTest on the devices common in the market, keep the app small, and write notifications that do not reveal sensitive health details on a shared screen.
AvoidLarge downloads, heavy animations, or notifications such as “Your hepatitis B test result is ready” appearing on a phone the whole family uses.
5Work with patchy connectivity and the cost of data
Connections drop, especially outside cities, and mobile data is a real household expense for many people. A product that needs a strong connection to load a page, or quietly uses a lot of data, will be used less.
DoKeep pages light, let key information such as upcoming appointments and recent results be viewed offline, and save forms so nothing is lost when the connection drops.
AvoidScreens that fail completely without a connection, or large images and videos loaded automatically.
6Meet people on the channels they already use
In many markets, messaging apps such as WhatsApp, LINE, Viber or Zalo, and in some settings plain text messages (SMS, short message service), are how people communicate with each other and increasingly with their clinic. Asking them to open a separate app for every reminder often means the reminder is missed.
DoUse familiar channels for reminders and simple updates, keep sensitive detail inside a secure space, and follow local rules on consent and data transfer for each channel.
AvoidSending results or diagnoses through general messaging channels, or relying only on in-app notifications.
Layer 3: Family and community
7Design for family involvement, with consent
Across much of Asia and Africa, health is managed as a family. An adult child books appointments for a parent, a spouse collects results, and a relative who lives in the city helps someone in a rural area understand a report. When the product only recognises the patient, family members borrow logins or fall back on phone calls.
DoOffer proper caregiver roles, with the patient’s consent, clear permissions for what each person can see and do, and an easy way to change or remove access.
AvoidTreating shared access as misuse, or giving caregivers all or nothing with no way to limit what they see.
8Respect who people trust and how they expect to be addressed
People act on health information when it comes from someone they trust: their own doctor, a community health worker they know, or a respected family member. The way a message addresses them matters too. Forms of address such as “Khun” in Thailand or “Bapak” and “Ibu” in Indonesia, and polite markers such as “po” in Filipino, signal respect, and their absence can make a message feel cold or even rude.
DoSend messages in the name of the patient’s own clinic or doctor, use the forms of address people expect, and involve community health workers where they are part of care.
AvoidGeneric, brand-voiced messages from an app the patient does not know, or informal tone copied from consumer apps in another market.
Layer 4: Local systems and rules
9Fit local data realities
Health information does not look the same everywhere. Paper records and registers are still common. Laboratories use their own report formats and local code sets. Names vary: many people in Indonesia and Myanmar use a single name or no family name, and in the Philippines the middle name is usually the mother’s maiden surname. Dates may follow a different calendar, such as the Buddhist Era in Thailand or the Ethiopian calendar in Ethiopia.
DoDesign name, date and identifier fields around local conventions, plan how paper and local-format records will come in, and map local codes to shared standards without losing the originals.
AvoidRequired “first name” and “last name” fields, fixed date formats, or assuming every record will arrive as clean, structured data.
10Respect local privacy and data residency rules
Most markets across Asia and Africa now have data protection laws, for example Singapore’s Personal Data Protection Act 2012, the Philippines’ Data Privacy Act of 2012, Kenya’s Data Protection Act 2019, South Africa’s Protection of Personal Information Act 2013, Nigeria’s Data Protection Act 2023 and Rwanda’s Law No. 058/2021 on the protection of personal data and privacy. Requirements on consent, sensitive health data, cross-border transfer and where data is stored differ from one country to the next.
DoCheck each market’s rules early, design consent flows around them, and choose infrastructure that can process and store data in the country where that is required.
AvoidAssuming one privacy approach, or one data location, will satisfy every market you enter.
Same product, different realities
It helps to put the assumptions side by side. Before designing for a new market, we suggest the team writes down what it has assumed in each layer, and then checks those assumptions against what people there actually do.
How to research locally
None of these principles can be applied well from a distance. We suggest five steps before and during a launch in a new market.
Go to the setting, or work through people who are there. Visit clinics and homes where possible, and work with local partners who understand the health system and the community.
Test on real devices and real networks. Use the phones and connections common in the market, not the team’s own.
Include the whole circle of care. Speak with family members, caregivers, clinic staff and community health workers, not only patients.
Pilot small before scaling. Start with one site or one group, watch what happens, and adjust before expanding.
Review after the first month. Look at who is and is not using the product, and go back to the people who stopped.
How Jonda Health can help
We work across Asia and Africa with clinics, laboratories, health programmes and digital health companies, and we have seen how much local context shapes both the experience and the data underneath it.
Jonda Health Services: design, build and prove
Local research with patients, caregivers, clinic staff and community health workers.
Design for language, literacy, shared devices and family involvement.
Market entry support that brings experience, data and local rules together.
Pilots designed to show value before you scale.
JondaX: make local data usable
A single application programming interface (API) for records in local formats, including PDFs, scans and device photos, across more than ten languages.
Local code sets and naming conventions handled, with originals kept and records mapped to medical coding standards after review by clinically trained reviewers.
Deployment and processing within the country where that is required.
ISO 27001 certified and designed to comply with the Health Insurance Portability and Accountability Act (HIPAA), the General Data Protection Regulation (GDPR) and the Personal Data Protection Act (PDPA).
Taking a health product into a new market?
In a free 30-minute conversation, we will walk through the four layers with you and help you identify the assumptions worth testing first.
