Design a Mobile App From Scratch: Same-Day Grocery Delivery for a Single Neighborhood

1. Clarifying questions and assumptions

• "Is inventory live per store (real stock counts) or an estimate?" Assume live-ish inventory synced from partner stores' POS systems, since "within the hour" delivery collapses if an item is promised but out of stock at pack time.
• "Is this single-order-per-checkout, or can a user combine items from multiple stores in one delivery?" Assume single store per order for the MVP — multi-store consolidation is a fulfillment and routing problem, not a screen-design problem, and adds significant scope.
• "Who delivers — a dedicated fleet, or a third-party courier integration?" Assume third-party courier API, since building a delivery fleet is out of scope for a design exercise about the consumer app.
• "Is pricing store-set or platform-set?" Assume store-set with a visible platform delivery fee, stated up front, not buried at checkout — this becomes a microcopy decision later.

2. Job-to-be-done

Functional job: "Get groceries I need today into my home within the hour, without going to the store myself." Emotional/social dimensions: relief from the friction of an unplanned need (ran out of something mid-cooking, guests arriving soon) — the emotional core is removing a specific, time-boxed inconvenience, not general meal planning (that's a different, slower-paced JTBD better served by a weekly-planning app, not this one). A demographic persona would blur this — a busy parent and a college student hosting friends have nothing in common demographically but share the exact same triggering moment.

3. MVP scope

In scope: browse one store's available inventory → build a cart → checkout with delivery estimate → track delivery status. Out of scope, stated explicitly: multi-store combined orders (fulfillment complexity, not this session's problem), recipe-based or list-suggestion features (a discovery enhancement, not core to the urgent-need job), loyalty/rewards programs (retention feature, premature before the core loop is proven), and driver-facing tooling (a completely separate product for a separate user).

4. Information architecture

A bottom tab bar with three destinations: Shop (store selection and browsing, the default landing tab, since the job is urgent and task-first), Orders (active delivery tracking plus order history — kept top-level rather than buried, because a user mid-delivery will check status compulsively, the same reasoning the case study applies to a "Bookings" tab), and Account (payment, address, saved stores). Three tabs, not more, for the same Hick's-Law reasoning the case study uses — no fourth job in this MVP's scope needs its own slot.

5. Core flow wireframes

Store selection screen: a short list of partner stores within delivery range, sorted by estimated delivery time, not alphabetically — because "within the hour" is the differentiating promise, so the list should surface it as the primary sort key, the same logic the case study applies to sorting classes by soonest availability rather than by name.

Store browse/cart screen: category-grouped product grid with a persistent, sticky cart summary bar at the bottom — a Gestalt proximity decision (group items by category so a scanning eye doesn't re-parse unrelated products together) paired with a Fitts's Law decision (the "View Cart / Checkout" action stays large and thumb-reachable at all times rather than requiring a scroll back up).

Checkout screen: delivery address (pre-filled from Account), delivery-fee and total shown before the final confirm tap — not revealed only after tapping "place order," since a surprise fee at the last second directly undermines the "remove friction" emotional job this app exists to serve.

6. Microcopy

Empty state (no stores currently delivering to this address): "No partner stores deliver here yet — we're adding neighborhoods every month. [Notify me when one's available]" — states the honest reason (coverage, not a bug) and gives a concrete next action instead of a dead end.

Order confirmation: "Order placed — arriving by 3:40pm from Green Aisle Market. [Track delivery]" — leads with the concrete, time-anchored fact (when, from where) rather than a generic "Success!", mirroring the case study's booking-confirmation copy.

7. Accessibility consideration

Product images alone are not a reliable way to distinguish similar items (e.g., two brands of oat milk) for a low-vision or screen-reader user — every product card needs a text label sufficient on its own (brand, size, price) rather than relying on the product photo to carry disambiguating information, the same "never let a visual-only signal carry meaning" principle the case study applies to color-coded status.

8. HEART metrics

Task success: % of started orders that reach a completed checkout. Adoption: % of new signups who complete a first order within their first 7 days. Retention: % of users who place a second order within 30 days of their first.

9. Close

"The flow is: pick a nearby store sorted by delivery speed, browse and build a cart, check out with the fee shown up front, and track delivery — measured by checkout completion, 7-day first-order adoption, and 30-day repeat-order retention. The biggest unvalidated risk is whether 'within the hour' is a promise the courier integration and store pack times can actually keep at scale — if that SLA slips regularly, the core trust proposition collapses the same way stale availability data would break the case study's fitness-class app, and I'd want to validate that operational constraint before designing further."