Morsel: design alternatives
These notes record the alternatives considered for the first version. The study findings and revisions explain the label and navigation changes now in the demo.
A · What order does the menu take?
A1 · Photos first
Photographed dishes at the top, the rest below. The most attractive screen; it reorders the menu and pushes a third of it below the fold.
A2 · Photographed dishes only
Hide what has no photo. Simple to build, but a diner holding the paper menu would find dishes the app does not have.
A3 · Menu order, gaps shown chosen
Every dish in the restaurant's order. An unphotographed dish keeps its place with a "No photo yet" block the same size as a photo. Less even to look at; the menu stays complete.
A4 · Menu order, plus a Photos view
A3 with a secondary grid of photographed dishes that says how many it leaves out. Added: browsing by photo is the pleasure, the menu is the task.
Design-stage question: whether the gaps bother people, and whether anyone reads "No photo yet" as "not available tonight".
B · How does the menu meet the rest of the app?
B1 · The menu is the whole app
Open to a restaurant picker. Focused, but the first screens are text before any food appears, and there is nothing to do away from a table.
B2 · Two separate apps in one
A nearby feed and a menu mode with no link between them. Each makes sense; neither helps the other.
B3 · The feed leads into the menu chosen
Home is photos of dishes nearby with restaurant cards, and "I'm at a restaurant" one tap from the top. Every dish card opens its dish page, and from there the restaurant's menu. The feed is trimmed: no filters or dietary tiers, so it cannot bury the at-the-table task.
C · How do you get to the restaurant?
C1 · Location request
Guess the restaurant from where the phone is. A permission prompt before any value, and wrong in a dense block.
C2 · Scan the menu
Point the camera at the paper menu and match it. Interesting; out of scope for a design prototype with no backend.
C3 · Pick from photo cards chosen
Restaurant cards with a three-photo strip and a coverage tag, filtered as you type. Lightweight, honest about coverage, no permission, and food on screen before anything is chosen.
D · Where did the photo come from?
D1 · No label
Cleanest. The diner has to guess whether a photo is the kitchen's or a plate someone was served.
D2 · Label diner photos only
Marks the "unofficial" ones. Reads as if restaurant photos are the reference; they are styled shots with their own gap from the plate.
D3 · A label on every photo chosen
"Restaurant photo" or "Diner photo" on each, a short form on thumbnails, and a count when there are several. More to read on every photo; no guessing about source.
Design-stage question: which source people trust for what, and whether they want diner photos first. In this prototype both sources are fixtures; no one contributed anything.
E · How do you choose between dishes?
E1 · Save for later
The earlier design’s answer. Suits browsing across days; at a table the decision is now, and a saved list is somewhere else.
E2 · A cart
Familiar, but Morsel does not place orders, so a cart would end nowhere. It also nudges toward adding rather than choosing between.
E3 · Compare two or three chosen
A shortlist of up to three, shown side by side with price, description, ingredients and whatever photo exists. Remove, add another, back to the menu. Fits a phone width.
F · What stands in for a missing photo?
F1 · A generic image
A stock photo of "pasta" beside a specific dish. It fills the gap and is easily read as the dish itself.
F2 · Nothing
Text-only rows. The dish keeps its place but loses visual weight next to photographed neighbors.
F3 · A placeholder that says so chosen
The same footprint as a photo, a camera-off mark and "No photo yet". The dish stays fully usable: open it, compare it.
Supporting notes from the design and prototype review. Restaurants, menus and photos are fictional sample data.