Learnings from designing for Bharat

shreya
4 min readApr 2, 2021

I recently worked with a startup to design buying and reselling experience targeting young adults to middle age men in tier 2, 3 & 4 cities. The product enables users to buy wholesale items (soaps, noodle packets, washing powder, oil etc from multiple brands in large quantities) and sell them to shopkeepers in villages and semi urban places, 100s of km away from towns, earning a % margin from the sale.

There was an interesting take to the whole premise; 3–4 months after the product was open to a small set of users, pandemic struck. People were losing jobs. The platform saw traction amongst people who had recently lost their jobs, looking for some work to do without investing a whole lot of money from tier 2, 3 & 4.

This prompted us to relook at our users and the environments they were placed in. Here, the idea is to bring some of those observations forward that made us shriek about how less we knew our users and how important this exercise was.

Who really is the user?

The persona you have created is not your only user. The ecosystem around that human is.

Example- If your persona is a 39 year old shopkeeper from Kanpur(dehat), who is using your app/system everyday, do consider other family members he is surrounded with and what they do. He might be on-boarded on to the app by a nephew living in the same house who saw the product ad on Facebook. He might be taking help from his children to place orders and from his cousin brother who lives in the town to receive the order, because that pincode where he stays is not serviceable by the delivery partner.

Why the search function in your product will fail almost every time

So if your user wants to check the price of Maggi packets, he opens the app, taps on the search bar and types — ‘meg’, expecting auto suggestions but nothing comes up. So he goes ahead and types ‘meggi’ well…nothing again. So he deletes it and types, ‘megi’, then ‘megy’ then ‘magy’ then probably meggi again.

Upon pulling data from production we realised that there were many such instances of search results returning null, when the spelling was wrong.

User thinks that maybe the product is not available right now or there is something wrong with the app because he most certainly saw the product somewhere while scrolling through the product list. The moment is lost.

Please consider tagging products in your backend according to who the user is and how they actually look for something. One method doesn’t fit all. One language doesn’t fit all.

Product hierarchy and clustering

Sometimes a logical clustering system doesn’t work. It needs to be intuitive more than logical.

Observe the business lingo and use that to understand business relevant clustering. See what is placed next to what in physical shops and why spaces of business are arranged in a certain way. They might not subscribe to the same logic as you do.

Business ecosystem

If someone is an insurance agent, and has build relationships over a period of time by selling insurances, expect that person to adopt a complimentary business that also requires relationship based selling with much more ease than a complete novice. They would most likely using their existing clients to sell a few more things than just insurance.

Know the history of your users and the kinds of jobs they have been involved in. Most users have 2–3 parallel business that complement each other and influence value creation by each other.

Human customer support

If you are new in the market, users might explore your product but they are more likely to invest or put their money with you after they have had at least one human interaction. There is always more trust in a new product once the user has spoken to at least someone from the system, because they know who to catch hold of when something goes wrong.

Or there has to be enough number of people talking about it around the user to give that initial push(Online or offline).

Historic data

Users are more likely to trust the system if their historic data is properly accounted for. We observed instances where people either print out bill for each order and keep them in a physical filing system, or note down orders in a separate notebook to keep track. Filing systems are not only very important for tracking purpose but they also help in building trust.

Product ++

A product rarely completes all the user flows itself. It has integrations with many others to run all functions smoothly. Know about them and the popular patterns within them. Be careful of not creating contrasting patterns in other flows inside your product.

Safety conscious

With the times, users are becoming safety conscious. In order to reduce friction, do not remove all barriers to user entry and other tasks as they might end up feeling that product is not safe, and is probably a scam. A fine balance is key here.

Users won’t read

Be cautious of introducing extremely new patterns for familiar tasks. If you place a box to enter price (because logic says so) where users would expect to enter quantity, they would still go ahead and add quantity even if the label says add price. Be ready for these challenges during user testing if you’ve gone rogue(read experimental) during design.

Hope this was helpful! Uncovering what looks like chaos from far away and giving it the most intuitive order for the user is what we understood to be one way to approach design for bharat.

Special thanks to @surya for being an accomplice.

--

--