CauseLabs and Library For All testing a digital prototype in Haiti.

I Don’t Speak the Language

Rapid Prototyping in a Developing Country

We do a lot of rapid prototyping at CauseLabs and testing them with your audience can be intimidating. Testing prototypes in a developing country when you don’t speak the language can be daunting. Here are five simple tips for getting over the language barrier so that you can get the best insights about your prototype.

1. Build a relationship with your interpreter

The quality of your interpreter can make or break the success of your prototype testing sessions. To mitigate the risk, invest in and plan time to get to know them. Things can get difficult; having a relationship in place makes things better.

• Treat your interpreter like a member of your team. Let them know the goals and outcomes you’re testing for. Their feedback may help you rethink and refine your approach.
• Ask for their candid feedback. Your interpreter’s knowledge of the local people, area customs and culture can be invaluable.

TIP: Ask your interpreter to share back exactly what the user said. You’ll gain better insights from a word for word translation versus the paraphrased version.

2. A few words can go a long way

Take time to learn a few basic words and phrases before you arrive in the field. Saying hello, please and thank you, can go a long way in building a relationship with your interpreter and users.

• Greetings: hello, goodbye, good morning and goodnight will help you greet and bid farewell any time of day.
• Being polite: please, thank you and I’m sorry. Being polite never gets old.
• Numbers and currency: Learn numbers 1–10 and how to ask “how much is this?” There’s no way to avoid spending money when in the field.

Google Translate for iOS.

TIP: Use the Google Translate app to favorite common phrases so that they’re always at your fingertips.

3. Keep your questions simple

Keeping your questions simple is a good rule of thumb for all prototype testing. This is especially important when working through an interpreter.

• Keep questions short so that sessions flow faster.
• Use simple words and steer clear of technical jargon. Complexity can get lost in translation and can cause more confusion than it’s worth.
• Plan on things moving slowly. Working through an interpreter simply takes more time.

TIP: Open ended questions can be great because they can take you to unexpected places. For example: “How would you redesign this screen?” could yield some interesting answers. However, this often trips users up. Asking simpler, more concrete questions tend to produce better results. For example: “Do you prefer the button on the top or the bottom?” is much simpler to answer. Take the feedback from these simpler questions and create another version of the prototype to test.

4. Leverage the power of comparison

Asking users to share why they like or dislike a single design in isolation can be challenging. Asking which design they prefer between two options is much simpler. As humans, we determine value by comparing and contrasting one thing to another.

Students from a rural school in Haiti testing prototypes side by side.

• When users consider two designs side by side it is easy for them to determine which one is better of the two.
• Not only is it easier for users to articulate which design they like better when comparing the two, it is easier for us to observe which is simpler for them to use. This is especially useful when you don’t speak their language.

5. Observe body language

We don’t all speak the same spoken language but we all nonverbally communicate through conscious and unconscious gestures and movements through body language. Often it’s the things we observe that yield the best insights about our prototypes. Here are a few things to keep in mind.

These users are leaning in and are actively engaged with the prototype.

• Remember, we are always communicating through body language. Even though the dialog is moving slower than normal through an interpreter, make sure to be hyper vigilant of your user’s body language, where their eyes are going or how they raise their eyebrows or change posture.
• A user may say they like a set of interactions, but their body language tells a different story. Use this insight to dig a little deeper.

Conclusion

With the tips above you should be running on all cylinders with your interpreter and collecting helpful insights about your prototype.

Thanks for reading. What tips would you add? And if you enjoyed it, hit the heart button!