How to test a tech idea with the people who need it

A group of talented young developers once spent six months building an app to help market women track their sales. It had graphs, reports, colour-coded dashboards and a login with a very secure password.

When they finally showed it to market women, the reactions were polite but clear: "Where do I click?" "Why do I need a password? My phone is always with me." "I don't have data to use this every day." "Can it speak Fon?" "My daughter will do it for me… maybe."

The app was well built. It just wasn't built with the people who needed it.

How can innovators test their tech ideas with real users early — before spending months building the wrong thing?

Why testing with users matters

Technology fails for many reasons. One of the most common is building something people don't want or can't use. Research on start-up failures by CB Insights has repeatedly found "no market need" among the top reasons companies fail.

In Africa, the gap between builders and users can be especially wide. Developers may live in cities, speak English or French fluently, have fast internet and modern phones. Many users may live in different conditions: rural areas, local languages, basic phones, expensive data. What seems "easy" to a developer may be confusing to a user.

The solution: involve users from the beginning. This approach is called human-centred design (or user-centred design).

Testing with just five users can reveal most of the major usability problems in a design. (Jakob Nielsen, Nielsen Norman Group, "Why You Only Need to Test with 5 Users," 2000) You don't need a big budget — you need to talk to the right people.

Step 1: Understand before you build

Before building anything, spend time with the people you want to help. Watch them. Ask about their lives.

Good questions (based on Rob Fitzpatrick's "The Mom Test"):

• "Tell me about the last time you [had this problem]."
• "What did you do about it?"
• "What was hardest?"
• "How much did it cost you in time or money?"
• "What have you tried before?"

Avoid questions like "Would you use an app that does X?" People are polite; they'll say yes. Ask about what they actually did, not what they might do.

Joke break: If you ask your aunt whether she'd use your app, she'll say "Yes, my child, it's wonderful." If you ask her what she did yesterday to track her sales, she'll show you a notebook, a calculator and a very organised plastic bag. That's your real competition.

Step 2: Go where users are

Don't only test in your office. Go to:

• Markets, shops and workshops.
• Farms and cooperatives.
• Schools and health centres.
• Homes (with permission).
• Transport hubs.

Watching people in their real environment reveals things they wouldn't mention: noise, sunlight on screens, busy hands, shared phones, poor network, interruptions.

This matters especially for low-connectivity contexts — see How to design useful technology for low connectivity.

Step 3: Start with paper

Before coding, sketch your app on paper. Draw each screen on a card. Show users the "home screen" and ask them to tap (with their finger) where they would go to do a task. Swap cards to show the next screen.

Paper prototypes are:

• Cheap (paper and pens).
• Fast (you can change a screen in seconds).
• Honest (users criticise paper more freely than a polished app).

Designers at many global tech companies use paper prototyping. It works just as well in Cotonou as in California.

Step 4: Give tasks, then stay quiet

During a test, give the user a task: "Record a sale of 3,000 francs." Then watch. Don't help. Don't explain. Don't defend your design.

Ask them to "think aloud": say what they're thinking as they go. "I'm looking for… maybe this button? No…"

Take notes on:

• Where they hesitate.
• Where they make mistakes.
• What words confuse them.
• What they say they like or dislike.

It's painful to watch someone struggle with your design. That pain is valuable.

"Pay attention to what users do, not what they say." — Jakob Nielsen, usability expert

Step 5: Test the whole experience

Tech isn't just the screen. Test:

• Onboarding: How do users sign up? Do they need an email (many don't use one)?
• Payment: Can they pay easily with mobile money?
• Data: How much data does it use?
• Language: Do users understand the words?
• Support: If something goes wrong, who do they call?
• Trust: Do they feel safe entering personal information?

Sometimes the biggest barrier isn't the app — it's trust. See How small African brands earn trust.

Step 6: Use a "Wizard of Oz" test

Before building complex technology, fake it. In a "Wizard of Oz" test, users interact with what seems like an automated system — but a human is doing the work behind the scenes.

Example: You want to build an AI chatbot that answers farmers' questions. Instead of building the AI, set up a WhatsApp number. Farmers send questions; an agronomist answers them manually. You learn what farmers ask, how they phrase questions, what time they message and what answers help. Then you decide whether (and how) to automate.

This saves months of building the wrong thing. It connects to our guide A practical guide to testing a business idea.

Step 7: Measure real behaviour

After an early version is live, watch what people do:

• How many people sign up?
• How many complete the main task?
• How many come back after a week?
• Where do they stop?

Behaviour tells the truth. If 1,000 people download your app but only 20 use it after a week, something's wrong — no matter how many people said they loved it.

Step 8: Include people who are often left out

Test with a diverse group:

• Women and men.
• Older and younger people.
• People with lower literacy.
• People with disabilities.
• Rural and urban users.
• Speakers of different languages.

If you only test with your university friends, you'll build an app for university friends. See What girls need to feel welcome in a tech class for why diverse perspectives matter from the start.

Ethics: respect your testers

• Ask for consent and explain the purpose.
• Protect personal data.
• Pay or thank participants for their time (airtime, a small gift, a meal).
• Don't make promises you can't keep ("This will make you rich!").
• Share results back when possible.

Users aren't "test subjects." They're partners in building something useful.

Real examples

• M-Pesa's early pilot in Kenya revealed that users mainly wanted to send money to family — not just repay microloans, as originally planned. The team adapted, and the rest is history.
• Ushahidi started as a quick tool built by Kenyan technologists during a crisis, shaped by how people actually reported events via SMS and web.
• Many African health apps have been redesigned after field tests showed health workers needed offline access, simpler forms and local languages.

These examples show that listening to users isn't a delay. It's the shortest path to something that works.

Mistakes that ruin user tests

• Testing only with friends. They know you and want to be nice.
• Leading questions. "Isn't this button easy to find?" pushes users toward yes.
• Explaining too much. If you have to explain it, the design isn't clear yet.
• Testing in the wrong place. A quiet office hides the noise and interruptions of real life.
• Ignoring the "small" complaints. If three people hesitate at the same screen, it's not small.
• Testing too late. After six months of coding, it's painful and expensive to change direction.

Turning feedback into decisions

After each test round, sit with your team and sort findings into three groups:

• Must fix: problems that stop users from completing key tasks.
• Should fix: problems that slow users down or confuse them.
• Nice to have: suggestions and ideas for later.

Fix the "must fix" items first, then test again with new users. Repeat. Each round, your product gets closer to what people really need. For a similar process in business, see Why customer feedback matters more than a logo.

A simple user-testing plan for your next idea

Week 1: Interview 10 potential users about their current behaviour. Week 2: Sketch paper prototypes and test them with 5 users. Week 3: Improve and build a clickable prototype (tools like Figma) or a WhatsApp-based "Wizard of Oz" version. Week 4: Test with 5–10 new users in their real environment. Week 5: Decide what to build — and what not to build.

Build with, not for

The biggest mindset shift in technology design is simple: stop building for people. Start building with them.

The market women in our opening story weren't the problem. They were the solution — if only the developers had asked earlier.

Keep reading: From a classroom robot to a local solution, The questions to ask before using AI in schools, and our Technology & Innovation section.

Questions

How many users do I need to test an app?

Testing with about five users per round can reveal most major usability problems. Test several rounds with different users.

What is a paper prototype?

A hand-drawn version of an app's screens on paper, used to test ideas cheaply before coding.

What is a Wizard of Oz test?

A test where users interact with what looks like an automated service, but humans perform the work behind the scenes to learn what users need.