Recall Finder UX: Confirm Brand and Lot Before a Match
A recall-checking app should verify more than a product name. Use label capture, explicit confirmation and clear uncertainty to help users assess a possible match.
A recall finder is only useful if people can tell whether the notice applies to the product in their hand. The supplied Google Trends US signal, alongside coverage describing recalled eye drops sold under several brand names, makes a durable product-design question salient: what should an app ask users to confirm before it presents a match? The answer is not simply “scan the barcode.” Brand, product variant and lot or batch details may all matter, and a missing or unreadable identifier should not be silently treated as a confirmed match. This guide sets out a practical verification flow for teams scoping a recall-checking mobile app, including how to communicate uncertainty without overstating safety.
Ask for identifiers that can distinguish the affected item
Start with the fields that the recall notice actually uses to define affected products. Depending on the notice, users may need to check the brand or label name, product name, variant or strength, package size, lot or batch number, and an expiry or best-before date. Do not assume every notice contains every field, or that a barcode uniquely identifies a production lot. The data model should represent which identifiers are required, optional or unavailable for each notice. That keeps the interface tied to evidence in the source notice rather than presenting a generic checklist as if it applied universally.
For each field, show users where to look and preserve the label’s own wording. A camera view can guide a photo or barcode scan, but the app should display the captured brand and lot number as editable text before searching. Ask the user to confirm that the displayed value matches the physical package, including letters, digits and separators that are easy to confuse. Where multiple brand names are included in a notice, show those names clearly and let users select or confirm the one printed on their item. A scan is a way to collect information; it is not, by itself, proof that the product is affected.
- Define notice-specific required fields before designing a universal recall-check form.
- Keep scanned values editable and ask for confirmation before submitting a check.
Design capture and manual entry as equal paths
Label capture can reduce typing, but it needs a deliberate fallback. Packaging may be curved, reflective, worn or printed in small type, and a user may not be able to grant camera access. Offer manual entry for each relevant identifier, explain the expected format, and avoid rejecting a value merely because it differs from an assumed format unless the notice supports that validation. If text recognition is used, distinguish its suggestion from the user-confirmed value. A practical flow shows the captured text, invites correction, and lets the user retake the image or continue manually without losing information already entered.
Before a result appears, summarize the inputs: brand, product or variant, and lot or date where applicable. Let users correct any field, then record which values were user-entered, scanned or left blank. This supports troubleshooting when a person reports an unexpected result and helps product teams identify weak capture steps. A hypothetical example: a notice identifies a specific eye-drop brand and a set of lots, while a shopper scans only a barcode shared by several packages. The app should request the lot number from the label rather than treating that scan as enough to confirm a match.
- Offer camera capture and manual entry without making either path a dead end.
- Show a final input summary and let users edit it before checking.
Communicate match, non-match and uncertainty honestly
Use result states that reflect what the available information can support. A confirmed match should identify the matched brand and lot or other relevant field, name the notice, and direct users to its authoritative instructions. A possible match can indicate which detail agrees and which remains unverified. If a required identifier is missing, unreadable or absent from the app’s notice data, say that the check is inconclusive and explain what the user can inspect next. A “no match found” result should not be phrased as proof that a product is safe: the notice coverage may be limited, or the entered details may be incomplete or mistyped.
This distinction has scope and operational consequences. Product teams need a documented path for sourcing and updating recall notices, mapping aliases and brand names, and preserving the notice version used for a check. They should also test common user errors: swapped characters, missing lot numbers, multiple brands, partial scans, old notice data and interrupted camera access. In a hypothetical MVP, ship a carefully bounded search and a clear manual-confirmation flow before adding more elaborate image recognition. Decide who reviews notice updates, how stale data is surfaced, and what users see when the service cannot verify a result. Those choices affect backend requirements as much as screen design.
- Use distinct result language for confirmed match, possible match, no match and inconclusive checks.
- Plan notice provenance, update ownership and stale-data messaging as part of the MVP.
Before showing a recall result, ask users to confirm the identifiers that the specific notice uses—often a brand and product detail, plus a lot or date when listed. Treat scans as input, not authority; support careful manual entry; and make missing information visible. For product leaders, the key scope decision is how the app will obtain, update and explain its recall data, not merely how it will scan a label. A trustworthy finder makes the evidence and its limits clear enough for users to take the next appropriate step.