Research, UI Audit, UX Design, Documentation

Bigbasket records up to 20 million orders a month, especially due to the surge that was noticed during the pandemic. It is available on all major platforms — iOS, Android and PWA. As a summer intern at the largest online supermarket in India, I got the opportunity to work on a couple of interesting projects, one of them being setting up a design system from the ground-up.

As one of the biggest players in the grocery-tech space in the country, Bigbasket has a huge catalog of SKUs ranging from F&V to beauty and hygiene. Being quite a dense application, it contains a ton of screens. This in turn resulted in unorganized styles vis-à-vis type, color, iconography etc.
When a designer in the team had to work on a new feature or solve for a newly discovered problem, they had to invest a fair share of their time in order to build out components and screens that were already in the production app. Say, 5 different designers work on 5 different problems — there is a very less chance that all of them have followed a particular spacing guide or a pixel perfect button width. When this kind of situation arises, it results in entropy/disorderliness — right from the design files to the final shipped product.

The process would slightly vary based on the module I was working on, but roughly, it looked like this:

1. Audit
2. Check for Inconsistencies
3. Design
4. Test
5. Document

Before designing a particular component, it was very important for me to understand the user flow completely. I thoroughly studied each and every use-case that was associated with a particular component and took a bunch of screenshots, which would later serve as a source of truth.
By the end of the audit, I made sure that I understood the ins and outs of the component’s need, purpose and how it contributed to the app without missing a single use-case.

Since the user flows were fresh in my head, it was ideal to check for inconsistencies post-auditing. We maintained a separate Hygiene Sheet just to fix and update minute design changes. As I was encountering these minor inconsistencies, I was also given the freedom to suggest improvements for the same. These 2 steps generally went hand-in-hand. But at the same time, it is important to respect and understand the existing design and why it was done a certain way. Putting myself in the shoes of that designer and knowing more about the context resulted in better improvements. For the most part, we were looking to solve these inconsistencies with our design system.

Upon understanding the user flow in detail, it was time to design the components. At this stage of the process, I realized looking at it from a component level (micro) alone might not be enough, but it’s also necessary to be looking at the bigger picture at a macro level. Sure, detailing is key, but the context in which it is presented is equally important too. A few modules that I worked on were Ratings & Reviews, Sticky Bars, Name Tags, Empty States, Chatbot and Tabs.

All components in Melon were made using Auto-Layout. For most components, we leveraged Figma’s component-variant feature which turned out to be very efficient.

Post designing a particular module, it was time to put it to test. Testing is an essential step in this process — this is where the macro aspect of the design comes into picture about how a small component fits into a standard screen with other elements in it. This step is a good time to also check whether:

• All use-cases and edge-cases are covered
• The component is designed for Android and iOS
• Layers and Frames have been aptly named
• Color & type styles and the grid system strictly adhere to the guidelines

Considering a lot of important points are checked off at this stage, testing turns out to be vital indeed. But how did we achieve this? By building screens and designing interactive flows between them.

For example, in the Return and Exchange flow (See Image), by re-designing the complete flow using components from Melon, we were able to test Bottom Sheets, SKUs, Buttons, Text Fields, Icons, Sticky Bars, Cards, Images, Navigation Bars and Widgets! By doing so, we were able to tweak the components a bit here and there so that it doesn’t break under any circumstance, thereby giving it a polished look and making it ready for all use-cases.

One of the main purposes of building Melon was that it could be used by designers, engineers and PMs to bring about consistency and a solid set of design principles and values about BB Design. In order to do so, documenting the design in such a way that all stakeholders involved can look it up and understand the core of the company’s design principles is the way to go. As a designer, this is the part of the process which requires a lot of empathy. At the end of the day, Melon is built to bring about ease and harmony between design and code, and also for people outside the design team to have a glance at it to understand the usage guidelines and Do’s and Don't’s. The documentation for each component and pattern varied slightly, but overall, it delivered the message in a detailed yet concise manner.