technology
· · 3 min readDesigning for Shared Devices
Most software assumes one device per person. In much of Africa, one phone serves a household. Here's how we design for account switching, privacy, and multi-user patterns.
By Bryan Fawcett
There is a quiet assumption in most software: one device, one person. Your phone is yours. Your browser history is yours. Your notification stream is private. The entire UX paradigm of modern consumer apps — persistent login, personalised feeds, biometric unlock — depends on this assumption.
In much of Africa, it doesn't hold.
One smartphone serves a household. A mother checks her EcoCash balance, then hands the phone to her son for school resources, then to a neighbour who needs to look something up. In a rural clinic, one tablet is shared between three nurses across shifts.
This isn't a niche edge case. It's the default.
What breaks on shared devices
Persistent login becomes a privacy violation. If I'm logged into a health app and hand my phone to my son, he can see my medical information.
Notifications leak context. Push notifications arrive on the lock screen regardless of who's holding the device. A message about a medical appointment, a payment confirmation — all visible to whoever glances at the screen.
Personalisation becomes confusion. Content feeds trained on my behaviour make no sense to the next person who picks up the phone.
How we design for this in Mukoko
Mukoko is a super-app with seventeen mini-apps. All of them run on the same device, often the same shared device.
Account switching as a first-class primitive
Account switching is one tap from the home screen. We support up to five accounts on a single device, each with its own session, notification preferences, and data boundary. When you switch accounts, the app swaps the entire context: feed, conversations, wallet, calendar. There is no bleed-through.
Every data query in the app is scoped to the active account. Every cache is partitioned. Every background sync is associated with a specific session.
Dignity defaults
We have a design principle we call "dignity defaults" — the default configuration should never embarrass the user:
- Notifications for sensitive apps (Health, Wallet, private Campfire conversations) are content-hidden by default. The notification says "New update" rather than showing the message content.
- Financial amounts are masked on the home screen widget. You see that you have a balance, not what it is. Tap to reveal.
- The lock screen shows the active account's avatar, not their name.
Session timeout with context
Sessions expire, but the timeout is context-aware. A health information session expires faster than a marketplace browsing session. A wallet session requires re-authentication for any transaction above a threshold.
The 56-pixel rule and outdoor readability
56-pixel minimum touch targets. Not 44px (Apple's guideline) — 56px. Larger targets are more forgiving of imprecise taps in direct sunlight.
APCA Lc 90+ contrast on body text. We use the Accessible Perceptual Contrast Algorithm rather than WCAG 2's simpler contrast ratio. APCA accounts for font size, weight, and the actual perceptual experience of reading text.
100KB JavaScript budget per route. The devices we design for have limited memory and the networks have limited bandwidth. A Tecno Spark on 3G cannot afford a 2MB JavaScript bundle.
Why this matters beyond Africa
Shared-device design is not an African-market workaround. Families in any market share iPads. Clinics everywhere share tablets. Retail staff share point-of-sale devices. The patterns we've built — account isolation, dignity defaults, context-aware sessions — are patterns any multi-user application should consider.
Bryan Fawcett is the founder and CEO of Nyuchi Africa. Mukoko is the consumer surface of Nyuchi's frontier infrastructure.