By Gordon Lau
“This is the new model of wood burning stoves. They are selling like hotcakes!” Zappora proudly quipped as she flipped through the EzyLife product catalogue, sporting her smartly branded yellow golf shirt as I sat on the floor of a hired van, bumping along a dusty road leading away from Kitui to an even more remote settlement some hours away.
She continued to expound the virtues of the stove: It is durable, insulated and efficient – reducing cooking fuel cost for a typical meal to 10 Shillings, from 50 Shillings for the traditional three-stone method practiced for generations. Even though it is not my background, as an engineer from Canada, I couldn’t help but to admire the design.
The confidence and energy from Zappora and her three colleagues were infectious, and my team and I couldn’t wait to see them in action. As I soothed my tailbone after a particularly large bump, it suddenly dawned on me how fortunate I was to be there, and yet, how my own engineering education didn’t really prepare me for this work.
For context, I was trained as a biomedical engineer at the University of Toronto, starting from math and foundational sciences and moving to a variety of systems and applications. After some work abroad, I completed a master’s degree in biotechnology with emphasis on innovation and entrepreneurship. What I didn’t have experience in was observing customers in the field – and this is what brought me to Kenya.
With no small amount of serendipity, I joined Grameen Foundation (http://www.grameenfoundation.org/) about a year and a half ago, honoured to work in a team of professionals dedicated to combating poverty with innovation. Examples of our work include mobile savings products in the Philippines(http://www.grameenfoundation.org/what-we-do/financial-services/savings) and a prenatal information service in Ghana that uses feature phones to transmit important health related information to expectant mothers (http://motechsuite.org/).
I myself am part of an exciting tech-startup building TaroWorksTM(http://taroworks.org/) – a SaaS (Software as a Service) solution growing as the first choice for managing field operations in the “last mile” – far flung areas where transportation is difficult and internet connectivity can be intermittent at best.
The TaroWorks team operates as a business, and one of our target markets is social enterprises – tax-paying, people-hiring businesses that seek to solve a social need sustainably using a viable business model. As an example, EzyLife sells useful household goods that save time and money (like efficient wood stoves) or increase productivity (like solar-powered lanterns).
The key innovations that allow them to serve the vast market of undeserved villagers is a mobile sales team like Zappora’s and strategic partnerships with savings or self-help groups that make payment by installment possible. Thus, rural Kenyans are able to benefit immediately from products distributed by EzyLife, and the benefits accrue in a virtuous cycle.
In fact, Kenya is a world leader in social businesses. Others including Sanergy(http://saner.gy/), D.light(http://www.dlightdesign.com/) and Honey Care Africa(http://honeycareafrica.com/) count amongst world-renowned companies receiving sizable capital investment from abroad. (They also count amongst our customers!)
One major shared challenge stems naturally from their mission – how to effectively manage operations with clients living in the last mile? With field staff potentially days’ drive away, how can headquarters get vital information about their activities and transactions? Going the other direction, how can the field staff be empowered with information from the central database so they can make better decisions on the ground when out of contact?
Often paper processes are adopted at first, being cheap and easy to train for, later giving way to spreadsheets manually entered by branches and emailed in – however even this eventually gums up, as errors and omissions make a mockery of any attempt at system management. Thus, lacking timely and accurate data, the social business cannot scale any further, limiting the impact of an otherwise brilliant idea.
This is where the Grameen Foundation and TaroWorksTM come in – our product allows any organization to put their workflow into an Android App, making it easy for field staff to follow standard operating procedures. They then collect information, review existing records or display multimedia files in a specific order set by headquarters. (I use the word ‘set’ because the user interface is all click-and-drag, and no programming skills are needed.)
The tasks can be done offline using our Android app, and the information is stored on the field officers’ mobile device until it is convenient to sync with a secure server in the cloud. By automating the paperwork, TaroWorksTM takes care of the details so field staff can focus on the real value-adding tasks. While the system is simple, implementation isn’t always as easy as one might think, because even though field staff around the world are almost always literate, some have never seen a smartphone before. So the design needs to be intuitive and user-friendly to appeal to people who are unfamiliar with mobile technology.
Hence our quest to understand our customers via observation and experimentation. While every organization that uses Taroworks is unique, optimizing their experience with the product requires a systemic approach: What are the company’s goals? Who are the end customers, and what are their needs? Which operations will they implement to pursue those goals? Who in the company will carry out which step in the process? What does the staff need to do their job?
Returning to my field visit… we arrived at a gathering of 20-25 people seated in an arc, and the EzyLife team took turns presenting the product. Following a live demo where a small bunch of branches was lit for the attendees to feel the intensity of the heat and someone stood on top of the stove to show its structural strength (not at the same time of course), the attendees were then asked by a show of hands if they would like to make a purchase. Hand after hand shot up around the arc. As Zappora said, they were indeed selling like hotcakes! A motorcycle deliveryman had to be called to bring extra stock just to meet the demand. I took notes as the team went about their business.
As I watched the situation unfold, I started to wonder, were the devices “getting in the way” of the interaction between salespeople and their customers? Which field officers were more adept, making the Android device an extension of themselves? How was this accomplished? The answer seems to be that instead of treating it as an alien object, the best staff explained what the device is for and actively included the customer in the process.
However, I also observed that some salespeople were writing down the customers’ names and serial numbers on paper. Perplexed, I asked why. It turned out it they had only limited time with the group, and typing all the transaction details into the device would have taken too long. This spurred ideas in my mind: Is there anything we can do? Perhaps install a larger keyboard or preload the customer lists? Maybe make use of the built-in barcode scanning function in our app?
I made a mental note to ask about it later, for here lies one of the pitfalls of being an engineer and having responsibility for seeing your tool in action, especially since I wasn’t taught user-centric design or ethnographic research techniques in engineering school – that we as engineers are trained problem solvers and have an occupational risk of not listening and watching, instead jumping ahead to prescribe the “right way” of doing things prematurely. This is an area where my designer colleagues skilled in user-centric design do a far better job.
Another useful point confirmed for me is that establishing rapport is very important in a field visit – I did not want anyone to be afraid of getting something “wrong” or get into the habit of answering what they thought I would like to hear. So I was conscious about talking to people, rather than at them, or worse, down to them.
Shortly after explaining my mission in the field, I made sure they knew I was genuinely interested in their opinion, because it is their user experiences that I need to immerse myself in. If they encountered any difficulty with our tool, I wanted to support them in finding their own solutions so they would be empowered and invested in their relationship with the technology.
After the visit, where did all this learning go? As with each field visit, when I got back to the office, I shared my experiences with our team so we could brainstorm about solutions. Given that we have different backgrounds in sales, programming, and customer support, there are often different approaches. These might translate to a new feature on our product; a video on our YouTube channel(https://www.youtube.com/watch?v=urEE5wyIql8&list=PLRMd5j92pyj0GhiA1nR2a8KdLH80YAaaq&index=1); or a new topic at a live training. Whatever we decide to do, we test it to make sure it has the intended result.
No work of engineering, software or otherwise, exists solely in a vacuum. The user and his environment are essential parts of the ecosystem (and the ones over which we have little control). As such, we need to take that into account in the design, construction, training and improvement of our solutions.
I would posit that any engineer who deems their work to be done after the last line of code is compiled or last panel bolted down would be in for a rude shock. It doesn’t matter how busy we think we are, or how much our boss needs us in the office, it behooves us to get in a van, get out on the dusty bumpy roads, and see things for ourselves.
?
