# Substitution Structure — Synthesis

Mode: Multi-variant (Tab / Accordion / Filter)
Users synthesized: 9 (3 per variant)
Hypotheses validated: 3 (1 Pass, 1 Partial, 1 Fail)
Key findings: 4
Recommendations: High 2, Medium 1, Low 1

---

## Context

We tested three structures for the Review & Edit "Substitutions" screen — a **Tab** split, an **Accordion** of collapsible groups, and a **Filter**ed list — to learn which best helps a customer manage which of their grocery items can be replaced if out of stock. 9 participants (3 per variant) worked through the same 9-task scenario: read the screen, state how many items would be replaced, locate a specific item, set a "don't replace," find the items that can't be substituted at all, and rate confidence and clarity.

> Small sample (n=3 per variant) — treat magnitudes directionally; patterns are consistent enough to act on.

---

## Hypothesis results

| # | Hypothesis | Result | Evidence |
|---|------------|--------|----------|
| H1 | Tabs with counts let users state how many items will be replaced **at a glance** | ✅ Pass | 3/3 answered the count correctly and instantly, citing the number on the tab. Highest confidence (avg 4.3) and clarity (avg 4.7). |
| H2 | An accordion lets users **locate and manage** items easily on one scroll | ⚠️ Partial | Users did locate items, but **3/3 complained the layout jumped** when a section expanded/collapsed; 1 mis-added group counts before self-correcting. Confidence and clarity dropped (avg 3.3 / 3.3). |
| H3 | A filtered list is the most **familiar** pattern, so users navigate comfortably | ❌ Fail | Familiar, yes — but **0/3 answered the count correctly**. With no persistent total and items hidden behind the active filter, users under-counted (4), couldn't answer, or guessed. Lowest clarity (avg 2.7). |

---

## Variant comparison

| | Count correct (Q2) | Avg confidence | Avg clarity | Core issue |
|---|---|---|---|---|
| **Tab** | **3 / 3** | **4.3** | **4.7** | "Ineligible" wording read as corporate |
| **Accordion** | 3 / 3 (1 self-corrected) | 3.3 | 3.3 | Layout shifts on expand/collapse |
| **Filter** | **0 / 3** | 3.3 | 2.7 | No persistent count; filter hides items |

---

## Findings

**F1 — Tabs make the count legible; that drove comprehension, confidence, and clarity.**
The per-tab counts answered "how many will be replaced?" without anyone counting rows. Tab led every comprehension and rating measure.

**F2 — The accordion's strength (one scroll) was undercut by motion.**
Items were findable, but every expand/collapse moved the page. All three accordion users named the shifting layout as disorienting — it cost confidence even when the task succeeded.

**F3 — The filter's familiarity hid a comprehension failure.**
It looked like a pattern people knew, so they navigated confidently — but the filtered view removed the very thing the task needed: a running total. None of the three could state the count correctly.

**F4 — ⚠ Unexpected, and cross-variant: the *eligibility* framing confused people regardless of structure.**
The "Ineligible" label (the system's eligible-vs-ineligible model) was flagged across variants — read as corporate jargon, and unclear until tapped. Watching people move through a real order, the question they actually asked wasn't "is this eligible?" — it was **"which of *my* items will get replaced, and which won't?"** The categories were named for the backend's data model, not the customer's decision.

---

## Recommendations

**🔴 High — Ship the Tab structure.**
Best count comprehension (3/3), highest confidence and clarity, lowest interaction friction. Tabs keep categories few and the counts always visible.

**🔴 High — Re-label around the customer's decision, not the system's model.**
Replace the eligibility framing with the question users are actually asking: **"Replace" / "Don't replace."** Surface can't-be-substituted items in plain language (e.g. "Can't be swapped — alcohol & medication") instead of "Ineligible."

**🟡 Medium — Keep a persistent count visible.**
The filter failed because totals disappeared under the active filter. Whatever structure ships, the at-a-glance count is what carries comprehension — never hide it.

**🟢 Low — Avoid layout shift.**
The accordion's expand/collapse motion cost orientation and confidence. Minimize reflow when users act.

---

## Final takeaway

The eligibility split read fine on paper. It was only when people moved through a real order that the mismatch between **how the system thinks** (eligible / ineligible) and **how the customer thinks** (will this get replaced or not?) became obvious enough to fix. The Tab model won — but the bigger win is reorganizing it around the customer's decision, not the backend's data.