This document was structured to have 3 main “flows” and a lil bonus view to encourage using up perishables.
Under the hood, these required separate pages and underlying structures for the database layers.
The interaction layers follow similar patterns of 1) buttons & search, sort, and filter settings at the top, 2) buttons on the main table/cards of the page where valuable, and 3) link buttons to configuration pages either at the top or end of page depending on how frequently the user is to need to visit the config page for a given flow. All pages were designed for either desktop or mobile use in mind, with the exception of
which is mobile-oriented.
For the presentation layer, most pages are meant to be “functional” working pages and lack a header page (with exceptions of
which are more “mellow” pages). Where possible, I opt for card views with pictures instead.
You can read more about the intent behind each flow here:
1. Figure out what to eat
both use a shared underlying table (
) so that they can both be added to your meal plan (as lookup columns can only reference a single table at a time).
: Allows button logic to live in 1 place, i.e. buttons like “Add to Meal Plan”, “Generate Random #’s”, “Pull Image from Wiki”
Some columns don’t apply to both, e.g. ingredients/steps, neighborhood; separate views required to have different popup layouts
Comes to life via buttons (for adding new recipes / restaurants, to the configuration page, and to add specific cards to meal plans) and through sort, filter, and search.
is made to be played with! This essentially hits a “Generate Random #’s” button on the
table and returns the max value, where the recipe / restaurant gets a 0 if it doesn’t meet any of the user’s selected criteria.
No header images on
, as these pages are already picture-filled and a user is coming to these pages to browse and start planning their meals, rather than read a blog post.
Card view with photos and faking card headers via conditional formatting the recipe/restaurant name + the cuisine type.
Different pop-up views for recipes vs. restaurants and for adding / editing vs. viewing stored under
2. Prepare to eat
is a simple, separate table that references
and 2 lookup tables to separate out options & logic for day of the week and meal times.
I did not set the meal plan settings (i.e. day of week, time of day to eat XYZ recipe/restaurant) on the recipe / restaurant level to make it easier for someone to eat the same recipe / restaurant multiple times a week.
references the recipes you selected for your meal plan and pulls a filtered list of grocery list items that the doc detects you need for your recipes by searching through the recipes’ Ingredients.
, this comes to life via buttons both at the meal plan level and on the card (to set the meal time and to open the recipe when you’re ready to cook) and dragging your meals to the relevant day of the week!
, you view 1 recipe at a time and get a slim version of your grocery list with buttons at the bottom that lets you see how much of each ingredient you need for your meal plan’s recipes.
As mentioned in the areas I’d like to explore next on
, it’d be cool to automate the connection between these more, but it’s a bit beyond my skills (and possibly the capabilities of this doc)!
gets a header picture to get you in a Zen planning mindset, but
is meant to be a more functional page and stays a bit cleaner, as it already has a lot going on!
is one big table with rows of unique grocery items and lookups to grocery stores, item categories, units, etc.
The doc is configured for 1 row per unique grocery item to:
Avoid having duplicate rows (that you then have to manually enter config data, e.g. grocery story, item category, etc.) for
Allow our (+) Add Item button to double-duty as adding new items OR opening an existing entry to update
is meant to be used on your phone to add ingredients as you run out and to check things off as you shop, whilst
lets you clean up any missing data attributes.
As always, buttons and search/filter/sort features help bring this to life! The add item button also searches for entries that already exist to avoid double-entering the same item (and thus having to enter grocery store, perishable y/n, category, etc. multiple times).
These are meant to be slim, working pages — so no headers a user would constantly scroll past!
Item pictures automatically come from the Wikipedia pack and obtained items get crossed out + green highlighted, while off-list “archived” items are crossed out + grayed out.
Bonus: Perishables Reminder
This is a simple, simple page referencing your grocery list that’s meant to be view-only to help you remember to use up your perishables! (It could expand to be an inventory tool, but I can’t imagine myself opening Coda to check off each banana I eat from a bunch to keep this live-updated...)