When we met with our first team of trainees a few months ago, we had no idea what to expect. Our training was to take place in Kotido district. Kotido is about 500kms North of Kampala. At this moment we had built a minimum viable product and wanted to test it with the end users and get feedback from them. Throughout our building process we had interacted with the program managers and everyone in-charge of supervising the program to understand their needs. It is with these results that we built our first minimum viable product.
Our first challenge was to find out what data this program needed to track. One of the major pain points that came out in a lot in our meetings was the need to have accurate, timely data informing the program directors about program deliverables. Questions such as; How much seed is being distributed? In what quantities? Who are the most benefactors of the program? What is the ratio of male to female? Which areas do the most seed voucher redeeming? These and many more questions seemed to be relevant to program directors.
The need to track the right kind of information is key for most social and humanitarian programs. In most cases many social programs don’t have the right data collected and end up with inaccurate reports for their program deliverables. This data collected is very essential for many other applications apart from the obvious which is to report back on program deliverables.
With the knowledge of the program needs we crafted some important data entry questions that would be asked from farmers using a USSD menu that we designed specifically for this project. The agro-dealers were to use this menu to enter basic data about farmers and also use the same menu to redeem seed vouchers while instantly getting paid for each voucher redeemed.
Northern Karamoja is one of the remote regions in Uganda. The road leading to Kotido is not entirely smooth as are many other roads in the country. After properly testing our product on different Mobile Network Operators, we were set to head to Kotido for our training. More than 40 participants, all agro-dealers and agents under the Growth, Health and Governance program from districts of Kaabong, Kotido and Abim attended the training. It’s important to note that while Northern Karamoja is one of the less developed regions in Uganda with very low literacy rates, our training was conducted in English with a translator who spoke Karimajong, a locally spoken language understood by many. Most agro-dealers however had a basic understanding of English and therefore would understand 90% of the information we were giving to them.
There were many lessons from the first training. A lot of things we thought we had right were interpreted differently by end-users. I can’t stress the following; Unless you spend time with the people with whom you are developing an intervention for, you will miss out a lot of valuable information that is necessary for your product or service to work. The whole idea of human centered design is very key in addressing and deploying technological interventions for people at the bottom of the pyramid.
Most of the tests we did with our system prior to meeting our clients were done on a smart phone while all the agro-dealers have basic feature phones that function differently. You may ask, how is this relevant? MNOs put a time limit on a USSD session, it usually lasts about 30 to 40 seconds long after which it times out. While using a smart phone to go through the USSD session you are most likely to beat this time but the person using a basic feature phone will still not have gone through half the questions on their phone. This was a great eye-opener for us. This is one of many lessons we learned from end-users that helped us go back and iterate and come up with another version of our solution that tested with them.
What we have found key in deploying tech interventions is that you have to keep the channels of communication between the end users and the developers open. You have to be able to understand their needs from their perspective and build backwards to meet these needs, that’s the only way they will use your intervention. Also key to note is that there’s need to be patient with end users, most of them will not always understand the tech intervention right a way and will need to constantly be reminded to finally understand the solution. Most importantly, your intervention has to be able to solve a pain point that is relevant to the end users as well. If an intervention only benefits programs and not the end-users, chances are that end-users will reject or passively use the intervention. It is therefore important to stress what the users stand to benefit by using your intervention.
Gathering feedback is also critical in helping your development team to improve in their next phase of development. As you go live with your intervention or solution, you will find out that many things will go wrong, or bugs will be introduced, or users will enter the wrong data. You have to constantly monitor the system to be ahead of these glitches and fixing them as fast as you can to ensure that the system performs smoothly.
These lessons have been key in our pilot implementation and we’ve been greatly successful because we listened to the end-users and helped build a product that they find easy to use. We’ve also made our team accessible for them to ask questions when they need help. The system is not without it’s flaws but we are constantly learning as we progress and the biggest lesson of them all is the ability to be open minded to listen to the people implementing programs and to make sure their needs are met.