Product Shop – UX Specification

Related Technical Authority: Product Shop – Technical Specification

1. Purpose

This UX specification governs the end-to-end experience of Primoro's Product Shop module — a clinician-recommended commerce surface that allows patients to purchase dental and oral-care products directly through the Primoro patient app. It defines how patients browse, purchase, and track orders, and how practice staff configure the catalogue, manage orders, process refunds, and monitor commerce performance. The primary roles it serves are: authenticated patients (purchasers), clinicians (recommenders), and practice administrators (catalogue owners and order managers).

2. Core UX Principles (Non-Negotiable)

These principles take precedence over visual preferences. If a design choice conflicts with a principle below, the principle wins.

• Action-first — users see the action they need next, not abstract status displays.
• Governance always visible — when AI is involved, users always know what AI did and what they're confirming.
• No dead toggles — every UI control either does something or doesn't appear.
• Calm by default — the interface gets out of the way; alerts are reserved for things that genuinely need attention.
• Progressive disclosure — advanced detail is one click away, not always-on.
• Clinical framing is non-negotiable — products are always presented in a care-team context. Retail discovery patterns (trending items, social proof, upsell carousels) MUST NOT appear anywhere in the product surfaces. This principle is inferred from the technical spec §4.1, which mandates clinical framing and explicitly prohibits retail discovery patterns.
• Payment integrity at every step — the checkout flow communicates clearly at each stage whether payment has succeeded or failed, and no order is shown to the patient until payment is confirmed. This is inferred from the technical spec §3.2 and §5.2, which prohibit Order records in an unpaid state.
• Staff accountability is always visible — refunds and governed actions display the name of the staff member who performed them. This is inferred from the technical spec §5.3 and §9, which require named actor attribution for all refund and governance actions.

3. Design Philosophy

The Product Shop's mental model is a trusted clinical handoff: the clinician has already made the recommendation; the patient's job is simply to decide and pay. The interface should feel like completing a trusted suggestion rather than shopping. This is inferred from the technical spec §4.1, which mandates that products are surfaced only via clinical recommendation or AI-assisted prompts approved by a staff member.

Empty states: When no products have been recommended, the patient-facing surface should show a calm, informative empty state explaining that recommendations will appear here after an appointment — not an empty shop grid. This is inferred from the technical spec §4.1's prohibition on open retail discovery. (needs UX writer input — exact empty-state headline and supporting copy)

Error states: Payment failures must be handled gracefully with a clear prompt to retry, since the technical spec §5.2 mandates checkout abort and retry prompt on any failed payment capture. No partial or ambiguous state should be displayed. (needs UX writer input — payment failure error copy and retry call-to-action label)

AI suggestions: AI-generated product suggestions are never presented directly to the patient. From the patient's perspective, all recommendations come from their care team. On the staff-facing surface, AI-suggested recommendations that are pending approval must be visually distinct from staff-authored recommendations — using a consistent AI badge or indicator — so that staff know they are reviewing a suggestion before approving it. This is inferred from the technical spec §7, which prohibits unconfirmed AI suggestions reaching patients, and §8, which requires logging of approvals and rejections.

Multi-step flows: Checkout is a short, linear wizard — recommendation context, product confirmation, payment, confirmation. No branching browsing. This is inferred from the technical spec §5.2's linear payment flow. Refund initiation is a governed modal flow with mandatory reason-code selection and MFA confirmation before submission, inferred from §5.3 and §9.

Undo/redo: Orders are immutable once created (technical spec §15.3). There is no undo for a completed purchase; the only correction path is a refund. The UI must not offer undo controls for order creation.

Read-only vs editable: Order records are always read-only for patients. Staff can view all practice orders in read-only mode; only staff with the appropriate role (Practice Admin) can initiate refunds or configure the catalogue. Read-only surfaces must be visually distinct from editable ones. This is inferred from the technical spec §9 access control table.

4. Primary Surfaces

4.1 Web Portal

Who uses it: Practice Admins, Clinicians (read-only order view), Finance role staff.

Key tasks performed here:

• Browse and manage the practice's active product catalogue, including setting retail prices and attaching optional practice notes per product. Inferred from technical spec §4.2 and §15.3.
• View and filter the full order list by status, date range, fulfilment type, and patient. Inferred from technical spec §15.4.
• Initiate full or partial refunds against an order, selecting a mandatory reason code and completing MFA confirmation. Inferred from technical spec §5.3 and §9.
• Monitor the Product Shop dashboard: revenue totals, order volume, recommendation-to-purchase conversion rate, fulfilment exception queue, and refund volume with reason-code breakdown. Inferred from technical spec §10.4 and §15.4.
• Review and approve or reject AI-generated product recommendation suggestions before they are surfaced to patients. Inferred from technical spec §7.
• Handle fulfilment exceptions flagged by Communication Hub. Inferred from technical spec §6.2 and §11.2.

Layout pattern: List-detail for the order management view (order list on the left, order detail on the right). Dashboard for the analytics surface. Form/wizard for refund initiation. Inferred from the nature of the data objects in technical spec §3 and the filtering/view requirements in §15.4.

4.2 Tablet App

Who uses it: Clinicians in surgery and front-of-house staff, primarily for chairside product recommendation during or after an appointment. Inferred from technical spec §10.3.

Key tasks performed here:

• Review and approve AI-generated product suggestions or create explicit product recommendations for a patient during or after an appointment. Inferred from technical spec §4.1 and §7.
• View a patient's pending and past orders during an appointment context. Inferred from technical spec §9, which grants Clinicians read access to orders.
• Mark In-Clinic fulfilment tasks as ready for patient collection (staff task surfaced from Communication Hub). Inferred from technical spec §6.2 and the enriched note in that section.

Touch ergonomics: One-handed reach considered; glove-friendly tap targets ≥48 px; confirmation dialogs avoid bottom-edge placement.

(needs UX writer input — whether tablet checkout is supported in-clinic is an open product question; see Open Questions §13)

4.3 Mobile App (Patient)

Who uses it: Authenticated patients browsing clinician-recommended products, completing purchases, and tracking order and fulfilment status. Inferred from technical spec §10.1.

Key tasks performed here:

• View products recommended by their care team, with the clinical framing preserved at all times (e.g. a "recommended by your care team" attribution). Inferred from technical spec §4.1.
• Complete the checkout flow: review product(s), confirm purchase, enter or confirm payment method (card, Apple Pay, Google Pay), receive confirmation. Inferred from technical spec §5.2.
• View order history and per-order fulfilment status, including shipment tracking for Drop-Ship orders and pickup-readiness notification for In-Clinic orders. Inferred from technical spec §6.2 and §10.1.
• Receive and read order confirmation and fulfilment update notifications, delivered via Communication Hub. Inferred from technical spec §11.2 and §6.2.

5. Interaction Model

5.1 Primary Flows

Flow 1 — Patient: view recommendation and purchase

This flow is inferred from the technical spec §4.1, §5.2, and the payment flow in §15.2.

Start: Patient opens app; a product recommendation is present (surfaced
       after an appointment or via staff-approved prompt)
  │
  ▼
Patient views recommended product card
  │  (clinical framing visible — "recommended by your care team")
  ▼
Patient taps to view product detail
  │
  ▼
Patient taps checkout / add to order
  │
  ▼
Payment method selection / confirmation
  │  (card, Apple Pay, Google Pay — via Integrated Payments UI)
  ▼
Payment submitted to DNA Payments
  │
  ├──[Payment success]──────────────────────────────────────────┐
  │                                                             ▼
  │                                              Order record created (Created state)
  │                                                             │
  │                                              Order confirmation screen shown to patient
  │                                                             │
  │                                              Communication Hub emits confirmation event
  │                                                             │
  │                                                           End
  │
  └──[Payment failure]──────────────────────────────────────────┐
                                                                ▼
                                          Checkout abort — no Order record created
                                                                │
                                          Patient shown payment failure state
                                          with retry prompt
                                                                │
                                                              End

Flow 2 — Clinician / staff: approve AI recommendation before patient delivery

This flow is inferred from the technical spec §7 and §8.

Start: AI generates contextual product suggestion for a patient
  │
  ▼
Suggestion held in pending state — NOT delivered to patient
  │
  ▼
Staff/clinician sees pending AI suggestion (visually badged as AI-generated)
on tablet or web portal
  │
  ├──[Approve]────────────────────────────────────────────────┐
  │                                                           ▼
  │                                         Approval event logged to Audit & Compliance
  │                                                           │
  │                                         Recommendation surfaced to patient in app
  │                                                           │
  │                                                         End
  │
  └──[Reject]──────────────────────────────────────────────────┐
                                                               ▼
                                          Rejection event logged to Audit & Compliance
                                                               │
                                          Suggestion discarded — patient never sees it
                                                               │
                                                             End

Flow 3 — Staff: initiate a refund

This flow is inferred from the technical spec §5.3, §9, and the MFA requirement in §9.

Start: Staff member opens an order in the web portal
  │
  ▼
Staff selects "Initiate refund" action
  │
  ▼
Refund modal opens — staff selects full or partial refund
  │
  ▼
Staff selects mandatory reason code (from Integrated Payments-defined set)
  │
  ▼
Summary shown: amount, reason code, original payment reference
  │
  ▼
MFA challenge presented to staff member
  │
  ├──[MFA passed]─────────────────────────────────────────────┐
  │                                                           ▼
  │                                         Refund submitted to Integrated Payments
  │                                                           │
  │                                         Immutable audit entry created
  │                                                           │
  │                                         Order status updated (Refunded overlay)
  │                                                           │
  │                                         Communication Hub emits refund notification
  │                                                           │
  │                                                         End
  │
  └──[MFA failed / cancelled]──────────────────────────────────┐
                                                               ▼
                                          Refund aborted — no state change
                                                               │
                                                             End

5.2 UX Boundary: Product Shop vs Hygiene Subscriptions

Products may appear in both the Product Shop and the Hygiene Subscriptions module, but the two workflows represent fundamentally different mental models and MUST be kept visually and conceptually separate at every patient-facing and staff-facing touchpoint.

• Product Shop represents a one-time, transactional purchase: the patient pays immediately via the checkout flow, receives a single order, and fulfilment is handled per that order. The pricing shown is the retail price configured by the practice.
• Hygiene Subscriptions represents a recurring clinical programme: products included in a subscription plan are selected as part of a care pathway, not purchased individually at checkout. Pricing, delivery cadence, and billing are governed entirely by the Hygiene Subscriptions module.

The following rules apply at the UX boundary between the two modules:

• A product that is already included in a patient's active hygiene subscription MUST be clearly labelled as such on its Product Shop recommendation card, so that the patient understands they will not be charged again via Product Shop for a product they already receive through their subscription. (needs UX writer input — label copy for "included in your subscription" indicator)
• The Product Shop checkout flow MUST NOT present subscription billing options, recurring payment UI, or any affordance that implies ongoing billing. If a patient attempts to purchase a product that should only be acquired through a subscription, they must be clearly directed to the Hygiene Subscriptions module rather than permitted to proceed through the one-time checkout. (needs UX writer input — redirect message copy)
• On staff-facing surfaces, the catalogue management view MUST distinguish between products available for ad-hoc purchase via Product Shop and those that are only available as subscription components. Controls for subscription configuration (cadence, plan assignment) are owned by the Hygiene Subscriptions module and MUST NOT appear within the Product Shop catalogue management surface.
• Clinicians recommending a product via the tablet app chairside view MUST see a clear indicator if that product is already part of the patient's active subscription, to avoid creating a duplicate recommendation that would prompt the patient to purchase something they already receive.

These rules are inferred from the explicit out-of-scope boundary in technical spec §2.2 and §13, which exclude subscription billing from Product Shop, and from the clinical-framing principle (§2 above), which requires that patients always understand the care context and commercial nature of any product interaction.

5.3 State Machines (Mirror of Technical Spec §3.3)

The following UX treatments mirror the Order state machine defined in the technical spec §3.3.

Additional rules reflected in the UI:

• The Completed → Fulfilment-In-Progress reversal is impossible; the UI must never offer a control that would imply this. Inferred from technical spec §3.3, which prohibits this reversion.
• For mixed-fulfilment orders, line-item fulfilment status is shown per line item, with the parent order status reflecting the least-advanced item. Inferred from the enriched note in technical spec §3.3.
• Refunded is shown as an overlay on the existing status, not as a replacement, so that a Completed order that has been refunded displays both states. Inferred from technical spec §3.3's "terminal overlay state" definition.

5.4 Empty / Loading / Error / Offline States

Patient mobile app — recommendations screen

• Empty state: Shown when no products have been recommended to this patient yet. Explains that recommendations from their care team will appear here. Inferred from the clinical-framing-only model in technical spec §4.1. (needs UX writer input — empty state headline and supporting copy)
• Loading state: Skeleton cards matching the product card layout while recommendations load.
• Error state: Inline error with a retry action if the recommendations list fails to load. (needs UX writer input — error message copy)
• Offline state: Previously loaded recommendations may be shown from cache in a read-only, non-purchasable state. Checkout is disabled when offline, with a clear explanation. (needs UX writer input — offline copy)

Patient mobile app — checkout

• Empty state: Not applicable (checkout is entered from a recommendation, not browsed to independently).
• Loading state: Payment submission shows an in-progress indicator while awaiting DNA Payments capture confirmation. Target: ≤2 s p95, inferred from technical spec §16. The UI must prevent duplicate submission during this window.
• Error state: Payment failure triggers checkout abort and a clear retry prompt. No Order record is shown. Inferred from technical spec §5.2 and §15.2. (needs UX writer input — payment failure copy and retry label)
• Offline state: Checkout is fully blocked when offline; patient is shown a clear message that payment requires a connection. (needs UX writer input — offline checkout copy)

Staff web portal — order list

• Empty state: Shown when no orders exist for the selected filters. Distinguishes between "no orders yet" and "no orders match your filters", with a clear way to clear filters. (needs UX writer input — empty state copy)
• Loading state: Skeleton list rows while the order list loads.
• Error state: Inline error with a retry action if the order list fails to load. (needs UX writer input — error copy)
• Offline state: Staff portal offline behaviour to be aligned with platform-wide offline policy. (needs UX writer input — confirm platform default)

Staff web portal — dashboard

• Empty state: Shown when no orders have been placed yet (e.g. module newly enabled for a practice). Dashboard widgets show zero states rather than blank space. (needs UX writer input — zero-state copy for dashboard widgets)
• Loading state: Skeleton chart and metric placeholders.
• Error state: Per-widget error states if individual data feeds fail, so that a partial failure does not blank the whole dashboard. (needs UX writer input — widget error copy)
• Offline state: Cached data shown with a "last updated" timestamp; live refresh disabled. (needs UX writer input — stale-data indicator copy)

6. Component Inventory

New components introduced or extended by this module:

• Product recommendation card — displays a single clinician-recommended product with image, name, description, retail price, and care-team attribution. Appears on the patient mobile app recommendations screen and in the tablet app chairside view. Where applicable, carries a "included in your subscription" indicator when the product is already part of the patient's active hygiene subscription (see §5.2). Inferred from technical spec §3.1 and §4.1.
• Order status badge — compact badge showing the current Order state (Created, Fulfilment-In-Progress, Completed, Refunded overlay). Appears on the patient order history view and the staff order list. Inferred from the Order state machine in technical spec §3.3.
• Line-item fulfilment tracker — per-line-item fulfilment status indicator within an order detail view, supporting mixed-fulfilment orders. Inferred from technical spec §6.1 and the enriched note in §3.3.
• Refund initiation modal — governed modal with full/partial amount selector, reason-code picker (sourced from Integrated Payments-defined set), summary review step, and MFA challenge. Staff web portal only. Inferred from technical spec §5.3 and §9.
• AI recommendation review panel — displays a pending AI-generated product suggestion with product details, AI badge, and approve/reject controls. Staff web portal and tablet app. Inferred from technical spec §7 and §8.
• Product catalogue management row — editable row for a single product in the practice's catalogue, showing name, category, fulfilment type, retail price (editable), practice note (editable), and availability status. Staff web portal only. Products that are only available as subscription components are clearly distinguished from those available for ad-hoc purchase (see §5.2). Inferred from technical spec §4.2 and §15.3.
• Commerce dashboard widget set — summary metric tiles and chart components for revenue, order volume, conversion rate, fulfilment exception queue, and refund breakdown. Staff web portal only. Inferred from technical spec §10.4 and §15.4.

Reused from the design system:

• Form fields (text input, dropdown/select for reason codes and filters)
• Toast notification (order confirmation, refund success)
• In-app banner (fulfilment exception alert for staff)
• Skeleton loader
• MFA challenge component (shared with Integrated Payments / Access Manager flows)
• Data table with filtering (order list, refund list)
• Modal / dialog shell

7. Visual Design Notes

• Typography: (needs UX writer input — heading and body scale to follow platform design system)
• Colour: Semantic colour usage must distinguish: order success (Completed), in-progress fulfilment, refunded overlay state, AI-suggestion badge, and payment failure error. Specific tokens to follow the platform design system. (needs UX writer input — confirm semantic token names with design system)
• Iconography: Icon set to follow platform design system; icons must never appear without a visible text label or programmatic accessible name.
• Motion: Transitions used sparingly — only where they communicate a meaningful state change (e.g. order confirmation). Nothing is animated purely for decoration. Respects prefers-reduced-motion.
• The AI badge / indicator used on pending AI suggestions must be consistent with the platform-wide convention for AI provenance marking, whatever that convention is. This is inferred from the governance requirement in technical spec §7 and §8, and the UX principle "governance always visible". (needs UX writer input — confirm platform AI badge design token / pattern)

8. Accessibility & Inclusivity

The module MUST meet WCAG 2.2 AA. Specifically:

• Text contrast ≥4.5:1 (normal) / ≥3:1 (large)
• All interactive controls reachable via keyboard
• Focus states visible
• Form fields have programmatic labels
• ARIA used only where native semantics are insufficient
• Touch targets ≥44×44 px on mobile/tablet
• Motion can be reduced via prefers-reduced-motion
• Screen reader tested on NVDA (Windows), VoiceOver (iOS/macOS), TalkBack (Android)
• The order status badge and line-item fulfilment tracker must not rely on colour alone to communicate state — a text label or icon+label combination is required at all times. Inferred from the multiple distinct states in the Order state machine, technical spec §3.3.
• The AI badge on pending recommendations must have a programmatic accessible name so that screen reader users understand the provenance of the suggestion. Inferred from technical spec §7's governance requirement and the core UX principle "governance always visible".
• The MFA challenge during refund initiation must be fully keyboard-navigable and screen-reader-compatible, given its governed, high-stakes nature. Inferred from technical spec §9 and §5.3.

9. Internationalisation

• Locale-aware date/time/number formatting
• All user-facing strings externalised
• Layouts tolerant of 30% string-length growth (German, French)
• Currency formatting must use locale-aware decimal and grouping separators, since retail prices and refund amounts are displayed to both patients and staff. Inferred from the presence of RetailPrice and refund Amount fields in technical spec §3.1 and §15.1.
• RTL support: (needs UX writer input — confirm whether RTL is required for this module's launch markets)

10. Cross-Module UX Touchpoints

Where this module's UX intersects with related modules:

• Integrated Payments — the checkout flow hands off to the Integrated Payments / DNA Payments UI for card entry and payment method selection, then returns to Product Shop on success or failure. The hand-off point must be visually seamless and consistent with the platform's payment UI conventions. The refund initiation flow also calls into Integrated Payments for processing. Inferred from technical spec §5.1, §5.2, and §5.3.
• Communication Hub — Product Shop emits events to Communication Hub for all order lifecycle stages (confirmation, payment receipt, shipment/pickup readiness, refund/cancellation, delivery exceptions) and for In-Clinic staff task generation. Patients and staff receive these as in-app notifications, push notifications, and email/SMS. The notification content and templates are owned by Communication Hub; Product Shop supplies the triggering event and data payload. Inferred from technical spec §11.2 and §6.2.
• Access Manager — role-based access is enforced at every surface boundary. The current user's role (Practice Admin, Clinician, Finance, patient) determines which controls are visible and interactive. The MFA challenge during refund initiation is delivered via Access Manager. Inferred from technical spec §9 and §12.
• Audit & Compliance — staff-facing surfaces should provide a route (or cross-link) to the Audit & Compliance module for inspecting the audit trail of a specific order, refund, or AI approval event. The audit log itself is owned by Audit & Compliance; Product Shop contributes the events. Inferred from technical spec §8 and §11.2.
• Finance — the Product Shop dashboard exposes order-level revenue and refund data. Finance-role staff may navigate from the Product Shop dashboard to the Finance module for VAT reporting and reconciliation. The exact hand-off point is not defined in the technical spec. Inferred from technical spec §11.2 and §2.2.
• Appointment Manager — product recommendations may be surfaced in the patient app after an appointment context is received from Appointment Manager. From the patient's perspective, the recommendation appears as a natural continuation of their appointment, not a separate commercial event. Inferred from technical spec §4.1 and §11.1.
• Hygiene Subscriptions — explicitly out of scope for Product Shop in terms of shared UI surfaces. However, where a product exists in both modules, the Product Shop UX MUST clearly communicate to patients whether a product is already covered by their active subscription, so that they are not misled into purchasing something they already receive. Staff-facing surfaces must not expose subscription configuration controls. If a patient or staff member attempts an action that would require subscription billing, they must be clearly directed to the Hygiene Subscriptions module. See §5.2 for the full set of boundary rules. Inferred from technical spec §2.2 and §13.

UX consistency rules:

• Action buttons (e.g. initiate refund, approve recommendation) follow the platform-standard placement convention — bottom-right on tablet, top-right on web — to maintain spatial consistency across modules.
• The AI badge / AI provenance indicator must be identical in visual form to any equivalent badge used elsewhere on the platform, to avoid patients or staff encountering multiple AI-provenance patterns.
• Order status badges must use the same design token set as status badges in any other module that displays order or task status, to prevent patients and staff learning multiple badge vocabularies.

11. Governance & Auditability

The following governance treatments are inferred from the technical spec §7, §8, and §9.

• AI-generated product suggestions are visually distinct from staff-authored recommendations on every staff-facing surface, using a consistent AI badge. Patients never see an unconfirmed AI suggestion; from the patient's perspective, all recommendations are from their care team. Inferred from technical spec §7.
• Audit-significant actions — refund initiation and AI recommendation approval/rejection — display a confirmation step that summarises the action (amount, reason code, product name, patient) before the user commits. The confirmation step must name the acting staff member explicitly. Inferred from technical spec §5.3 and §8.
• The MFA challenge for refund initiation is presented as an integral part of the refund flow, not as a separate uncontextualised step — the UI should make clear why MFA is required at this point. Inferred from technical spec §9.
• Every order detail view (staff-facing) surfaces a link or panel showing the immutable audit trail for that order — state transitions, actor identity, timestamps, and refund events — accessible to Practice Admin and Finance roles. Inferred from technical spec §8 and §9.
• Read-only order views (available to Clinicians) are visually distinct from the editable/actionable views available to Practice Admins — controls that the user's role does not permit must not appear as disabled ghost buttons; they must not appear at all. This follows the "no dead toggles" principle and is inferred from the access control table in technical spec §9.
• The practice catalogue configuration surface clearly marks products with an Unavailable availability status so that admins understand why those products are not purchasable by patients. Inferred from technical spec §4.2 and rule 7 in §15.2.
• Refund records displayed to staff always show: refund amount, reason code, initiating staff member name, timestamp, and reference to the original DNA Payments transaction. Anonymous or system-attributed refunds are never displayed, because they cannot exist. Inferred from technical spec §5.3.

12. Notification & Communication Patterns

All of the following notification patterns are inferred from the technical spec §6.2, §11.2, and §15.2 rule 12. Product Shop does NOT send notifications directly; all communications are emitted as events to Communication Hub, which owns delivery.

• In-app banner (staff web portal) — used for fulfilment exceptions requiring human action (e.g. a Drop-Ship delivery exception flagged back to the practice). Surfaced on the order management view and fulfilment exception queue dashboard widget. Inferred from technical spec §10.4 and §6.2.
• Toast (patient mobile app) — used for transient confirmations: order placed successfully, recommendation dismissed. Short-lived, does not require user acknowledgement. Inferred from the standard confirmation pattern implied by the payment success flow in technical spec §5.2.
• Toast (staff web portal) — used for transient action confirmations: refund submitted, AI recommendation approved or rejected, catalogue change saved. Inferred from the governed action patterns in technical spec §5.3 and §7.
• Push notification (via Communication Hub — NOT directly) — sent to patient for: order confirmation, shipment dispatched (Drop-Ship), order ready for collection (In-Clinic), refund processed. Inferred from technical spec §6.2 and §11.2.
• Email/SMS (via Communication Hub — NOT directly) — sent to patient for: order confirmation with payment receipt, fulfilment updates, refund confirmation. Inferred from technical spec §6.2 and Communication Hub's ownership of all lifecycle communications per §11.2.
• Staff task notification (via Communication Hub — NOT directly) — generated when an In-Clinic fulfilment item requires stock preparation for patient collection. Delivered as a task in the Communication Hub staff task queue, not as a push notification. Inferred from the enriched note in technical spec §6.2.

13. Open Questions

UX decisions to resolve before this spec is promoted from draft to published.

1. Tablet app checkout — the technical spec (§10.3 and open question 3 in §17) explicitly leaves open whether checkout (not just recommendation) is supported on the tablet in-clinic. A product decision is needed before the tablet app surface in §4.2 can be fully specified. If checkout on tablet is confirmed, the entire checkout flow (§5.1 Flow 1) must be designed for touch ergonomics and the In-Clinic context.
2. Availability status workflow — the technical spec (§17 open question 4) does not define whether Primoro catalogue team only, or also practice admins, can set AvailabilityStatus. This affects what controls appear in the catalogue management surface (§4.1). It also affects what the UX shows when a product becomes unavailable mid-order (a state the technical spec flags but does not resolve).
3. Communication Hub event schema — the technical spec (§17 open question 5) notes that specific event payload shapes for order lifecycle communications are unresolved. Until these are agreed with the Communication Hub module owner, the notification patterns in §12 cannot be fully designed (the content and structure of each notification is unknown).
4. Data retention and patient-facing order history — the technical spec (§17 open question 1) leaves data retention period undefined. The UX needs to know how far back a patient can see their order history and whether older records become inaccessible or are archived, as this affects the order history empty/end states.
5. AI badge and provenance pattern — the platform-wide convention for visually marking AI-generated content has not been confirmed in this spec. The AI recommendation review panel (§6) and the governance treatments in §11 depend on a consistent, platform-agreed AI badge. This must be resolved with the platform design system team before these surfaces can be finalised.
6. In-Clinic stock visibility — the technical spec (§17 open question 2) leaves unresolved whether Primoro should surface any stock-level visibility or low-stock alerting for In-Clinic fulfilment. If this is added in future, it would introduce a new UI pattern on the staff web portal catalogue management surface.
7. Hygiene Subscriptions — subscription-aware product labelling — the "included in your subscription" indicator described in §5.2 and §6 requires confirmation of the data contract between Product Shop and Hygiene Subscriptions that would expose a patient's active subscription product list to the Product Shop recommendation surface. This cross-module data dependency must be agreed with the Hygiene Subscriptions module owner before these labels can be implemented.
8. (needs UX writer input — all body copy, microcopy, button labels, empty-state headlines, error messages, toast copy, notification subject lines, and confirmation modal copy across all surfaces)