About Me

 

I look at problems from a technology, business and social point of view. My career has shaped accordingly.

My undergraduate degree in computer science is the foundation of my education. While still being a sophomore, I started building The Testament. I was instrumental in establishing a technology division at my startup thereby steering it from a small ops based business to a scalable tech startup. I contributed to multiple products in different ways – from being a full stack developer to a product manager. By virtue of being one of the founding members, I also contributed to various aspects of business like marketing, operations, and recruitment.

Carrying forward the immense learning from the startup experience, I am pursuing my master’s in information management and systems from UC Berkeley. At the School of information, I have found a perfect home to enhance my technical skills in the business and social context.

I am looking forward to working as a product manager at a company that solves problems on a large scale. I would prefer to work on multi-sided platforms, where the focus is on driving interaction and maximizing value for stakeholders. I am excited by the fact that such companies essentially create opportunities for people, a mission that also drove me at my startup.

 

Design Manifesto: From My Lens

Coming from a startup background where resources are generally scarce and focus is on building solutions, I cannot but emphasize the value of following the design process. When I was building products for my startup, it was often the case that I would directly jump into building products without doing the needfinding. I remember an instance where I had a cool idea in mind and then tried to tie it back to a need instead of the other way round. Furthermore, as entrepreneurs, we would often fall in love with our solutions and almost forget the user’s perspective. While I always tried to be empathetic about users and advocate for them, it was difficult to do so without following a structured approach to design. Perhaps caring for users is not enough unless you actually talk to them. If you do not talk to your users, you end up relying on intuition and assumptions which can be false. I believe that user empathy coupled with the ability to properly execute the design process is key to designing any system. I do believe that every stage of the design process is important however I also think that it is important to understand the purpose of each of the stages and not just focus on the tools and frameworks involved in the process. In the projects I worked on, I would usually focus on satisfying the purpose of each of the stages and allow myself some degree of flexibility in the methodology. Following are the key points about the design process:

  • Needfinding: I would focus on discovering the underlying need by following the five why’s technique. I would usually try to identify the underlying feeling and emotion attached to a particular idea. This was best served by evoking stories from people. For instance, In my grocery shopping in an unfamiliar environment project, one of my interviewees said that the most important thing in the store are the employees. I used this information to prototype a solution that made shopping collaborative because the underlying need in this case was human assistance while shopping. Furthermore, through the interviews I did for my projects, I observed that following the needfinding interview script does not always work. It happened with me a couple of times that the most insightful information I got was at the end of the interview when we were casually talking about the problem space. To conclude, the most important thing, in my opinion, is not to jump into the solution space during the needfinding phase.
  • Flaring and focusing: Once we figured out the needs and empathy maps, flaring was very useful. It prevented me from narrowing down on just one idea and falling in love with it. I believe the continuous cycles of flaring and focusing are extremely useful to prevent idea fixation.
  • Prototyping: Following the fail fast and fail often methodology was extremely helpful in the context of prototyping. One of the lessons that I learned was that it is almost always beneficial to talk to your users very early on in the prototyping phase. Instead of designing high fidelity prototypes and then realizing the false assumptions made about users, it was helpful to ask for user feedback and then iterate accordingly.
  • User Testing: During the user testing phase, especially in my final project, I was surprised to see the number of assumptions we had made about users and at times it was very tempting to prompt the user and justify the design decisions we made. However, I believe the key to successful usability testing is to observe, record and then analyze. It is also of utmost importance to avoid your confirmation bias to creep in during this entire process.

STIR: Experimenting with Cooking

Project Background

Stir is an iteration on a project one of my teammates did for his class project. It was discovered that there was an unmet need for people who cook and want to make dishes with ingredients they already have as well as the ability to experiment with cooking. As part of the final project in our Intro to HCI class, we decided to drill down on this need and focus on people who experiment with cooking as our target audience.


Needfinding

We interviewed 4 users during the needfinding phase each of whom were people who have been cooking for a while and like experimenting with it.

Some of the key questions we asked during the interview were:

  • What ingredients do you have in your kitchen? What influences how you use them?
  • What do you usually do if you don’t have the ingredients mentioned in the recipe?
  • Do you tend to experiment with the recipes you use? Why/why not? What influences the changes you make?
  • Tell me about the last time you successfully experimented with a recipe. Why do you think it went well?
  • Tell me about the last time you unsuccessfully experimented with a recipe. Why do you think it didn’t succeed?

The following empathy map is representative of the responses we got from the users:

Empathy map for one user

Based on the four interviews and empathy maps we came up with the following user needs :

  • User needs to be able to find recipes with ingredients that are available to him/her
  • User needs to be able to look for alternatives for missing ingredients
  • User needs to be able to discover new recipes with familiar ingredients quickly

Design Question

How might we give users new ideas on how to use the ingredients they are familiar with?


Prototyping

Low fidelity prototypes

We came up with the following low fidelity prototypes:

 

 

High Fidelity Prototypes

Having designed the low fidelity prototypes we felt that the second prototype best addressed the design question so we came up with the high fidelity version for it. The prototype mainly had the following features:

  • User interest selection in terms of ingredients and recipes they like
  • Recipe feed based on user interests
  • Filters to search for recipes with specified ingredients
  • Displaying variations/experimentation done by others on the recipes

We had four variations of our high fidelity prototypes each having the features mentioned above. Each variation differed in the design of one feature. Each variation catered to a specific question regarding the design of one of the features. Following are the variations of the prototypes :

“Interests selection progress variation”

Which is the more intuitive way to show progress when the user is selecting interests

As shown above, the user needed to select at least four interests to move forward. One of the prototypes indicated progress by greying out the continue button and when the user selected at least four the continue button got activated. The other prototype indicated progress through a progress bar.

“Feed variation”

How do we best display recipes to the users

These prototypes differed on the basis of how recipes are displayed to the user. In the first prototype, the recipes in the feed only had a name and an image, and the user could click on it to see the detailed recipe on the next screen. In the second prototype, the detailed instructions of the recipe were present in the feed itself. The second prototype was designed keeping in mind that the target users were familiar with cooking so they might just want to skim through recipes and the second prototype would enable them to do that faster.

“Ingredients filter variation”

What is the best way to filter recipes with the given ingredients?

In this variation, the two prototypes differed based on how the user could add ingredients to filter recipes based on those ingredients. Since this was one of the primary needs of the user, it was safe to assume that users would use this feature frequently. When users have a lot of ingredients, adding all of them frequently is a tedious task so we wanted to design the feature in a way that addition is seamless. One of the prototypes allowed the user to add ingredients based on the categories in which they lie and the other one allowed them to look for ingredients alphabetically.

“Experiments/modifications variation”

How do we best display recipe modifications to users

The app showed modifications/experimentation done by other people on the recipes so that it was easier for users to discover new recipes they were looking for. There were two ways we thought we could capture this information. As shown above, one of them was to show a subjective text written by the person who did the modification and the other was to objectively show what has been added and what has been removed.


Usability Testing

Since we had different variations of the same prototype, each team member conducted usability tests on two users: one user was shown the base prototype and the other user was shown a variation of it. Each one of us then compared the results of the two tests. As the variations were based on different parts of the whole prototype, the intention was that we would be able to get good feedback on all features of the application as well as its general flow. Furthermore, we conducted the tests keeping in mind the questions mentioned above for each variation. We gave each participant the following tasks but focused our follow up questions on specific features of the application:

  1. Select four interests
  2. Browse through the recipes and then apply a filter to get recipes containing eggs
  3. Assuming that you have the following ingredients:
    • Eggs
    • Sugar
    • Butter
    • Baking powder
    • Cocoa powder
    • Flour
      • Find a brownie recipe you can make with these ingredients
  4. Now assuming that you don’t have eggs, check if there is a way to make brownie without eggs.
Results
“Interests selection progress variation”
  • One of the users said “food is a lot about eating with your eyes” so users preferred images for interests instead of text.
  • The meaning of the word ‘interests” was unclear.
  • One of the users did not like the search functionality on the interests page because that slows down the process and should be in the main feed instead of being at the start.
  • The flow of the progress bar was not smooth. It should have had more stages to actually make the user go through four steps.
“Feed variation”
  • Recipe on the image approach made it easier for users to quickly scroll through recipes. However, if such an approach is adopted, we should make it more clear that the image is clickable to get more details.
  • One of the users noted that the recipes should be organized by categories like it is done for products in e-commerce apps rather than just a flat feed.
“Ingredients filter variation”
  • For adding ingredients to filter recipes, the approach of showing ingredients alphabetically was more intuitive as compared to showing them by categories
  • It was difficult for users to decipher the category of ingredients through icons
  • The whole flow for this feature was confusing for users because they felt that once they added ingredients there should be a way to apply filter and see results instead of navigating back. Users were skeptical of the fact that they would lose changes if they go back. Interestingly, one of the users felt the flow should be more like the checkout flow in e-commerce sites.
  • The icon for this feature was counterintuitive because users felt it was searching instead of filtering
“Experiments/modifications variation”
  • The objective way of showing modifications was preferred over the subjective way
  • “Cooking is all about getting the quantities right” exclaimed one user in the context that the modifications should also show the quantity of the ingredient which has been modified.
  • One of the users also preferred  having modifications displayed both subjectively and objectively
  • Another user noted that since the app focuses on experimentation the modifications should be shown in the recipe detail screen itself rather than going to another screen
  • The way the modifications were displayed objectively was confusing for one user because he felt they were tabs and not modifications themselves.

Lessons

We observed that people liked the idea a lot and found the concept to be very relatable. However, through the course of the study, we learned that some of the assumptions we made about our design proved to be false. Some of the features were not very intuitive for users. The fact that people drew parallels with existing apps indicates that we could have made use of some of the design patterns which exist to make our application more user-friendly. Furthermore, we felt that the usage of text and images is not interchangeable in this design space. There were areas like interests where users felt strongly about the presence of images whereas when it came to choosing ingredients from categories, users preferred text for categories. In places like the feed, the images were so powerful that perhaps they may be the reason why a user would prefer one recipe over the other. Another important aspect of this design space was the lingo used in the application. Terms like “interests” were confusing for the users. Some users indicated that they would prefer terms like dishes or cuisines over interests. Also, in our app we did not make a clear distinction between ingredients and recipes because we wanted to give users the flexibility to filters things by both but it was observed from the interviews that it was confusing for users at times. To conclude, I would say despite these challenges it is a very exciting space to work in and there is a lot one can do to delight the users.

 


 

Other Projects

Needfinding: Public Transportation

Design for understanding: Grocery shopping in an unfamiliar environment

Design for friction: Digital wellbeing