At Angaza, we build tools that distribution businesses use to sell and manage loans for life-changing products like solar home systems, clean cookstoves, and solar water pumps. Designing a software product (including a mobile app) that enables our users to carry out their day-to-day responsibilities is a challenge. To tackle this challenge, Angaza employs design thinking to understand customer needs and craft solutions before even a single line of code is written.
What are some of the challenges we face on a regular basis?
We have close to 30,000 platform users in 30+ countries. There are many cultural nuances around loan management, clean energy products, and general infrastructure that have to be taken into account when testing and designing user flows.
Many of our users operate in areas with little to no network connectivity. This not only impacts app functionality, but also app adoption.
Our users have vastly different levels of education and technological literacy. Some of our users are using a smartphone for the first time, while others have college-level degrees in engineering or are software engineers themselves.
As product designers and builders, we regularly make assumptions about how users will interact with our product, usually driven by what we would do ourselves or what we think might be logical behavior. In turn, we invest resources into creating and launching these products, only to discover that our assumptions were wrong—or even to expose assumptions we didn’t realize we’d made. Early and frequent user feedback helps us avoid these costly mistakes. Firsthand user feedback and observation ensure that the product we build is actually solving users’ challenges, and that our resources are invested in the most efficient way.
As a B2B company, our customers are distribution businesses that sell products on credit. On a regular basis, we hear feedback on how they want to use our technology to scale their businesses. One of the most common requests we received was to add stock management functionality to our platform. So how did we use the design thinking process to build a feature that would meet our customers’ stock management needs?
*Users refers to all team members of a distribution businesses, which usually include sales agents, collection agents, call center agents, and management.
Design Thinking: Our Process
Observe
We spent two months researching our customers’ existing stock processes, tools, and pain points through individual interviews, group interviews, and in person observation. Our customers have very diverse distribution models that are highly dependent on the areas where they operate. For example, a sales agent who lives close to a stockpoint can regularly pick units up directly from the stockpoint and carry them by hand. If a sales agent lives far away from a stockpoint (1-2 hour of travel), a stock manager might send units on a motorcycle or bus to reach the sales agent.
* A local warehouse or store where stock is held for agents to collect and sell.
**The person responsible for managing inventory. Most common responsibilities include performing stock audits, dispatching units to agents, and repairing returned units. For some Kenyan distribution businesses, stock is transferred via boda (motorcycle) or by hand. A box may carry up to 10 units and weigh up to 5 kg.
Define
Through interviews with customers, sales agents, and management, we found that the biggest pain point was tracking a unit from when it left the local stockpoint to when it was sold. To define the specific challenge we were trying to solve, we crafted a needs statement using this template:
[specific user needs need because insight ]
Our needs statement was: Stock managers need increased visibility into product movement from stockpoint to sale because they are responsible for holding sales agents accountable for stock.
We used this needs statement to narrow our focus and define the specific challenge that we were trying to solve. As we designed the feature, we uncovered several additional challenges and found ourselves trying to solve everything at once. This not only led to an unfocused design but also blew up the project’s scope. Referring to this needs statement throughout the design process helped us stay focused on the specific problem we wanted to solve and which set of users that would use this tool
Prototype
Many of our users who are handling stock don’t have access to a computer, but do have access to a smartphone. Because of this, we focused on prototyping mobile solutions that were accessible through our app. For our initial prototypes, we used paper because it was faster and easier for outlining and sketching designs. The goal of this stage was to create quick and cheap prototypes to communicate our solution in a tangible way.
Feedback
Once we had a few prototypes, we spent three months doing user testing with our customers. We put our prototypes in front of 20 users from six customers across Kenya, Rwanda, Zambia, Senegal, and Sierra Leone, to make sure our solution met the needs of our partners across various operational models and country contexts.
One of the biggest lessons we learned from customer feedback was the need for permissioning the different actions that users could take with stock. For example, one distributor in Kenya wanted sales agents to be able to receive but not send stock, but allow stock managers to receive and send stock. A different distributor in Zambia didn’t have stock managers, and therefore wanted all users in the organization to send and receive stock. In order to account for the different operational preferences, we added permissions for each action, which allowed distributors to customize which actions their agents could take. This was an operational nuance that we had not anticipated in our initial design, and would have completely omitted without user feedback.
Iteration
Our paper prototypes went through another five rounds of revision before we created mockups in Sketch, which then went through another four rounds of revision. During testing, we gained a lot of insight from both hearing direct feedback and watching users interact with the prototypes. We incorporated customer feedback on everything from language (“The word ‘dispatch’ is too complicated”) to interface (“I didn’t see the button”) to overall user experience (“Confirmation messages are slowing down my ability to scan lots of units in a row”).
Implementation
Once we had a design in place, we had to consider two things: (1) how we would build the feature and (2) how our customers would implement the feature into their daily operations. During sprint definition, we presented the final design to our engineers, who identified a few key components of the feature that we missed during the design process—such as creating workflows for edge case scenarios. Once they began building the feature, we began creating resources to support customer deployment. We created a training framework and supplemental resources for teaching customers how to use the feature. We also worked with some of our customers to create an initial pilot, where they launched the feature with a subset of their users.
Lessons Learned
Along the way, we learned a lot of things.
Simplicity is key! There are a lot of great interactive resources to get user feedback on prototypes – Proto.io, InVision, Marvel. I spent several hours creating a working prototype for the stock management feature in Sketch and InVision. When I went to test these mockups with sales agents in Zambia, I realized that they lived and worked in areas with no electricity or mobile network. They also had never participated in user testing before, so I spent a lot of time trying to explain that this was an example that had no impact on their actual work or performance evaluation. When I reverted to paper and pen, it was not only easier to quickly create and reiterate, but it also allowed users to provide more candid feedback as they realized the impact their feedback had on the design. A few even picked up the pen and drew their own screens.
Frequent user feedback was critical to ensuring we were moving in the right direction before finalizing any designs. Every time I found myself saying, “I’m not sure if…,” our Product Manager and CEO would ask, “Can we get more feedback on this?” While it was tempting to wait until we had the perfect design before putting it in front of someone, we realized that the designs almost always changed each time we got feedback. The more frequently we involved our users in the process, the easier it was to validate our hunches and the more confident we were in the direction we were moving.
Leave room for implementation. Once our design was finalized, it felt like the project was complete. However, ensuring that our customers could deploy the feature at scale required just as much work—creating supplemental materials, planning the release, and identifying criteria to evaluate the usage of the feature. Many of our customers had more than 50 users who needed to be trained on how to use the stock management feature. Understanding how our users were going to introduce and implement the feature into their day-to-day was just as crucial as understanding their day-to-day needs and getting their feedback on prototypes. No design is good design if no one is using it—no matter how user-driven it is.
