Doorknock, a neighborhood marketplace on your fingertips

Doorknock, a neighborhood marketplace on your fingertips

Doorknock, a neighborhood marketplace on your fingertips

A story of how a 5 member team built an E-commerce product from scratch in a 500 sq. ft. house and successfully failed

View the prototype on Figma →


In mid-2017, we (5 member team) built an e-commerce platform for traditional brick-and-mortar stores to go online since most of the purchases happened at retailers compared to the online consumer market which is dominated by players like Amazon, Flipkart, Swiggy, and Zomato.

I was the founding designer and was responsible right from naming the product and crafting the experience for multiple platforms like Web, Android, and iOS for the consumers, merchants, and delivery executives.

Problem statement

  • There was no single marketplace for discovery and delivery of products across traditional stores in a neighborhood across multiple categories - Food, Groceries, Vegetables, Fruits, Sea Food, Meat, Sweets, and Snacks.
  • In India, not everyone is tech-savvy and more consumers are getting online every single minute. It's hard for them to understand apps and how tech works. Not everyone gets it. We had to cater to multiple age groups. Mobile and web aren't the only medium where people place orders. In order to get a day-to-day products on the same day, consumers tend to order by calling their neighbourhood stores which they're familiar with.
  • Lack of on-demand delivery infrastructure for retailers to deliver their orders which they received via phone call/in-person.


  • Build an efficient neighborhood marketplace for brick-and-mortar stores to enhance the discovery of products for the consumer with on-demand delivery infrastructure.
  • Leverage our existing in-house POS system which was primarily distributed to restaurants and start selling to big retailers and build a Mobile POS for the smaller brick-and-mortar stores. Every time a customer makes an order via Doorknock, the POS system receives the order details.
  • Craft the experience of Mobile POS in such a way that it can handle on-demand delivery requests.
  • Build an initial MVP to check the product-market fit and understand the initial feedback by cold calling the customers.

Building out the MVP

We had a clearly defined goal - build an MVP in 4 months by scaling to multiple neighborhoods within Chennai and get feedback from our customers. The launch was first commenced with the web platform followed by Android and iOS considering the number of users using Android vs iOS

Highlights - 2 months post-launch -



  • We didn't have images of the consumables across a wide range of categories in our database thereby requiring us to capture images.
  • No sight of a restaurant menu in our database as well since we had to collect all these manually.
  • Since we wanted to target the brick and mortar stores, we need images of the stores people would easily connect with. We didn't have those too but had an internal app that let the sales/delivery executives take images of the stores.
  • We couldn't do user research since everything was fast-paced and needed to put the product out to market to get real-time feedback from our users.
  • We hadn't onboarded our merchant partners so making them live on our app required the groundwork that needs to be performed.

Designing mobile experiences - Consumer, Merchant, and Delivery

1. Consumer mobile experience -

In India, consumers typically use Android and it contributes close to 95% compared to iOS 3%. However, we decided from day one, that, we focus on consumers from all platforms, be it Web, Android and iOS, since as a company, we wanted to cater to age groups from all backgrounds.

While designing, we wanted to keep the experience consistent across Android and iOS. In these examples below, I'll be showcasing a couple of our flows -


  • We wanted to keep onboarding as simple as possible for the end-user since our goal was to enter the app without friction and view the stores near them
  • Since we were targeting a large base of users, we weren't really sure how many may / may not allow location permissions. If there were users who didn't allow the permission, we prompted them to identify their location or choose from a set of pre-defined locations since we were only available at 6 locations to start off.

Things that we could've done better -

  • We could've prompted the location access contextually.
  • The value proposition of the app could be better displayed via a carousel of images
  • Instead of hardcoding the locations, we could've instead notified them when we were available at their location. Moreover, it would've helped us to easily identify which location has more demand

Initial Touchpoints


  • We experimented with search placement, marketing carousels, illustration vs real images for categories. Each of the variations has its own pros and cons.
  • In the first example where we have a distinct banner for marketing campaigns, we posted deals for all products or it was categorical i.e. offers on baking products, fruits, etc. And as obvious as it sounds, those were the days we had maximum orders for those particular categories ~55 orders PER day which was insanely high for our delivery partners to manage.
  • We didn't give much emphasis on the search bar in the first example since we wanted to focus more on how the carousel performed.
  • In the second example, we wanted the search to take the centre stage and we had more people using the search to find out the items they want and finish the flow.
  • We used real images of items as much as possible since it's relatable for the end-users. Since we were catering to a wide range of users, using illustrations/icons won't be recognizable.

Displaying type of stores vs name of stores


  • We experimented with 2 kinds of flows and found that out

Example 1 - In this behavior, we showcased the stories upon clicking on the category rather than the products.

Example 2 - We displayed one of the nearest shops by category as the first card and upon swiping they would be displayed the next nearest shop.

After looking at our data and making a couple of cold calls,

  • In the first example, people expected grocery items to be listed upon clicking on "Groceries" and vegetables to be displayed upon clicking the "Vegetables" category.

  • In the second example, apart from restaurants, people didn't care which shop they purchased vegetables, fruits, seafood from since they are the same across all Kirana stores.

Search experience


Search in an E-commerce product is rudimentary as it helps the users to easily find what they're looking for. Since our web experience was shipped first, we had data that pointed out that,

  • Restaurants category was the least ordered compared to vegetables, fruits, and other household items since people were already accustomed to other leading brands like Zomato, Swiggy.
  • We identified a couple of items people generally ordered and reduced their friction of typing by providing them upfront when there were zero queries. The zero query search results were an aggregate of frequent orders and trending items for the day in multiple categories.
  • While typing, we wanted the suggestions to help accelerate the process of search thereby reducing the effort needed to type a lot.



  • When designing an e-commerce solution that encompasses everything right from restaurants, groceries, baking, vegetables, fruits, meat, and more, it's essential that there's a single place wherein categories and their respective sub-categories are displayed so that it's easier to discover all the items.
  • We arranged the sub-categories according to the hierarchy the user expects so that it's easier to drill down what they prefer.

For eg - Indian, Chinese, Italian cuisines fall under the hierarchy of restaurants since we're categorizing them based on cuisines.



  • We gave prominence to stores as a tab and listed the nearby stores for the user across all categories. That was our value proposition - find your neighborhood stores and shop from there but our users told us a different story.
  • "Stores" was not much used since people cared more about the products and not where it's from unless it's a restaurant.
  • Since the restaurant was least searched due to competitors, we could've removed it as a carousel category while navigating.

Profile page & cart checkout


  • During the mid-2017, most of the companies used referral-based systems for their customer acquisition and we hopped on a similar bandwagon. Though we burnt cash, we still acquired a couple of customers through this channel.
  • We couldn't let our customers store details of debit/credit cards since we need to be PCI-DSS compliant which we weren't ready to shell out. Instead, we let users pay via a payment gateway.
  • Just like other similar apps, we let the users track and view their orders.

Once we had everything figured out, it's time we created the app store screenshots and took it live to get our initial feedback.

App Store screens, Play Store screenshots, and a couple of reviews from customers


2. Retail app experience -

For the retail experience, we partnered with stores in and around the neighborhood, be it a small store or a supermart.

  • The retailers had to process the orders placed by the customers via mobile/web.
  • Retailers can receive orders via offline/online medium so we had to cater to both types of users thereby enabling the online/offline orders with last-mile delivery flexibility.
  • For smaller stores without inventory management, we gave them the flexibility to add/manage stocks. By doing this, we can efficiently track whether a particular store has stock available or not on Doorknock.
  • Apart from the above, we also let them view the payments from each order except offline.

Actions that can be performed by the retail manager


In the home section, we're distinctly mentioning the actions that can be performed by the retail executive/manager.

  • The retail manager can request a pickup if they need to serve offline orders.
  • The second section lets you view the orders placed by customers via web/mobile apps.
  • Manage products lets you manage your store's stock/inventory.

Viewing orders and filtering them

  • Since stores keep receiving orders, we made sure they can handle the scale of orders.
  • Restaurants can have offline/online orders and we have a dedicated tab menu to distinguish between online or a store order. Since we've integrated restaurants with a POS system, the "Store" section would consist of offline orders only. For stores without POS, only online orders will be displayed by default.

Order details page

  • We've made the app super convenient for retail managers/executives to easily manage the lifecycle of orders until order pickup.
  • The retail folks have the ability to call up the customers in case any particular order isn't available or modify the order as per the customer's requirements.
  • The chances of an order getting canceled are considerably less so we've placed order cancellation in the overflow menu.

Managing products in the inventory

  • Since we've enabled the local stores with mobile POS capabilities, it's easier for them to add and manage products in their inventory. However, after conversing with them in field, we found out that, the retailers hardly update the inventory since there's a flood of offline orders.
  • Moreover, they're accustomed to managing stocks the old way. i.e. jotting down stock inflow and outflow via pen and paper

3. Doorknock delivery experience

At Doorknock, we had ~8 delivery executives serving 6 locations within Chennai and while interviewing the delivery executives who have used other e-commerce products for quite a while, I happen to understand how they operate on a daily basis.

The goal was to keep it simple while being intelligent at the same time.

Intelligent how? -

  • We displayed the order pickup screen as soon as the delivery executive was within a 50m radius of the pickup location.
  • In addition to #1, we displayed the order delivery confirmation as soon as the delivery executive was within a 50m radius of the delivery location.

Actions possible from the menu


  • The delivery executives received mostly 1 order at any point in time or a maximum of 2 orders to pick up if the pickup locations are nearby.
  • Declining the orders would result in automatically reassigning to the next available delivery executive.
  • Apart from these actions, we wanted to be as transparent as possible by revealing their payments which get updated on a daily basis.

Navigation - Pick up experience


  • Once an order has been accepted, picking up the order would be the next task. Moving from point A to point B should be seamless therefore, options like turn-by-turn navigation (via Google Maps), Info of the order, and the ability to quickly call up the store were right upfront.
  • Unless the delivery executive is within ~50m of the pickup location, they can't confirm the pickup.
  • If the executive encountered any logistical challenges, they could either contact support or cancel the pickup via the overflow menu.

Navigation - Delivery experience


  • We wanted the delivery experience to be consistent with the pickup experience.
  • Some of the controls like calling up the customer have been kept upfront instead of the store since that's what matters to the delivery executive during delivery.

When I was tasked to work on Doorknock, I didn't think twice to say "Yes" despite the fact that I was having hardly 1 year of experience and was asked to work with a small team of members in a 500 sq. ft. house. I'm glad I shipped an MVP for all apps - Web, Mobile - Consumer, Retail, Delivery.