Wireframes & Clickable Prototype

What you'll produce

A set of low-to-mid-fidelity wireframes for every screen in FreshCart's redesigned browse → cart → checkout flow, linked into a clickable Figma prototype a stranger can tap through end-to-end to place a test order. This is the moment your research (Deliverable 1) and your IA + user-flow map (Deliverable 2) become a thing people can actually use — but deliberately before any visual polish, so feedback lands on structure, content, and flow instead of "I don't like the green." It matters because the clickable prototype is the cheapest possible version of the redesign: it lets you test the experience for real (Topic 7) while a confusing flow still costs $0 to fix instead of three weeks of engineering. For a UX/UI designer, this artifact is the spine of the case study — it's the proof you can take a flow off a diagram and turn it into a tappable experience, and the thing you'll actually put a real user in front of next.

Instructions

Work in Figma (free tier is enough). Stay in grey-box fidelity the whole time — boxes, lines, real labels, placeholder text. No color, no brand, no real photos. If you catch yourself picking a shade of green, you've drifted into Deliverable 5; stop.

1. List the screens from your flow first. Open your Deliverable 2 user-flow map and write down every screen the redesigned browse → cart → checkout path requires, in order. Don't invent screens here — derive them. For FreshCart that's roughly: Home/Browse → Category or Search results → Product detail → Cart → Account gate (guest vs. sign-in) → Delivery address & slot → Payment → Review & place order → Order confirmation. Note any screen your map flagged as a drop-off point — those get extra care.
2. Set a realistic frame size. Use a mobile frame (Figma preset iPhone 14 / 390×844) since FreshCart's pain lives in the app. One Figma frame = one screen. Name each frame exactly as it appears in your flow (02 Product Detail, not Frame 12) so the prototype and your case study speak the same language.
3. Wireframe each screen against a content checklist, not your imagination. For every screen ask the three wireframe questions from Topic 6: Is the right information here? Is it in a sensible order? Is the main action obvious? Give each screen exactly one primary action (one filled grey "button" box) and make it the most prominent thing. Everything secondary stays visually quieter.
4. Apply your IA labels in the user's words. Reuse the navigation labels from Deliverable 2 verbatim. Use plain shopper language on the buttons too — "Place order," "Continue as guest" — never internal jargon like "Commit transaction." This is "match the real world" (Topic 7) applied at the wireframe stage.
5. Directly design out the drop-off causes you found. This is the part that separates a real deliverable from screen decoration. For each sticking point from your research/flow, build the fix into the wireframe and leave a sticky note (Figma text block beside the frame) naming the decision. Example targets for FreshCart: forced account creation, a hidden delivery fee that surprises people at the end, an unclear cart, no sense of "how many steps left."
6. Add a progress indicator across checkout. Since the goal is "a first-timer places an order in under three minutes," put a simple step indicator (e.g. Cart · Delivery · Payment · Review) at the top of each checkout screen so users always know where they are and how much is left ("show users where they are," Topic 5).
7. Wire the screens into a clickable prototype. Switch to Figma's Prototype tab. Drag a connection from each primary-action button to the next frame (On tap → Navigate to). Add a working back affordance on every screen past Home. At minimum, build the one golden path: a guest first-timer taps from Home all the way to Order confirmation without a dead end. Set the confirmation screen's "Back to home" to loop to the start.
8. Add the one or two essential branches, not all of them. A prototype isn't the whole app. Wire the guest-vs-sign-in fork (because forced sign-up is a known FreshCart drop-off) and one realistic recoverable error (e.g. an "address not in delivery area" state with a clear way out — "error prevention and recovery," Topic 7). Skip exhaustive edge cases; you're building a testable path, not production.
9. Smoke-test it yourself on a phone. Open the prototype in the Figma mobile app or share a preview link and run the task "order milk and bananas for tomorrow morning" with your own thumb. Every primary button must go somewhere; there should be zero dead ends on the golden path. Fix anything that traps you.
10. Write the task script and the share link. End your deliverable with (a) the exact one-sentence task you'll hand a tester in Deliverable 4, (b) the expected golden-path screen sequence, and (c) a shareable "anyone with the link can view" Figma prototype URL. The link is non-negotiable — a prototype no one can tap is just pictures.

A small note on scope: 120 minutes is enough for ~8–10 clean grey-box screens and a wired golden path plus two branches. Don't gold-plate. The goal is testable, not finished.

┌─────────────────────────────┐
│  ‹ Back            Cart      │   ← back affordance, top-left
├─────────────────────────────┤
│  [img] Whole milk 2L        │
│        £1.45    [–] 1 [+]  ✕ │
│  [img] Bananas (loose)      │
│        £0.74    [–] 1 [+]  ✕ │
├─────────────────────────────┤
│  Subtotal              £2.19 │
│  Delivery (tomorrow AM) £3.99│   ← fee shown HERE, not at the end
│  ─────────────────────────  │
│  Total                 £6.18 │
├─────────────────────────────┤
│  ▣  Checkout  →             │   ← single primary action, full-width
└─────────────────────────────┘
   sticky note: "Delivery fee surfaced in cart (not checkout) —
   directly fixes the 'maze' / surprise-cost complaint from reviews."

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

• Screen coverage traces to the flow — 1: missing screens or invented ones that aren't in the Deliverable 2 flow · 2: every screen in the browse → cart → checkout flow is wireframed and named · 3: complete coverage, frame names match the flow's user-language labels, and drop-off screens are explicitly identified.
• Appropriate fidelity — 1: jumped to color/brand/photos, or so rough it's unreadable · 2: clean grey-box wireframes that show structure and content without visual styling · 3: disciplined low-to-mid fidelity that keeps attention on layout, with one clear primary action per screen.
• Clickable & complete prototype — 1: static screens, dead ends, or no shareable link · 2: a working link where the golden path is tappable start-to-finish with back navigation · 3: golden path plus 1–2 essential branches (e.g. guest/sign-in fork, a recoverable error) wired cleanly, self-smoke-tested, zero dead ends.
• Design decisions target the real problem — 1: screens are decorated but don't address known drop-off causes · 2: at least the top drop-off cause is visibly designed out · 3: each major sticking point from research is fixed in the wireframe and the decision is logged (sticky note / annotation) with a why.
• Testability — 1: no task or unclear what to test · 2: a realistic task scenario and expected path are written · 3: a neutral, first-timer task script plus the expected golden-path sequence and a working share link — genuinely ready to hand to a tester in Deliverable 4.
• Coherence with prior deliverables — 1: disconnected from the persona/IA/flow work · 2: clearly builds on the IA labels and flow map · 3: tightly traces research insight → IA/flow → these wireframes, so the case-study narrative is already forming.