User insights are key to developing any product. This blog details out the dos and don’ts of Usability Testing to collect accurate and unbiased user insights.

In the early 90s, Kellogg’s cereals became synonymous with breakfast in several countries around the world but faced a rude jolt upon entering the Indian market. Why? Because it missed one important nuance. Indians predominantly had hot milk with sweetener for breakfast, a habit cultivated since childhood and carried on till late teens. But what happens when you add hot milk to cereal? It becomes soggy and chewy, basically extremely unappetising. So Kellogg’s made its way out of the Indian home quicker than it entered.

This is a classic example of why thorough usability testing is crucial for a product’s success. Relevance, recall and relatability are key to the success of any product.

In this blog, I will take you through the Usability Testing (UT) framework we use while designing a product, and how we ensure our results are accurate and free of respondent bias.

✍ Understanding Usability Testing

Technically speaking, it is testing a product with users, before it’s developed or launched, to get a clear understanding of how real users interact with the interface. However, it can also happen at other stages of product development based on requirements.

At Meesho, we believe in the mantra of User First, so it’s imperative that we intently listen to the user’s voice at all times. From designers to product managers to just about any stakeholder you can think of, we all directly interact with users to understand their challenges.

Generally, we conduct UTs by showing users visual screens, or by asking them to test our prototype via screen sharing or in-person interviews. That helps us gauge their intent throughout the journey. This kind of interaction is especially important for us — nearly 80% of Meesho’s consumers and sellers come from Tier 2+ towns, a vast cross-section of them new to e-commerce. By virtue of being the first-movers in this cohort, we discover unique challenges and, often, unexpected insights.

Here’s an example.

While working on a project around price recommendations, we identified that suppliers were facing challenges in getting a read of how competitors’ pricing might be impacting their sale prospects. We were giving them recommendations, but were they really understanding and using them to good effect? We decided to take a deeper look.

During initial research, we focused on sellers’ comprehension of content and design. Instead of asking them leading questions like “What do you comprehend from the Action tab?” or “Will you use it as reference to understand the competition?”, here’s what we did.

• We asked sellers how they accepted price recommendations. For example: “Do you know at what price are other sellers selling this product?” This made them think holistically instead of considering just the Action tab.
• On the ‘Compare Price’ screen, we wanted to check if sellers were able to fully comprehend the impact of accepting our recommendations. Since we made them comfortable at the outset with a nice, relaxed conversation, they were able to share their points of view without the fear of being judged. We learned that they wanted more context, such as ratings and other parameters for competition, before accepting price recommendations.

Based on our learnings, we bolstered the design with improved messaging and visual elements that highlighted the magnitude of missed opportunity.

Some key updates we did in the redesign:

• We highlighted ‘Losing Orders’ pill in red to create a sense of urgency. Since the number of orders is the primary motivation of sellers, this gives them a clear idea as to what they could gain from pricing their products right.
• We added ‘ratings’ and ‘losing orders’ pill along with a ‘trending up’ icon to highlight numbers in the price comparison modal , after the user clicks on ‘Compare Price’ CTA.

🤷🏻‍♀️ Old Design

🤩 New Design

Our UTs gave us tremendous insights on how we can make the screen more insightful and actionable for sellers. The final product gave impressive results.

• Users were able to spot the ‘Action’ column and comprehend the information easily. They didn’t have to go back to the Meesho app or website to compare prices, which was the behaviour earlier.
• Apart from product parameters, they were also able to see and compare ratings and number of orders, which really contextualised the information for them.

🕵🏻‍♀️ Conducting an effective usability test

• Robust UT requires the respondent to be comfortable and feel at home. A good conversation starter I use is: What was your last purchase from Meesho? In the case of sellers, it could be: When was the last time you used our seller dashboard?
• Keep it simple. Instead of confusing users with tech jargon, use visual cues such as the colour of the mic/arrow for screen sharing, or its positioning relative to a known icon. I sometimes share my own screen to explain how they can mute/unmute.
• While explaining the agenda of the call, one common mistake is to start with statements like: “We are going to show something “new/interesting/exciting”. This creates a bias at the very outset, and users would sub-consciously start looking for differences.

🙅🏻‍♀️ Eliminating biases

Ideally, you should let the respondent guide you through the overall journey and share their views. You should nudge them whenever required to enunciate their thoughts.

However, such sessions — where the respondent leads the conversation — are a rarity and most interviews require you to be in the driver’s seat.

Here’s how you should lead the test:

• Ask open-ended questions so that users can freely talk about their experience. Give them room to express themselves and space to voice out their opinions.
• Make sure to control your reactions, especially when receiving negative feedback about your product or work. Users might stop sharing honest feedback if they sense you are getting defensive.
• Instead of asking leading questions, give your users a task to perform. I prefer this approach while doing an A/B test for screens — it clearly points out which version works better.
• In scenarios where the user asks “Should I click here?”, resist the temptation of saying “Yes”. Instead, ask them: “What do you think would happen if you click here? Where would you click if you want to perform ’X’ action?”

Usability testing is an evolving process. While each conversation will have its own set of challenges and speed bumps, it will eventually give you valuable experience and lessons that will come in handy in the future. Trust the process.

🎉 Shoutouts

Special thanks to Rahul Srivastava for helping me shape this blog into an informative piece

Also, a big shoutout to Rahul Prakash for the design cover of this blog

Usability Testing 101: How We Tap User Insights to Refine Our Products was originally published in Meesho Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

60-second takeaway

• Did you know? Meesho ships upwards of 3 million orders a day, but we do not own warehousing or logistics. This helps us ensure that our sellers get the most cost-efficient online selling experience.
• For any e-commerce platform, logistics is a huge expense. But at Meesho, we worked our way around them by tying up with specialised e-commerce logistics players across India
• Our asset-light business model allows us to leverage our logistics partners’ cutting-edge transportation solutions, thereby improving our scalability, flexibility and customer satisfaction.
• Our tech-first approach further optimises our logistics partners’ core competencies and by extension our own business model. For example, using API integration to help the seamless interaction of our respective networks, and developed systems to optimise their legacy machines.
• With our users displaying a strong value orientation, our efficiency-over-urgency approach to logistics helps bring down costs on both the seller and the user side.

Third-party (3PL) logistics players in India handle 1.8 billion shipments annually.

Can you get what percentage of that Meesho accounts for?

~50%.

That makes us the single-largest contributor to India’s fast-growing 3PL ecosystem. We ship upwards of 3 million orders a day, but we do not invest in in-house warehousing or logistics.

Why?

To ensure that our sellers have the most cost-efficient e-commerce experience. Building warehousing infrastructure and running a captive logistics workforce drives up expenses significantly in the supply chain, ultimately translating into higher costs for fulfilment as well as products. In fact, this choice of outsourcing logistics is a key lever in establishing our industry-first 0 commission model.

Why reinvent the wheel when specialised 3PL companies with deep capabilities cover the length and breadth of the country?

So far Indian e-commerce platforms in India have only been able to achieve an average capacity utilisation of 60% with in-house logistics. Plus, logistics — a combination of first-mile, middle-mile, and last-mile costs — is a huge expense.

Our decision to work with 3PL players across India, including Delhivery, Ecom Express, Xpressbees, Shadowfax, has led to increased supply chain efficiencies across the ecosystem, resulting in higher truckload utilisation, more fuel saved per tonne, far less carbon emissions, and a significant decline in the average cost per shipment.

Meanwhile, thanks to the sheer volume of orders placed by Meesho users, we not only receive favourable pricing opportunities with 3PL players, but we are also able to realise supply chain efficiencies, enjoy best-in-class delivery times and service quality.

As veteran brands in the logistics space, these 3PL players have developed deep last-mile networks from the customers’ perspective and first-mile nodes from the sellers’ perspective. Plus, they have cracked the code of logistics not just in tier-I cities, but also in tier-II, tier-III cities, and notably in remote regions such as Northeast India. This translates to our sellers having access to all serviceable pin codes across the country, with the agency to run their online business in remote markets at lowest possible costs.

Essentially, our asset-light business model, allows us to leverage their cutting-edge transportation solutions, thereby improving our scalability, flexibility, and customer satisfaction. Here’s how our tech-first approach further optimises our logistics partners’ core competencies and enables our sellers to get better pricing and services:

Integrating our tech with that of 3PLs

Our tech in the backend works as a translator that scans all the nodes within a 3PL partner’s network and pushes out relevant information about pickup and delivery into their demo pools. Meanwhile, our “Dynamic Allocation Engine” allows us to analyse and ensure that every shipment is processed by the 3PL partner that can offer the best cost and service quality.

Extending our tech efficiencies to improve utilisation at 3PL partners

In a recent example, we made the functioning of sorters — a device that is used in logistics to identify products and divert them into specific destinations as per requirement — cost-efficient. The typical run time of a sorter is 8 to 10 hours, which means this machine is on standby for more than 12 hours every day… which translates to loss of money. We developed a system to increase the runtime of the machine to 14–16 hours, which has made things more efficient and spread out the load for the machine.

Data science to reduce RTOs

RTOs come at a big cost in the ecosystem; think forward and reverse logistics, probability of damage, repackaging, stuck inventory, etc. We work very closely with 3PL companies to reduce these costs. For instance, our SaaS technology has in large part resolved a big issue in tier-II and tier-III cities, where pipal ke ped ke peeche and atta chakki se left are common address markers.

Further, we built a very strong prediction model based on hundreds of user and supplier attributes to identify frivolous orders and returns.

Our priority is always to help our sellers succeed (by saving their money). Given the choice between creating artificial urgency to deliver faster — which drives us supply chain costs — and ensuring maximum vehicle utilisation for each delivery, we always choose the latter.

We wholeheartedly follow a user-first approach, and our users value cost efficiency over all else. Our 0% seller commission and favourable logistics rates offered by 3PL players, makes us the lowest cost channel for small businesses. Our recent achievement — India’s fastest e-commerce company to amass 1.1 million sellers — is premised on innovations like these, where we challenged longstanding beliefs and didn’t force-fit solutions created for other markets.

There you have it: Meesho’s method of saving big bucks for suppliers by adopting out-of-the-box solutions and using a tech-first approach.

CREDITS

Cover Image: Rahul Prakash

Sources: Venkush Khede, Utkarsh Garg

How We Reimagined the Supply Chain to Reduce Logistics Costs for Our Sellers was originally published in Meesho Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

My first engineering project was building a water filtration system.

We had studied and taken apart an RO filter to figure out how it worked and created our own filtration device. We made a series of chambers, each performing some form of purification.

The filter cartridge removed dirt and mud before pushing the water into the next cartridge, where finer particles were filtered out. The water then moved into the chemi-block chamber and then into the RO membrane, where dissolved chemicals and microorganisms, bacteria, etc were removed respectively. The final chamber segregated the clean and rejected water and out came clean sparkling H2O.

It’s been a while since that experiment and now I am again taking apart and analysing a contraption, one that filters out ‘defects’, but at a quantum level.

In this blog, I will tear down the set-up and workings of Meesho’s internal security system and see how simple tweaks create big effects. But first…

Why do need a security scanner in the first place?

When we push a string of code into production there might be:

1. Vulnerable and risky code being pushed into production.
2. Hard-coded secrets, which are often stored in plain text and are easily extractable from the source code.
3. Vulnerabilities arising from the use of dependencies from open sources.

Building a strong security funnel that vets and scans for any vulnerabilities at the source is one way of ensuring that vulnerable code isn’t going out. Now, with the basics established, let’s move on to making a solid security system.

Let’s start building!

Here’s a fact: developers outnumber security engineers by a long margin, and the sheer influx of codes on a daily basis is so big that manual review is technically impossible. So, we needed a solution that was effective, quick and, most importantly, automated.

To this end, we built a security scanner that is triggered into action by GitHub webhooks. The scanner analyses the code for defects and compiles a list of found defects which is delivered via a dashboard.

The flagged code are reworked and sent back into the scanner for vetting and, if cleared, passed into production.

Now, our engineers generate thousands of lines of code each day. This also means that we deal with a slew of diverse vulnerabilities and defects that may arise from different engineering teams, and thus our security scanner must enclose different kind of tools to deal with for all kinds of defects.

After much deliberation, we zeroed in on three tools:

1. Semgrep for Static Application Security Testing (SAST).
2. Dependabot for scanning the code for dependency issues.
3. Trufflehog, an open source tool, that scans source code repositories for Hardcoded secrets and keys.

While we followed standard installation and execution procedure for Trufflehog and Dependabot, we tweaked our SAST tool for improved results. But before we talk about tweaking the SAST tool, let’s understand SAST.

What is SAST?

SAST is a method of scanning source code at rest and flagging vulnerabilities. The other way to scan for security threats is by using DAST — Dynamic Application Security Testing — where the code is analysed for security vulnerabilities while it’s running. More on this in the upcoming blogs.

Now, every company has its own set of internal library, coding guidelines, etc., and also their own set of unique vulnerabilities. Likewise, we too had our set of novel vulnerabilities and threats that needed to be flagged.

Semgrep allowed us to customize its ‘Rule Engine’ to include vulnerabilities that we wanted to weed out. But before we move into customization of the Rule Engine, let’s know the Rule Engine better.

What is a Rule Engine?

The Rule Engine is the brain of a SAST tool. SAST tools, Semgrep in our case, analyses codes based on the rules defined. These rules are basically instructions on how to treat the incoming code (which code to flag, which to let through). This analysis occurs in the Rule Engine.

Most SAST tools come with an inbuilt set of rules called presets. Once the presets are activated, they will actively scan and weed out vulnerable code and submit a list of defects on the dashboard.

For example, a Rule Engine may have OWASP top 10 vulnerabilities defined in the preset, and thus the SAST tool will readily identify and flag those vulnerabilities.

Now, finally, SAST tool customization.

SAST tool customization

Semgrep allows customizations that help companies create their rules based on previously identified issues via manual code review. So, we developed and embedded our own rule configuration into the process.

Our Rule configuration file is basically an extension of our SAST tool which allows us to prioritize queries, customise Rules efficiently, and have a stronger control over the tool.

This is how our security scanner works

Step 1. Triggering Mechanism: We use github webhooks to trigger the the scans. The webhooks is configured to trigger on every Pull Request made on the develop and master branch. The webhook contains all the information about the reponame, branch, commit etc. These details are then used to clone the repo and initiate the scan.

Step 2. Cloning and Scanning: We parse the response from webhook for repo details and initiate the scans. We used Semgrep and truffleHog for detecting source code vulnerabilities and hardcoded secrets, respectively. We pull dependence vulnerabilities found by Depenabot.

Step 3. Uploading to Dashboard: All the scan results are uploaded in their respective engagements, which are mapped with reponame.

Step 4. Posting Scan report on Pull Request Comments: All the scan-related summary is then shared in the comment section of the respective Pull Request, which notifies the owner and the developer.

The outcome

Our customizations gave extremely efficient outcomes:

1. The system triggers every time a branch is getting merged with the development branch or the master branch.
2. We have curated each security rule of the scanner to keep the noise low and only report high-impact and relevant security issues.
3. Commenting on Pull Request (PR) brings clear visibility about the scan and provides easy navigation to the dashboard with an overview of the scan results.
4. Rescan can easily be triggered with the link sent in the Pull Request (PR) comment.
5. Was used in mitigating the Log4j and spring4shell vulnerabilities.

Our automated security system was successfully able to weed out security defects and also offered very handy solutions to monitor and analyse codes going out of the system.

This automation and monitoring gave a lot of breathing space to our security engineers, who are a handful compared to the hundreds of developers pushing out tons of code each day.

Finally, I would like to thanks Rakesh and Siddarth for leading this project and taking the time of their schedule to talk to me about this project.

Also, a giant hug and high-five to Rahul who squeezed out time for this cover image. Rahul, you are a graphic rockstar.

Also, folks, if you like what we do and want to be a part of Meesho, please head over to our careers page and check for relevant openings.

Until next time.

We Improved & Automated our Security Systems with a Smart Tweak. Here’s How was originally published in Meesho Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

60-second takeaway:

1. A big section of our sellers are new to ecommerce. This is why it becomes imperative to create systems and dashboards that are intuitive and easy to navigate. The more intuitive and navigational the dashboard, the easier it is for the sellers to administer their business.
2. However, as we introduced newer features to the dashboard, it created a long list of action items and made the dashboard a bit tedious to use.
3. To solve this problem, the team analysed and demarcated features based on some guiding principles and revamped the icon-designs to make the whole experience simple and the dashboard — navigational.
4. This blog details how the guiding principles were developed and what went into creating recognizable and relatable iconography, and the subsequent impact this exercise created.

A tea stall about 4 blocks from my house went from serving only 2 items (tea & buns) to offering a whole breakfast menu in a few years. The erstwhile menu, a simple cardboard, is now a laminated A4 sheet with all the items categorised under “Quick Bites”, “Eggs on a roll”, “Refreshing beverages”, and “Shakes on the go”.

While categorising the menu sounds like a business-as-usual activity, there are finer variations and subtle nuances that help restaurants deliver value and convenience to customers.

A customer can easily recognise their category of interest and place their order instead of having to scan the entire menu.

In summary: a well categorised and demarcated menu makes the customer’s life easier.

And this, as uncanny as it may sound, is closely related to a recent upgrade we made in our seller dashboard. Isn’t it interesting how businesses seemingly miles apart are connected through a common thread of offering convenience?

The Challenges

Here’s how our old seller dashboard looked like:

And here are the two challenges it brought:

1. Lengthy menu list: An undemarcated and lengthy menu list meant that the seller had to move sequentially through it, until they found the action item they needed. This was a tedious activity and would become more cumbersome as more items got added.
2. Unrelatable icons: The icons representing the action item weren’t exactly hitting the nail on its head. Some icons were not easily relatable to the action item they accompanied.

While these seem like straightforward problems at first, much deliberation and analysis is required to reach the best solution. Here’s how we went about it.

Formation of Logical Groups

The first response to the problem was simple: group the action items. Having said that, it’s important to group these items logically — and then decide which group should be placed at the top, which group should take the next segment, and so on.

For example, if a frequently used segment was placed below a less frequently used segment, the purpose of group creation would be defeated. Sellers would have to sequentially move through the list to reach their frequently used action item.

To group action items together, we needed to develop guidelines that helped us identify their utility.

We devised 3 buckets to group action items:

1. Business operations: These items focused on suppliers’ daily business management and administration tools. Items under this bucket included frequently used and time-sensitive actions such as inventory management, payments, returns, etc.
2. Business growth: These items help sellers grow and have material business impact. These included items like pricing recommendations, ads creation, product recommendations, etc.
3. Analytics: These tools provide insights into business health and performance. These items included Quality Dashboard and Business Insights.

This is the rough pictorial representation of the buckets:

Once the buckets were created by logical grouping, we moved on to identifying relatable nomenclature:

1. Business operations bucket was tagged as “Manage business”
2. Business growth cohort was tagged as “Boost sales”
3. Analytics cohort was tagged as “Performance”

Now, we moved on to identifying the position of these cohorts on the seller dashboard.

Prioritising and Positioning

Identifying the right rank in a menu list is crucial as an intuitive dashboard is key to good seller experience. We retained the top segment of the old dashboard as ‘Support’ and ‘Notice’ are commonly sought after features, and thus should be available up top.

The next slot was retained by ‘Home’ as this is the default launch screen and should be accessible easily. Coupled with the earlier discussed buckets, here’s how the new dashboard looked like:

But there was one final challenge that needed to be addressed: visual comprehension.

Making the iconography more relatable and memorable.

Decoding the Visuals

Making the visuals more relatable and recognisable was the second challenge we wanted to solve. The first step was to get a fix on whether we should upgrade the existing lined icons, or overhaul our approach and create new graphical icons. To answer this question, we carried out surveys asking sellers which icon and icon type they preferred.

Here’s a sample from the questionnaire:

Through the tests, we found that coloured icons had higher recognition and relatability. The results of the tests, as shown below, clearly concluded that the relatability of coloured icons was significantly higher than that of lined icons.

With this learning, we revamped the iconography on the menu list. Here’s the new design and its comparison with the older version:

The Moment of Truth

Now, it was time for the acid test: the user testing phase where we would release the upgraded dashboard to a pool of sellers to gauge its effectiveness. The feedback:

1. All titles on the menu list were well comprehended and set the right context.
2. Out of suppliers who noticed the new designs, more than 60% identified the Order image icon and more than 50% identified the Promotions icon correctly
3. More than 70% suppliers noticed the new sidebar navigation design.

The Impact

Quantitative:

• Single and bulk catalogue uploads have improved by 20%
• Inventory stock update has improved by 21%

Qualitative:

• Click-to-action rates have improved significantly in the new navigation, leading to the following results:
• From the survey results, we saw that ~79% suppliers were aware of the new design.
• The average rating for the new navigation is 4.2, a significant improvement.
• We also asked sellers to identify images for the Orders and Promotions pages. The average recall value for the Orders page was more than 65%.

We were able to achieve significant results by implementing a few design changes and, quite like the bustling tea stall near my house, offered a great deal of convenience to our customers.

This blog is credited to the brilliant folks who worked on this project, especially Heli Fajalia, Mohit Manaktala, and Rahul Srivastava.

A special shoutout to Heli for her proactive participation in getting this blog up and running quickly.

Also, a huge high-five to Rahul Prakash for the awesome cover image.

How Our Tactical Design Tweaks Created A Massive Impact for Sellers was originally published in Meesho Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

60-second takeaway

• As champions of small sellers, we often collaborate and partner with state governments and Self-Help Groups (SHGs) to identify women sellers from poor economic backgrounds in rural pockets and handhold them into the world of e-commerce.
• There are many challenges we combat on this mission, including a lack of awareness around e-commerce and poor digital infrastructure.
• For example, many rural women sellers are either unaware of or hesitant to get GST registration; there is a misunderstanding that GST = cash loss. And since businesses cannot sell online without GST, we have been helping different state governments onboard the sellers under their respective National Rural Livelihood Missions (NRLM).
• While onboarding sellers from rural pockets with little to no experience with e-commerce, it is also important to train them to sell successfully on the Meesho platform.
• On the success of our efforts, Sanjeevini — Karnataka State Rural Livelihood Promotion Society (KSRLPS) opines, “(The tie-up) not only helped provide good prices for women artisans’ products and access to a larger market base but also a new identity for their entrepreneurship development.”
• We’re hoping to see similar success in J&K and Telangana, where we are headed with our offline training sessions next.

“Growth is never by mere chance; it is a result of forces working together.” — JC Penney

Small sellers are at the centre of everything we do at Meesho. COVID-19 taught us that these small sellers are more vulnerable to economic shocks if they remain exclusively offline. As India’s only true e-commerce marketplace, we want to be at the forefront of aiding their transition into the online world.

And while our own efforts have helped many first-time e-commerce sellers become successful online, tying up with state governments and leveraging the reach of NRLM has helped us scale our endeavour in various rural pockets.

From weavers to potters and bamboo workers, women sellers with no prior knowledge of e-commerce can sell online through public-private partnerships like ours. For example, more than 50,000 poor and underprivileged women have started micro and small enterprises through Karnataka State Rural Livelihood Mission’s (KSRLM) — Sanjeevini. Meesho’s goal is to help digitise their businesses scattered across districts such as Kolar, Mysore, Tumkur, Hassan and Uttara Kannada in the state.

To this end, we signed a Memorandum of Understanding (MOU) with the Karnataka government in July 2022. Next, we needed to eliminate the obstacles in their way and further train them to sell online successfully.

The GST challenge

Last June, the central government announced that mandatory GST registration would be waived for small online sellers (with turnover under INR 40 lakh). However, with the implementation now scheduled for October 2023, all online sellers would be required to obtain a GSTN — at least until then.

As you would expect, most women who are part of these SHGs do not have GST registration, and nor are they keen to get registered. The reasons:

• Most small sellers are still unaware of why GST is required, and there isn’t enough education about it.
• GST is often required to be filed monthly, quarterly or yearly, and small entrepreneurs do not see the merit in doing this activity multiple times a year.
• The uninitiated assume that GST is very costly and cannot be recovered by simply adjusting the amount to the prices of their products.
• The SHGs are made up of women, most of whom are not financially literate and are intimidated by taxes and paperwork.

Educating a cohort of sellers who are potentially already nervous about making that transition from brick-and-mortar to online isn’t a good idea, so we came up with a solution: Create a common GST account and initiate multiple sellers onto the Meesho platform through the Karnataka government’s brand Sanjeevini. Once they get used to selling on Meesho and get used to the idea of GST, they are encouraged to register for GST for their business.

Sanjeevini — KSRLPS was happy to cooperate with the arrangement. This move “provided good prices for women artisans’ products and access to a larger market base along with a new identity for their entrepreneurship development. The partnership has also increased the economic activity available to and the financial security of rural women business owners. Above all, Sanjeevini-KSRLPS and Meesho are also able to support these families in upholding their traditions and culture to preserve their legacy.”

This initiative has helped onboard women artisans who have been creating handmade tribal jewellery, sarees, home decor and Lavancha handicrafts traditionally as online sellers, helping them sustain these art forms in India.

We replicated this strategy with the Association of Lady Entrepreneurs of India (ALEAP), an organisation under the Telangana government. During our training session in Telangana, we learnt that only seven among the 38 sellers present had registered GST, and most of the remaining sellers had a preconceived notion that GST = incurring a loss. The most viable solution is to get an umbrella GST with ALEAP for all the sellers.

The training

Once the GST challenge was solved, we started our offline training sessions. An expert Meeshoite with a good grasp of the local language typically trains cohorts of 40–50 women sellers, covering everything: What does Meesho do? How to upload a product catalogue? What are the different components of pricing? How to run ads? How to participate in sales? What are the benefits of “Meesho Recommended Prices?” etc. They are also trained to set themselves apart from their competitors and avoid penalties. They are even told about the benefits of opting for our Next Day Delivery (NDD) programme.

The most positive outcome of these sessions has been learning how excited these sellers are about exploring the brand-new avenue of e-commerce. From their pertinent questions about making the right investments and growing their businesses, it’s evident that they’re on the right track.

“I belong to a community of bamboo makers, and we sell most of our products locally. Since joining Meesho, we have visibility among a much wider range of customers who love our traditionally made products. The very first range of products we uploaded on Meesho were all sold out in just a couple of months. We are enjoying our new-found success and want to encourage other traditional artisans like ourselves to grow. By speaking about Meesho at village melas, we have already enabled five small sellers to join Meesho.” — Ashwini, Bamboo artist from Davanagere district of Karnataka.

Meanwhile, many more state governments are keen to join our digital revolution, starting with Jammu & Kashmir. We hope that these partnerships between Meesho and the state governments will be a game-changer in the long run as we continue building India’s only true e-commerce marketplace.

CREDITS

Design: Rahul Prakash

Supported by: Prachi Bhuchar, Vijay Chauhan

Digital Revolution 2.0: Transforming Rural Women Into Online Entrepreneurs was originally published in Meesho Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

60-second takeaway:

1. Problem statement: 8% of our first-time users dropped off without exploring beyond the homepage. We needed to convert these users into explorative users and, subsequently, transacting users.
2. Through user testing and user calling, we identified that these users were not able to narrow down their discovery and ended up scrolling endlessly. Some were oblivious of the different product portfolios and catalogues available on Meesho.

We devised approaches to capture the user’s intent using Homescreen Widget and helped them reach their desired product.

1. We deployed these approaches through intuitive, uncluttered and communicative designs.
2. Impact:

• An additional ~1.6% users placed their first order within the first 9 days of installing the app
• An additional ~1.74% users placed their second order within 30 days of installing the app.

There are two situations you face while shopping online:

1. You know exactly what you want to order (high intent, low cognitive load).
2. You are looking for options and aren’t sure what your next purchase would be (low intent, high cognitive load).

While the first situation is ideal, the second scenario brings with it uncertainty due to a long tail of choices available on e-commerce platforms. This uncertainty compounds when you are a first-time user exploring an app.

A user is prone to drop off when their first interaction is not familiar, or if they don’t understand the navigational scheme of the app. To solve this, the home page layout, category demarcation and navigation become critical.

And since a significant number of our users are new-to-ecommerce, making the app intuitive from the get-go becomes necessary.

This article details out how we solved this problem at Meesho.

The Problem Statement

About 8% of our first-time shoppers were leaving the app without exploring beyond the home page. The challenge was to turn these users into explorative users, thereby increasing the chances that they will make a purchase. And the only way of doing this was to make Meesho’s homepage easy to navigate, intuitive, and uncluttered.

The Research
We had two questions to answer:

1. How do we pinpoint what the user is looking for?
2. How do we take the user to the right product in the category they have shown interest in?

The first question has two methods of approach:

1. Either explicitly ask the user about their product preference (what they are looking for, what their price range is, what their preference is, etc.)
2. Use implicit methods to detect their product preference (signals that the user exhibits while using our app or outside behaviour like gender, order history, ads, etc.)

Given that we are solving for first-time users, the second approach is ruled out as previous user history is a prerequisite for drawing up user preference. So we moved with the first approach.

Capturing the intent of new users via the explicit method is further bifurcated into two parts:

1. While onboarding
2. Via the home page

Here are the pros and cons of each method:

In the face-off, intent capture through the home page widget came out on top!

Now that we’ve answered the first basic question: “How do we pin-point what the user is looking for?”we move onto the next question. How do we take the user to the right product in the category they have shown interest in?

From quantitative signals obtained from our backend, we know 70% of our new users place an order from the first catalogue they explore. And 40% of new users in our qualitative testing exhibited difficulty in narrowing down their discovery to relevant products.

We deliberated on a few approaches to guide the user in their journey. For instance:

• Personalisation of discovery feed and homepage widgets
• Usage of implicit signals (gender, language preference, etc.)

Following multiple brainstorming sessions, we converged upon a guided discovery construct. Here, once the user expresses the intent, we shall open a focused category page with the ability to switch among categories through tabs.

We explored different layouts, leveraging different forms of visual and text communication:

After assessing which design satisfies the criterion of capturing intent through home page widgets and helps pinpoint user intent, we narrowed in on the final design:

Where the Winning Variant had an Edge

For the second session, the landing experience was the last product catalogue page that the user had clicked, as opposed to the homepage.

For example, say a user clicks the electronics tile in the first session, browses and drops off. When he or she returns, the app directly opens the electronics category page. This redirection experience yielded higher conversions.

The Flow

Whenever a new user installs Meesho, the first thing they are required to do is to choose a language. After that, the user lands on the homepage, where all the eyeballs go straight to our brand new EXPLICIT INTENT CAPTURE WIDGET.

Should the user choose any of the catalogues they are guided to a curated listing of that particular catalogue.

Design Interaction

The design has two states:

1. If the user hasn’t clicked any tile (of the intent widget) during the initial stages, we clearly show the widgets upfront following the app install.
2. But once the user has clicked a tab or placed the first order, we use a morph transition from widget → tabs to educate the user of the paradigm, which is also the steady state design as shown in this link

The Impact

1. Adoption for the explicit intent widget was ~30%+ overall.
2. An additional ~1.6% users placed their first order within the first 9 days of installing the app
3. An additional ~1.74% users placed their second order within 30 days of installing the app.

While these numbers continue to mature, we are working consistently towards creating more intuitive and interactive homepage layouts to handhold first-time users in their e-commerce journey. Stay tuned!

Special Thanks! 👏🏻

A great feature cannot be made without some spectacular product thinkers like Kanad Dagaonkar, Surmai Somya and Narayan Tendulkar. And also a gorgeous functional design cannot be made without maestros like Atul Kaushal, Varun Nagpal, Sanira Mediratta, Kopai Banerjee, Pranav Mishal and Himanshu Arora. Super-thanks to all the co-contributors.

Also, big cheers to Usman Zafar for helping put this blog together.

How We Reduced Drop-off on our Homepage and Helped First-Time Users Explore the App Better was originally published in Meesho Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

60-second takeaway

• Online sellers spend ~16 minutes on average uploading a product catalogue, mostly because of a lengthy and tedious form that needs to be filled.
• So we set out to develop a simple cataloguing process that required minimal time, effort and knowledge.
• We used data science and machine learning algorithms to provide autofill options, contextual nudges, aided recalls, micro-interactions and relevant recommendations while a seller uploads the catalogue.
• Consequentially, the number of inputs required from sellers came down by 50%.
• Results:
  75% sellers have seen a dramatic drop in upload times
  63% suppliers are able to list more due to the time reduction
  Most sellers are able to complete their catalogue uploads independently.

Did you know online sellers spend 16.3 minutes on average uploading a single product catalogue? And if they’re new to e-commerce, like many of our sellers are, add a few extra minutes.

That’s valuable time that a small business owner could invest in ideating new strategies, managing finances and inventory, or building ambitious business plans.

With just 2–3 million out of India’s ~63 million registered SMEs currently online, such hurdles to their digital adoption must be removed. In our efforts to bring the smallest of businesses online, we decided to…

Make the cataloguing process so simple and intuitive that the time, effort and knowledge required by suppliers to create a good quality catalogue is minimal.

Light but Long

When we started, uploading a catalogue would require selecting the relevant category and then uploading an image of the product. This would be followed by filling up a form with the entire taxonomy, including the product’s colour, size, and material.

Alternatively, sellers could download a spreadsheet, fill out all the relevant information, and bulk upload multiple catalogues. These catalogues would then go to the Taxonomy tagging agents, who would review each upload and run quality checks.

While this was still lighter than most e-commerce apps, there was scope for improvement. This is how our catalogue upload screen looked before the update:

A few things are immediately evident. This long-established catalogue uploading mental model:

• is tedious, information-heavy, and has a complex structure
• has multiple tasks on each page
• requires the uploader to pay close attention throughout the process

Big businesses with bandwidth and manpower have dedicated teams to meet the uploading requirements of online platforms. Our sellers, mostly MSMEs (Micro, Small and Medium Enterprises), do not have that luxury and end up spending their limited time and resources on catalogue uploads. The process seemed long, complex and potentially confusing for them.

Convenient Cataloguing

We started identifying and systematically removing bottlenecks to build the simplest and smoothest-running catalogue that India’s e-commerce sellers have ever used.

• We decided to do away with restrictive rules, cut down on the number of questions and keep the system agile for all supplier cohorts.
• We introduced a mix of data science and machine learning algorithms on the platform to autofill certain product attributes based on the image the sellers provided.
• We also added some contextual and discoverable nudges to assist sellers while filling out initial details, along with added recalls, micro-interactions and relevant recommendations.

Here’s how the catalogue upload form looks like now:

On average, 52% of the upload form comes pre-filled, while recommendations are generated for ~75% of the catalogue inflow.

As a result, three in four suppliers have seen a dramatic drop in upload times, while 63% are able to list more on account of the faster process. More importantly, most of our suppliers are able to successfully complete their catalogue uploads independently — in the true spirit of Atmanirbhar Bharat.

But we’re not done just yet. We feel catalogue uploads should be…

#JustLikeSocialMedia

The idea is simple — can uploading a catalogue become as easy as posting on social media?
(1) Upload product image
(2) Write product name and description
(3) Add price
… And you’re live.

Watch this space to find out!

CREDITS

Design: Gopal Panda, Rahul Prakash

Subject matter experts: Kaustubh Fule, Nihal Singh, Heli Fajalia

Catalogue Uploading Just Got Dramatically Easy for Meesho Sellers. Here’s How We Did It! was originally published in Meesho Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

As modern tech teams lean more and more into automation, Platform Engineering (PE) has emerged as one of the most promising developments in this space. But what exactly is Platform Engineering? Why does it matter, and how do we use PE principles at Meesho to improve our engineering output?

Our Principal Architect, Indroneel Das, walks us through PE concepts and what it means for Meesho and other cloud-native organisations. We hope this conversation will answer all these questions and many more.

Can you briefly explain what issues engineering teams faced that led to the conception and eventual rise of Platform Engineering?

Indroneel: Engineers focus on creating and shipping code for specific business requirements. This is fine during the initial stages of a company’s growth, as requirements change rapidly, necessitating a lot of experimentation.

However, as engineering teams converge to an established business model requiring only incremental changes, their focus should change to, “How can we efficiently, reliably, and securely meet business demands?” But that usually doesn’t happen.

This is where PE comes in.

Let’s consider teams facing challenges around scale, reliability, availability, and security while trying to ship code quickly. Left to themselves, each team would solve these issues in their own way, leading to knowledge silos. Failing to leverage knowledge and experience leads to the development of duplicate and/or overlapping capabilities.

Having good PE practices solves most of these issues.

Let’s talk about the journey from development to production. Can you give some scenarios of how PE helps tackle such situations?

The journey benefits from having the right processes, tools, automation, and security practices for different stages and operations within the overall development life cycle. Here, the role of platform engineering is to augment and support these processes and tools. For example:

1. Having observability as a platform capability across all services helps identify root causes during end-to-end and integration testing.
2. Well-defined reliability features lead to better recommendations around issues identified through performance testing.

Additionally, PE can reduce development time and effort by introducing technical abstractions. For example, an event-driven architecture between services is usually implemented by each team using Kafka as the underlying technology. This has several constraints that lead to more development time:

1. Each team must have the proficiency to integrate, debug, and tune Kafka for the best outcomes.
2. Each team must separately build capabilities around monitoring, configuration, data validation, and interoperability for the eventing pipeline.
3. Each team is responsible for the availability of their respective Kafka cluster. This also applies to upgrading and/or migrating to an alternative technology when required.

Having an eventing capability that exposes a set of strategies around event generation, propagation, and consumption improves developer bandwidth across engineering teams.

You touched upon knowledge silos. How does PE help avoid those?

First off, let’s understand knowledge silos in some depth.

Knowledge silos develop when engineering teams build capabilities and develop skills in isolation. These capabilities are usually contextualised to address a single business problem, which results in duplicate capabilities when solving similar problems. Duplicate capabilities mean more collective development efforts to improve and maintain all of them. Sometimes, knowledge propagation as shared capabilities does happen when driven by senior engineers, though it’s a very organic process and tends to be suboptimal.

With a central PE team and a stated vision, the following happens:

1. Duplicate capabilities are identified across teams and rolled into single, shared offerings.
2. Feature-driven capabilities (e.g., notifications, indexing, ranking, and relevance) are implemented in an extensible and configurable way to evolve rapidly with changing product requirements.

According to you, what are the tenets of building an effective PE team, and how have we applied them at Meesho?

Here are some of the tenets that a PE team must have:

1. A clear mission: I’ve observed that every organisation has different views of what constitutes a platform in its context. Therefore, it’s essential to have a clear answer to the question, “what does a platform mean to us?” for the entire organisation.
2. Product mindset: The team should think of the platform as a product with engineers and product owners as end-users. This requires everyone on the team to revisit soft traits such as empathy, strong communication, the ability to receive and act upon feedback, and continuous learning.
3. Generalise and create abstractions: The team also needs to pivot from a feature-driven mindset that targets the organisation’s end users to provide capabilities that help build and operationalise those features. One way to achieve this is to think in terms of abstractions.
4. Identify differentiators: For every platform feature conceived, there should be a stated motivation and consensus on the expected benefits. These benefits should translate into a dollar-value benefit for the business.
5. Scope: It’s also important to understand what isn’t the responsibility of a platform team. While the purpose is to serve the application developers, it’s not an extension of Site Reliability Engineering (SRE) or operations.

It seems like PE has a lot of positives for most engineering teams. Few organisations have adopted its principles. Why do you think that is? What might be the barriers to its adoption?

I’d say it depends on the organisation. In older, established companies, there’s often a lot of legacy infrastructure. In many cases, entire portions of the system are not even in the cloud — they’re hosted on-premise. Existing rules and bureaucracy also make it difficult to drive large-scale change. These are short-term downsides that inhibit progress.

Meanwhile, for young companies, the focus is on short-term gains as they might still be working on an MVP and proving their business model, while PE’s benefits are mostly medium- and long-term. Therefore, it’s hard to justify spending effort on something whose benefits are only apparent after the company has grown beyond a certain point.

Another issue inherent to PE is that of rewards and recognition — since the team is supposed to be the “invisible glue”, it’s difficult to get recognised for your efforts. On the other hand, it’s immediately noticeable when things go wrong, increasing resistance to contributing.

Finally, PE is seen as a cost centre because the team doesn’t ship new features or solve the so-called “concrete” business problems, making it difficult to convince the top brass to invest in it.

On the cost-centre front, do you have any recommendations to convince the organisation to invest in it?

While there are indeed costs associated with building a PE team, there are many less obvious and intangible benefits that more than offset these costs. Firstly, embracing PE from the beginning allows teams to stay lean because there are fewer personnel required for infra management.

Since developers spend less time and effort put into infra management, they can focus on adding and improving features, solving business problems, and reducing time to market. As there’s also a focus on observability and repeatability, it reduces the chances of downtime caused by incorrect deployments.

There are also savings related to cloud infrastructure costs. Since the infra allocation is automated, there are less “wasted” and unused cloud resources that would otherwise be billed.

Meesho has grown by leaps and bounds in the past few years. Has PE improved our ability to scale?

Definitely. As Meesho has grown at an incredible pace, our PE initiatives have supported that growth while remaining cost-effective. We call our current efforts the 3 A’s: Adoption, Abstraction, and Automation.

Adoption: We are continuously evaluating new technologies and service providers to help us manage them. A change in our deployment strategy from VMs to containers, and spreading out across multiple cloud providers would be good examples of our ability to adapt fast. From a cost perspective, we are also getting close to finding the sweet spot between managed and self-hosted services.

Abstraction: Fast adoption comes with the inherent risk of unreliability due to the changes introduced. This is why we are in the process of finalising our abstractions over common building blocks such as storage, caching, and eventing. These abstractions help us stay true to certain standards while giving a certain level of autonomy to try out newer stuff and incorporate the changes with localised change impact.

Automation: This is a continuous process where we systematically identify and replace manual operations with processes that are repeatable, configurable, observable, and therefore efficient. For example, our deployment pipelines are fully automated. We are also rolling out tooling for environment provision and test execution during performance engineering and quality assurance. All of these have a direct influence on developer productivity in the near term.

Indroneel Das has over 25 years of experience designing and developing large enterprise solutions and web-scale applications. For over 10 years of this journey, he has served as a principal architect across multiple industry domains such as online retailing, e-governance, and IT services.

If you found this conversation insightful, well good news, because we have more of them coming! To make sure you don’t miss out, follow us on LinkedIn, Twitter, and Instagram!

Credits

Interviewee: Indroneel Das

Interviewer: Shivam Raj

Creatives 🧑🏻‍🎨Ved Sarkar (Portfolio, Linkedin)

A Deep Dive Into Platform Engineering with Indroneel Das was originally published in Meesho Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Meesho has done something few have dared to try — cater to the massive, but untapped, demographic of buyers and sellers from tier II, III + towns. We have over 6 lakh small and macro sellers on our platform. Plus, over 50% of our sellers are new to e-commerce.

Understandably, there is no playbook on how to cater for this demographic. So, we are writing one. How? Through User Research (UR).

Joining Meesho’s UR team this year was my first foray into the field. And these past few months have been nothing short of enlightening. In this blog, I have collated some of the biggest learnings.

What does Meesho’s User Research team do?

UR is a horizontal function spread across all business verticals and contributes at different stages of the product development life cycle. We co-own the problem discovery and definition along with the product teams. At the solutioning stage, we give input on both — product as well as design solutioning and then gauge the effectiveness of the designs through evaluative research.

We’re also involved in cross-org strategic projects which require an in-depth user point of view. This makes UR well-integrated into the product teams, binding it to the proposition of never losing sight of our users! Our team prioritises depth-focused research based on execution, scope relevance and potential business/product impact.

In a nutshell, we provide insights that help product, design and business teams understand the users’ mental models We also identify opportunities and challenges that need to be surfaced for the product from long-term perspectives.

A unique challenge — Solving for Bharat

When I joined Meesho’s UR team, I was most excited by the opportunity to solve for Bharat users across rural and semi-urban regions in India. Starting a journey with a new organisation always comes with mixed feelings of nervousness and excitement.

I come from a service industry background — a field where you work with different clients and projects, but never really get to see the impact you create. I already had an understanding of evaluative research from a cognitive lens, but never got exposed to such in-depth generative research work.

Now being in a product environment, I’m fully immersed in the product and can see my efforts making a difference.

How?

1. Company mantras are aligned to UR goals: Our mantras like “User First” emphasise on understanding our users. And so, there’s never a need to prove the value of research. Besides, our “Problem First” mantra helps align all stakeholders to focus on the problem rather than just engage in validation-driven research.
2. We believe in complete ownership: At Meesho, your designation is not tied to the kind of opportunities you get. “Act Like An Owner” at Meesho is not just a mantra, but is also a practice of owning collaboration with different stakeholders. We “Act Like An Owner” while being the voice of the users and at the same time collaborate closely with product, business and design stakeholders through “pod” ways of working. This helps us contribute to different steps of the product-development lifecycle and have a say in the decision-making process.
3. Accelerated growth path for every researcher: Being part of a research team where you get to interact with researchers across levels, helps you learn from their diverse experiences and backgrounds. As a team, we share knowledge about different research methods, skills, tools and also to know our users more deeply through learnings across projects.
4. Mature research practices: Because we cater to all of Bharat’s users, coming from different backgrounds and levels of exposure, there’s a unique complexity which has been a great learning curve for me so far. Also, communicating and influencing stakeholders as well as generating insights that are actionable have also been contributing factors to my learning curve at Meesho! It’s because of our mature research practices that we’re able to cater to a large demographic with actionable insights.
5. Our research is depth-focused: Before joining Meesho, I had only heard of depth-focused research. But here, I got the chance to experience this! “Depth” in the research context has different meanings in different organisations. At Meesho, there are two parts to this.

First, we go deep into problems, not just from a psychological lens, but also from a sociological and anthropological lens. For example, the way people use an app may not be because of the app itself but because of their offline experiences. Second, when an insight surfaces, there are four levels of “why”s to get to the underlying reasons of the problem.

Being a part of the UR team at Meesho inspires me every day!

I believe that satisfaction at work comes when you really enjoy what you’re doing. For me, solving for Bharat users is not just the responsibility of one individual — or even of one team — but a company-level effort. The focus here for me is to be the best qualitative researcher in the industry.

Seeing my managers align and motivate me towards my career goal, is what makes me more enthusiastic about the kind of work I want to deliver. Apart from focusing on execution, I have also realised the importance of influencing stakeholders to integrate insights into their product-business roadmap.

The kind of support, context-building and exposure I got introduced to over the course of my initial days has helped transform my nervousness into motivation. Within this short span of time, I am confident to lead UR projects in specific product charters!

To know more about how we do what we do, head to meesho.io!

Credits

Guidance 💡

Achyutha Sharma (LinkedIn)

Editing 📝

Hadley D’Souza (LinkedIn)

Creatives 🧑🏻‍🎨

Ved Sarkar (Portfolio, Linkedin)

A Budding Researcher’s Journey Understanding Meesho’s Unique User Base was originally published in Meesho Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.