What’s Cooking? (Part 3) – Meal Planner Redesign

Ah the dreaded meal planner feature.  One of the last features to get implemented, however it’s the first thing I use to explain what’s so cool about KitchenPC.  You give it a bunch of ingredients, you tell it how many dishes you want to make, and it spits back an optimal solution ensuring not a single shred of cabbage or ear of corn or slice of bread goes to waste.  Tossing so much spoiled food in the garbage is one of the whole reasons I built the site.  However, so far users don’t seem to agree.  Only 80 people in the last 3 months (0.5% of my visitors) have successfully generated a meal plan.  Even more depressing, 350 people (2.1% of visitors) have  even gone to the Meal Planner page on the site, meaning the meal planner has nearly an 87% bounce rate.  87% of people who are curious about the meal planner give up and leave before clicking the “Submit” button.

I remember the all-nighters I pulled to write this code.  Countless hours in ANTZ Profiler optimizing every instruction and tracking down every little bottleneck.  I wrote my own hash table because the .NET one simply wasn’t fast enough for me.  It’s the single most heavily engineered feature on the site from a computer science point of view, but a complete and utter market failure.

Yet, I’ve demo’ed this feature several times to a live audience and the reaction is, without a doubt, overwhelmingly positive.  Many claim they will immediately start using the site because of this.  When I explain the feature to someone who’s never seen the site, they can’t wait to try it out themselves; or they have a friend or family member who needs to hear about it.  This gives me hope that there is a real problem to solve here, and I refuse to give up on this feature quite yet.  These potential users, who have never used the site, are excited because they have manifested a vision of what they think the feature is like, in their head.  They’re excited about that vision, and there’s a disconnect between this and the actual behavior of the site.  This is what needs to be fixed, and I have a few ideas on how.

Let’s first walk through the current meal planner implementation.  First, the name “Meal Planner” is not a great name.  The whole site is a meal planner, so already this feature is undiscoverable (duh, 2% of my users find it) and should be called, perhaps, “What Can I Make?” or something.  However, making various features more visible is a topic for another day.  When we get to the page, we see an ugly form with a bunch of text and radio buttons and other such complications.  The user is first presented with a choice; they can use items from their pantry, or enter a list of a ingredients they have available.  Below that, they’re asked how many recipes they want to find, and are then able to limit these recipes by tag.  Below is a radio button sliding scale, which allows the user to find recipes that will use their ingredients most efficiently, or trend towards recipes the site thinks they’ll like.  When all this mess is filled out, users hit the “Go!” button to see the results.  Only 13% of users who have gone to this page in the last 90 days have clicked the “Go!” button.

So why does this page suck so incredibly bad?

First, no one has a clue as to what it does.  The user is hassled to provide information before an unknown result is given.  They look at “what ingredients do you have?” and instantly think of the time involved typing in dozens of ingredients in their fridge or pantry.  In other words, I require people to do work up front before any reward is given.  “Spend time deciphering my UI, and I will give you data that may or may not be useful to you.”  Today’s Internet users are ADD, they’ll leave if something doesn’t look pretty or interesting or make sense in under five seconds.  They want immediate gratification, even if the data is less than valuable.

While thinking about this behavioral trend, I thought of a TV commercial I saw some time ago.  It must have not been very effective, as I can’t remember the name of the company it was for.  However, a young couple were looking for a new car.  They were surrounded by thousands of cars all driving around them.  One of them said, “Well we want a truck.” and all the non-trucks drove off.  Then the other said “A red truck!” and all the non-red trucks drove off.  In the end, there was one vehicle remaining; of course, exactly what they were looking for.  The commercial makes an important point.  Weeding through massive amounts of possibilities must be an iterative approach.  No one wants to spend 20 minutes filling out a big form explaining what kind of car they’re shopping for.

The redesign of the meal planner page will work something like this:  The user goes to the page, and immediately sees 5 recipes.  These recipes will have high ratings and also offer an overlap of common ingredients, re-using a lot of the same ingredients and not requiring too large a number of ingredients in total.  If the user is logged on, it will take advantage of their own personal ratings, likes and dislikes, blacklisted ingredients, and anything they have stored in their pantry.  Either way, the user immediately sees results that make sense to a very common use case and the user has done no work yet!

Now, let’s say the user has 3 tomatoes.  They can enter in “3 tomatoes” in a textbox above (hopefully using the NLP engine!) and press enter, and the results slide around and new recipes slide in (just like the cars driving away from the commercial.)  The results have been re-calculated to take this new data into account.  Next, the user thinks, “but I’m on a diet.”  They select the tags dropdown and select “low-fat” and, once again, the results are re-calculated to take this filter.  Each time new information is given, the results are updated to become more and more perfect.  The data they provide can also be “sticky”, so the same parameters will be used by default next time they login.  In fact, the entire Pantry feature is now practically obsolete because ingredient availability data is persisted by the meal planner, and not by a separate Pantry concept.

So where did I go wrong?  The engineer side of my brain attempted to solve this problem in the typical “computer science” way; grab all the data up front and generate a perfect result immediately and on the first try.  This strategy simply doesn’t work well for a consumer product.  People want immediate results, and if they choose to feed in more data for better results, that’s their option.  Don’t make your users work, especially when the rewards are not clear.

I haven’t yet really nailed down the exact user interface for the above vision, but the point is the process will be iterative and the “Meal Planner” and “Meal Planner Results” page will be combined into a single full-page interface.  Users will still be able to check and uncheck recipes, see the total required ingredients for their selection, and add one or more recipes to the calendar.  I plan on doing some wireframe mockups and perhaps some “faked” prototypes to test on real customers.  Now when they say “Yea that sounds cool!” I can actually show them a real experience and see if they still think it’s cool.

While re-thinking this feature, I’d like to take the opportunity to throw in a more more improvements.  First, I want to make ingredient amounts optional.  If you simply want to enter “carrots” and leave out the amount of carrots you have, the modeler will assume an average quantity of carrots that a typical person might possess.  This data might be averaged from all carrot containing recipes, or perhaps be an intrinsic part of my database.  I’d also like the ability to “Thumbs Down” a single recipe and have it replaced on the fly with a suitable substitute.  The modeling engine can run in a special mode, where all the other recipes are “locked” and an ideal replacement is found for just that recipe.  This change alone will really give users the chance to find tune the results into the perfect meal plan, and leave the page with meals to plan for the whole week, and an optimal set of groceries to buy to make them.

The redesign also poses some technical challenges.  The recipe modeling engine is incredibly CPU intensive, and doesn’t scale well.  A web server can handle hundreds of users on the site, but only a couple running the meal planner at the same time.  It was engineered in a way where I could even setup separate servers to offload just the modeling engine so it doesn’t slow down the rest of the site.  The possibility of running the modeler over and over again each time it gets new data from the user is a bit scary and probably a few breakthroughs will need to happen to support this.  There are some interesting “tricks” I can do though.  For example, the “public” results (initial results for users who are not logged on) do not actually have to be done on the fly; they could in fact be the same for everyone.  I could calculate this set once per day and cache that meal plan in memory.  Perhaps common tag filters or even common ingredients could be pre-calculated as well, and several “typical” result-sets could be stored in the database.  The actual meal modeler wouldn’t run unless a sufficiently atypical query was given.  I also need a way to re-calculate only the portions that have changed.  In other words, only the delta between the old parameters and the new parameters need be generated.  The CPU is probably doing a lot of the same work between a query with “one tomato” and a query with “one tomato and a pound of ham.”  This work should not be repeated if possible.

I think this meal planner redesign, along with really promoting the feature (perhaps with some How To videos or guided feature tutorials) can really make the feature take off.  I’m definitely excited to see what this feature can become once the usability kinks are worked out, since the engineer behind it is truly a work of art.