Usability testing in Africa: what's different

A usability test anywhere is the same idea: give someone a real task, watch them try it, and ask what they expected. Five people usually show you the biggest problems.

What's different in many African markets is everything around the task: the phone in their hand, the data on it, the power in the room, the language in their head and how polite it feels to criticise a guest's work. Plan for those and your results get much better.

Most people across Africa go online on a phone, and it's often a mid-range Android with little free storage, not the latest iPhone on your desk. An app that feels fast on your phone can feel slow or crash on theirs.

• Ask in your screener which phone people use, so you test across the range your customers have.
• Try your prototype on a cheaper Android phone yourself before the first session.
• Watch for what a flagship phone hides: slow loading, small screens, text that doesn't fit, and apps people have deleted to free up space.

Most people pay for data in bundles, so a video call or a heavy prototype costs them something. Say in the invite how long the session takes, keep prototypes light, and make the reward worth the data as well as the time.

Power cuts (dumsor in Ghana, load shedding in South Africa) and weak network happen in many places. Agree at the start what you'll do if the call drops: wait five minutes for them to rejoin, then find a new time together. Don't blame the participant, and pay for the time they've already given you.

On myUsersInsight, a call that ends early pays for the minutes you talked. Calls under 10 minutes aren't paid, so if the network drops early on, wait for them to rejoin rather than ending the call.

Many people use English or French at work but think and joke in another language: Twi or Ewe in Ghana, Wolof in Senegal, Swahili in Kenya. When people have to translate their thoughts as they go, you hear less of what they really feel.

• Tell people they can switch language whenever they like.
• If your customers mostly speak one language, have someone who speaks it run the session or sit in.
• Test your product's words too: a button that's clear to you in English may not be to your customers.

In many places across Africa it's polite not to criticise a host, and a participant may see you as one. “It's fine” and “it's nice” don't tell you much. You get honest answers when people know criticism helps.

• Say at the start: “We're testing the app, not you. You can't do anything wrong, and problems you find help us most.”
• Ask people to show you, not tell you: “Show me how you'd send money to your sister” beats “Would you use this?”
• Ask about the last time they really did it, not what they'd do in general.
• Stay quiet when they get stuck. Count to ten before you help.

Mobile money scams are common, so people are rightly careful with links, codes and requests for money. A test that feels unsafe gets cautious, unnatural behaviour.

• Say who you are, who the research is for and how the recording is used, before you start.
• Never ask for a real PIN or real money in a test. Use test accounts and pretend amounts.
• Pay what you promised, when you promised it. That's how people decide to take part again.

On myUsersInsight, sessions are recorded only after the participant agrees on the consent screen, and rewards go to their mobile money after the session.

Remote sessions reach people far beyond the capital city, at a time that suits them, without anyone travelling. In person is better when you need to see the setting: a market stall, a shared phone, or someone who's less comfortable with video calls.

On myUsersInsight, calls open from a link on a phone or laptop, with nothing to install, and you can watch their screen when they share it. Task tests and quick tests record the participant's screen, so people take them on a laptop or desktop computer. Every session is recorded and transcribed, so your team can watch it later.

1. Write three to five real tasks, each starting from what people already do.
2. Ask in your screener which phone people use, and test across that range.
3. Try the prototype on a cheaper Android phone yourself first.
4. Keep the prototype light and say how long the session takes.
5. Agree what happens if the call drops, and pay for the time already given.
6. Let people speak the language they think in.
7. Open by saying you're testing the app, not them.
8. Never ask for a real PIN or real money.