Shelf Life – My Process Behind Designing The User Experience.

Purpose For Starting a New Project

Hello! In this post I want to go over a new application idea that I have been building out for the past few days. I’m writing this mainly to document my thought process and initial ideas, but if this series of posts can help teach other people something as well, it’d be a huge plus!

It started out as a goal. I wanted to build an app using React Native in around one month. So, I knew the idea had to be simple and useful but had some flexibility for expansion later.

The initial idea that came to mind was an application where you could take a picture of your fridge, and it would catalog everything you had so you wouldn’t need to even go up to your fridge to see what is in the house to eat. After some research, I quickly realized that with my current level of knowledge of machine learning and image processing, that this would be an unrealistic goal.

“So, along the same thread, what is something that I could realistically pull off in a month?” was the first question I asked. After some more research, I found that barcodes can be scanned and used to get the expiration date, weight, and more. There is also a public database with a documented RESTful API called “Open Food Facts” that I could use for more information.

The core idea started to form. And I came up with the name Shelf Life. I could use the product name found in a barcode and search the Open Food Facts API by name to get expiration dates if they aren’t stored in the barcode. There is one problem though.

The Initial Problem

I’ve used journaling apps before, they usually stem from a burst of motivation to do a specific thing, like fitness, or mood trackers. But by the time that motivation wears off it just becomes an extra step to whatever process you were trying to complete initially. I knew Shelf Life needed to be different, it needed to either take steps out of a process, or it needed to give the user a reason to work through an extra step to get something in return.

I started to brainstorm some ideas for how I could use the data we have. We have products that the user has scanned in their home, their expiration date (and whatever else Open Food Facts offers). One of my ideas was to create a recipe system that would keep track of items you have in your “pantry” and let you know what you need to buy. This, however, brought up a big problem that needed to be solved.

Let’s say you have a recipe for a peanut butter and jelly sandwich. This recipe has three components, the bread, the peanut butter, and the jelly. When you scan a jar of “Jif Peanut Butter” you will get just that in your pantry, Jif Peanut Butter. There is no reliable way to tell what the product is using its brand or product name. Dr. Pepper doesn’t have “soda” in the name for example.

I did some digging with the data I had, and the Open Food Facts API also uses “category tags” that various users can contribute to at any time after review. This is a step in the right direction! When I have a recipe, the app can just check if my pantry has any item with the “peanut butter” category.

There is still a minor hiccup: Because Open Food Facts is built based on user contribution and moderator review, there may not be a “peanut butter” or “jelly” category, or the product may not exist or may not have one of those categories.

The way I plan to solve this is to create my own reference database that will store the product name, and a custom category that users on the Shelf Life app can set for themselves. This custom category table can’t be accessible to everyone that uses the app though, someone could say a watermelon is in the mustard category if they wanted to.

My solution to this is to create an encompassing object called households. This achieves a couple of things: for one, it allows multiple users to keep the same pantry in sync. And secondly, it solves the former problem by limiting custom category scope to a household. This way if a user decides to mess up their own data, it doesn’t affect anyone else.

Making The Tedious Worthwhile

Okay, so we have a cool idea that makes the scanning worth it for people who want a recipe book too. I can also make recipes sharable among households. That increases the social aspect of the app. What else can I do that would be useful to a more general user-base?

I decided on adding a “grocery list” feature. At first glance it seems like yet another journaling aspect to the app which only adds more steps to a process, but this isn’t the case.

When a product in your pantry expires or is close to expiring, Shelf Life will prompt you to add that product to your household grocery list. This will create a one tap step to add common products that you buy all of the time to your grocery list, right on your phone. Now the user doesn’t have to write down milk and eggs yet again and waste time and paper.

Still, the barcode scanning every single item the user buys is tedious and a lot of work. I had to slim down this process. My idea to do this, is to be able to scan a receipt for items that were on your list and mark them off. This has some major obstacles.

  1. Different stores write their receipts differently and use abbreviations to keep ink usage down. For example, Targets name brand “Good & Gather” is abbreviated to “GG”.
  2. Expiration dates aren’t stored on (most) receipts. So the main benefit of using the grocery list is unable to be used if you’re scanning the receipt.

My solution for problem one is to learn about Machine Learning and create a receipt parser with receipts from all kinds of stores as training data. This would be a massive undertaking, and not necessary to releasing Shelf Life. But it is a big feature I want to implement after the month deadline of release. I have wanted to learn about Machine learning for a while now, so it’s a win/win.

Problem two’s solution is simple in comparison. I would estimate the expiration date based on the previous barcode scanned pantry entry and notify the user that the newly receipt scanned product is estimated, and if they want an accurate date they need to scan the barcode.

Okay, now the grocery list feature has some meat to it (no pun intended). It integrates very nicely with the pantry and recipe systems. What else can I do with this?

I had the idea to add a location tracking system, so if you’re in a grocery store and your household has products that are expired or will expire, the app will alert you and prompt you to purchase the needed items. This will save the user from getting home and realizing they forgot eggs for the third time this week.

Conclusion

I think that the recipe, household, grocery list, and pantry system make the process of scanning items much more worthwhile.

All-in-all, I am very excited to work on this project and release it. As you’ve read, the (probably overly ambitious) goal is to release Shelf Life in around a month. I usually have trouble finishing the numerous projects I start, and I want this to be the one that I get out the door.

To ensure that I meet this deadline, I need to define a minimum viable product and keep the features slimmed down. However the roadmap for future features can be subject to change.

The minimal viable product will be compromised of the following features:

  1. Barcode scanning
  2. Pantry (What items you have in your household)
    1. Expiration Dates
    2. Categories
    3. Alerts based on expiration dates
    1. Grocery List
    2. Households
    3. Recipes
      1. Recipes need to be sharable to other households.
    4. Accounts

    The roadmap for bigger features after the initial release will consist of:

    1. An AI receipt parser.
    2. Possible AI image recognition to scan a group of products at once.
    3. Location services to alert users of items to purchase in a nearby store.

    In a future post, I will go over the architecture, tech stack, and my process behind designing the app in a robust and scalable manner.

    Thank you for reading, I look forward to writing more posts about Shelf Life!