Foodavinci: Real-Time Ingredient Substitution

Brief

Foodavinci is a startup that focuses on building ingredient substitution recipe web app. Users are able to create a dietary profile that lists his or her food allergies or foods that he or she must avoid, and real-time ingredient substitutions are made while browsing a user-generated recipe database. The team reached 11 people at its peak, with the core team being nine people, including nutritionists and a chef. The entire team worked on this project part-time.

The idea was generated by CEO Christine Newman, due to multiple food allergies running in her family. The web app was created to address the challenges around meal planning for multiple food allergies.

Project Role

My role on the team was Director of User Interface, and my main contributions included the information architecture of the web app, user research, UI asset creation, wireframes, prototype builds, and user testing. This role was held for the duration of my involvement on the project, from 2013 to 2015. I reported directly to Christine Newman, as well as her business partner and COO, Jason Uswak.

Challenge

- The following objective for the Foodavinci web app was already defined upon me joining the project:
- To allow users to make ingredient or food family substitutions in real time for any recipe

Initial Approach

As the problem was already defined at the time of joining the project, the team started off with facilitated brainstorming session, with ideas individually generated by team members before voting on the best ones.
Brainstorming session
Ideas that were generated during our brainstorming session
The brainstorming session generated additional ideas which were also considered as sub-objectives, such as allowing users with special dietary needs (e.g. low-glycemic ingredient substitutions for diabetics) were also included. The team was then tasked with conducting initial surveys to validate if there was interest in such an app.

I interviewed five people within my network, and during our subsequent team meetings, it was discovered that not only was there positive interest, but multiple interviewees have indicated an interest in having a function that lets you use up ingredients in your pantry as well. Taking these into consideration, our main objective expanded to also include:

- Users with special dietary needs, such as restricted diets
- An inverse function that lets users finish or use up certain food ingredients in their pantry

We also interviewed how people look for recipes, and most of our interviewees indicated online recipes as a source as opposed to flipping through a cookbook. As there are a number of food recipe websites such as food blogs and recipe websites such as Food.com, we decided to leverage that as opposed to creating a brand new database of substitution-friendly recipes. We made this decision based on the fact that our core user base of food allergy sufferers tend to decide on a recipe after browsing online, and then make substitutions afterwards as opposed to creating a recipe built around that substitution. One of the ideas suggested was to feed the recipes from other websites through our app, and then real-time substitutions and adjustments to measurements are made. Another was to have users submit their recipes in addition to leveraging recipes off other websites.
Information architecture map of client-side for Foodavinci
With that in mind, two sets of initial wireframes were designed, with one set being intended for clients, or users, and the other set for developers. At the time, we started designing our client side for desktop users as our main target were older users who used mainly desktop machines. The administration of the site was done through the developer side, as our chef and our nutritionist indicated that some recipes would require tweaking to to ensure that substituted ingredient may involve different measurements or adjustments of other ingredients.
User Testing and Research

Once the initial wireframes were completed, we proceeded with an early round of user testing to validate our ideas, which the core team members did. My method of testing was through paper prototypes for portability. I started by giving a scenario to get the user's frame of mind started, and gave specific tasks, asking the test participant to point with their finger where they would click in order to complete the task scenario. I swapped out paper printouts representing different screens in order to facilitate the testing sessions. I also requested users to think out loud, and include any comments or first impressions he or she might have. This allowed me to get an understanding of their reasoning behind their actions.

Once the initial stage of user testing was completed, we came together as a team to run through more iterations of the design. It was then realized that most of our users during this initial stage of user testing were millennials in addition to older users in the baby boomer category, and this resulted in going back and redesigning the app on the smallest screen first. However, we kept the developer side of the site at a desktop resolution as our developers indicated that they didn't need a mobile version of the site.

Additional wireframes for mobile were created, after multiple design sessions on how the desktop features would be translated for mobile devices. Once these wireframes were completed for mobile, we then began our testing, again with paper prototypes.
After a few more iterations of design and user testing, we were able to refine a number of our features, and eventually a high-res version of the wireframe was built, initially with PowerPoint (which the whole team had access and familiarity to), before moving on to Balsamiq (which we abandoned as we wanted a cleaner representation of our app), and then back to paper prototypes. We also played around with trying to build a prototype with a trial version of Omnigraffle, though the trial period ran out before we were able to complete the build.
Project Wrap Up

During the development of our app, Christine and Jason approached mentors and incubators for backing and support of our project. One of the recommendations that was given to our two leaders was to try pitching our app on Dragon's Den. The overall reception from the incubators and Dragon's Den producer was to have a functioning prototype, which would have defined the next stage of our project.

Unfortunately this never came to light as various members of our team underwent various life changes, and the project was discontinued.

Final Thoughts and Lessons Learned

As this was one of my first major projects involving heavy UX research for myself and the team, a number of mistakes were made along the way. One of the biggest mistakes for myself was not doing enough research into our user base, which affected the beginning stages of this project. This affected us notably in how we approached the initial design (for desktop as opposed to designing with the smallest screen in mind first). Had we spent more time researching the user base, we could have avoided wasting time in the first few months.

I would also change how we approached how we determined our interview questions and interview methods. When we first started, our interview questions weren't specific enough. For example, when we were asking for useful features, we didn't do enough facilitation and steering of the session, and this resulted in some wasted time.

For the user testing portion, I wish I could've started with specific task scenarios (which I ended up doing after realizing my mistake). Initially, I would ask users to look for a recipe while keeping in mind that they had to work around an example food allergy. It was too broad of a task for users and as a result, I had to modify my testing scenarios by breaking them down into task-based scenarios (e.g. How would you add a food allergy on this screen?).

I'd also change our approach to building interactive prototypes. We did jump from tool to tool, starting with PowerPoint, then Balsamiq and then Omnigraffle and then back to paper prototypes, which we used for the majority of testing. At the time of this project, a number of prototyping tools were starting to become available and one of the reasons we kept jumping was because we kept thinking that one tool would be more in-demand than others. In retrospect, I'm glad I learned this early on because tools keep changing, and one of the key lessons was the ability to adapt to new tools.