Design Diary: Nigerian Edition!
July 30, 2012
Every day at Reboot is a little different, but we wanted to share some stories from a recent trip to Nigeria, where we are working on a World Bank project to allow citizens to share their input on the delivery of government services.
We determined in earlier stages of the project that text messages are the best means to allow the greatest number of citizens to participate in the program. Thus, with our partner Dimagi, we are developing a basic mobile tool to allow citizens and trained reporters to provide feedback on two services: an agricultural subsidy program and a series of health care clinics.
In parallel, we are designing mechanisms by which the World Bank and the Nigerian Ministries of Agriculture and Health can monitor and act on the incoming feedback to improve their respective programs.
Currently, we have a late-stage prototype of the system — a mobile tool for citizens, and a web dashboard for program implementers — as well as communications and training materials to ensure awareness and understanding of the initiative. Our team was recently in Nigeria to test these prototypes, and to begin preparations for program launch, and we thought we’d share what a typical day might look like.
The day starts with a working breakfast. Here, the team gathers at our guesthouse for a typical breakfast of fried yams and oats, and plans the day. Today, we’re splitting up into two teams: Team A will be doing user testing in a neighbouring village, and Team B will be traveling to the state capital to meet with government stakeholders and do testing and consultations with them. Getting the perspectives of both sides is critical to ensuring that we design a solution that is impactful and realistic, given the needs and capacities of both beneficiaries and implementers.
When Team A arrives in the village, the first thing we do is meet with the village leadership. It is our fourth visit to this particular village in the past few months, but we always check in with the village leadership, to say hello, keep them abreast of our activities, and solicit any feedback they might have. From there, it is off to an impromptu meeting with the community residents to introduce our latest prototype. Group interviews are a great way to identify broad themes — questions, challenges, new opportunities — that we can pursue in greater detail in later one-on-one interviews.
One-on-one interviews form the bulk of our research and testing. They allow us to get more in-depth responses, and to reduce the impact of direct and indirect influence by peers on respondent responses. Our interviews are semi-structured, meaning that they follow a central framework but allow us to go “off-script” as the situation permits. We respect the time respondents spend with us, and we make sure they a) fully understand the purpose of our work and how their participation fits in, b) have the opportunity to refuse photography (or delete photos they do not like), and c) can ask plenty of questions. To protect their privacy, we scrub the data for any identifiable information and we use composite identities when we publish findings.
While interviews are important, so is understanding the context in which we are working. This can mean embedded ethnographic observation, shadowing people in their daily routines, or using the services that they use to understand the service experience. We often meet with people in their homes to get a whole and more accurate picture of their lives. For example, what people hang on their walls says a lot about them. And what people do is often different from what they say they do—observing them in a comfortable environment allows us to understand these discrepancies, and get details that would never surface in a conversation.
Designing and building prototypes is integral to our work. Sometimes, our prototypes can be quite elaborate, but more often than not, we build them quickly and cheaply. This allows us to rapidly test possible solutions, and to rule out ineffective ones early on. This means that we can then focus time and attention on the best solutions, as determined by actual users. For the first few months of this project, before we spent time and money on anything fancy, we used a simple USB dongle and a netbook to create our testing server.
This allowed us to quickly get a working prototype in people’s hands. Here, a tester gets a prompt from our system that says,“Get your voice heard.” She then tries to call the number to share about their experience by voice, not by SMS as we’d intended. We capture all this feedback for later that evening. Throughout our process, we observe users testing our applications and encourage them to ‘think out loud’ so that we can understand how they use the system, as well as questions or points of confusion that arise.
In the meantime, Team B has gone to the capital to consult and test with government implementers. Understanding how our implementing partners might use the tool — both the technology, and how it works with their organizational processes — is critical. Our social accountability platform will integrate into existing monitoring and evaluation framework, as well as grievance redressal procedures, so it’s key that we get government feedback frequently and regularly.
Here, the team is testing with a government official a web dashboard that will be used by implementers to monitor and respond to the feedback submitted by citizens. As with Team A’s feedback from citizens, his insights are captured for integration in future iterations of the dashboard. For instance, many of them wanted the ability to better distinguish between issues that needed urgent intervention, and others that were less so. The team then developed a prioritization feature in the dashboard, to allow all received issues to be classified according to urgency.
At the end of each day, we head back to HQ—in this case, our guesthouse—for evening synthesis. Night is often the best time to work in Nigeria, since the power (from diesel generators) is often turned off from 8am to 6pm and the daytime temperatures can top 40 degrees Celsius (over 100 Fahrenheit). These sessions involve different exercises to allow the team to come back together and share our experiences, draw out key insights from the day’s activities, make connections between data points, raise new questions to explore the next day, and determine the iterations that then need to be made to our system before the next day’s testing begins.
Based on the outcomes of synthesis, we then tweak different parts of the product to come up with something that is one step closer to a final version. Iteration might mean adding a new feature, re-ordering the flow of the content, or adapting an interface design to make it more user-friendly. In essence, this is anything that gets us closer to a service that “just works” for the user.
Needless to say, the sessions can run well into the night. What is wonderful about this block of time is that it enforces a period of reflection on what we have learned. It can be challenging to meet the needs of a research project that has constantly changing schedules and impromptu opportunities — and our end-of-day synthesis allows us to come back to our research intentions, check off the to-do list, and establish priorities for the next day.
So that we can wake up, have breakfast, and do it all over again!
—
This blog post was originally published on Reboot Ideas on July 30, 2012.
