Hygiene Subscriptions – UX Specification

Related Technical Authority: Hygiene Subscriptions – Technical Specification

1. Purpose

This UX specification governs the user-facing experience of the Hygiene Subscriptions module — the chair-side plan builder, patient enrolment flows, subscription lifecycle management, and related staff dashboards. It serves three primary roles: hygienists composing and presenting bespoke oral-care plans chair-side; reception staff and admins assisting with enrolment and managing exceptions; and patients completing enrolment, viewing their subscription, and managing cancellation via the mobile app. The spec establishes the interaction model, surface breakdown, and governance patterns that all design and build work must follow.

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.

Hygienist authorship is inviolable — the plan builder makes it structurally impossible for reception staff or admins to author or modify product selections; role boundaries are enforced in the UI, not just the backend, inferred from Technical Spec §4.1 and §9.

Price is always visible and current — the monthly total updates in real time as the hygienist adds or removes products, ensuring patients are never surprised by a price at the point of consent, inferred from Technical Spec §4.4.

Consent is a gate, not a checkbox — enrolment cannot proceed without the patient explicitly accepting terms and completing the Direct Debit mandate; the UI treats this as a mandatory multi-step gate, not an optional confirmation, inferred from Technical Spec §5.3 and §17.2 rule 3.

3. Design Philosophy

The mental model for this module is a clinical recommendation made permanent. The hygienist's chair-side advice has always ended at the appointment door; this module extends it into an ongoing, automatic supply relationship. The design should reinforce that framing: the plan builder is a clinical tool, not a shopping basket, inferred from Technical Spec §1.

Empty states should be purposeful and role-aware. A hygienist with no active plans yet should see an invitation to start a plan for the current patient. A reception dashboard with no pending enrolments should confirm that nothing requires follow-up, not leave an ambiguous blank screen, inferred from Technical Spec §11.1 and §11.4.

Error states must distinguish between recoverable and blocking conditions. A payment failure is recoverable; an unresolved escalated failure is blocking. An unavailable stock item requires a human decision. Each error state must surface the next action clearly, not just describe the problem, inferred from Technical Spec §6.3, §10.2.

AI surfaces are not present in this module's initial release. If introduced in a future release, they must be purely informational and visually distinct from hygienist-authored selections. The hygienist's product choices must never be pre-populated or silently modified by AI, inferred from Technical Spec §7.

Multi-step flows (plan builder, enrolment, cancellation) use a linear wizard model with clear progress indication. Each step is independently completable or saveable where the technical spec permits a deferred journey (e.g. Pending Enrolment state), inferred from Technical Spec §3.2 and §5.1.

Undo/redo is supported within the plan builder while the subscription is in Draft state; once submitted to Pending Enrolment, product selection is locked to authorised clinicians only. Edits after enrolment begins are not supported by the current technical spec and should not be implied by the UI, inferred from Technical Spec §3.2 and §9.

Read-only surfaces — a patient viewing their active subscription in the mobile app should clearly understand they are viewing a live plan, not a form. Staff viewing a subscription in a non-editable state must see an unambiguous read-only treatment, inferred from Technical Spec §11.3 and §9.

4. Primary Surfaces

4.1 Web Portal

Who uses it: Admins, hygienists, and reception staff accessing subscription management from a desktop or laptop in the practice back-office or at a workstation, inferred from Technical Spec §11.1.

Key tasks performed here:

• Reviewing and managing the full subscription dashboard across all patients and all states (Draft, Pending Enrolment, Active, Paused, Cancelling, Ended), inferred from Technical Spec §11.1 and §17.4.
• Tracking pending enrolments and identifying patients who have not yet completed their setup, inferred from Technical Spec §5.1 and §11.4.
• Reviewing fulfilment exceptions (unavailable stock, deferred orders) and taking action or escalating, inferred from Technical Spec §10.2.
• Viewing payment exception status and acting on escalated intervention tasks surfaced from Communication Hub, inferred from Technical Spec §6.3.
• Accessing subscription outcomes and analytics: active subscriber count, churn, revenue, fulfilment timeliness, and payment failure rates, inferred from Technical Spec §14.
• Exporting audit logs (admin role only), inferred from Technical Spec §9.
• Assisting with enrolment steps (non-product-authoring) when a patient is completing setup via the portal rather than the mobile app, inferred from Technical Spec §5.1 and §9.

Layout pattern: list-detail for the subscription dashboard (filterable list of subscriptions with detail pane); dashboard layout for the analytics and outcomes view, inferred from Technical Spec §11.1 and §14.

4.2 Tablet App

Who uses it: Hygienists and authorised clinicians in the surgery, composing plans chair-side during or immediately after a hygiene appointment, inferred from Technical Spec §11.2.

Key tasks performed here:

• Composing a bespoke subscription plan for the current patient, selecting products across all supported categories and setting per-item supply intervals, inferred from Technical Spec §4.2 and §4.3.
• Reviewing the real-time monthly price as items are added or removed, inferred from Technical Spec §4.4.
• Presenting the completed plan to the patient for review before enrolment, inferred from Technical Spec §4.4.
• Initiating the in-clinic enrolment flow, including presenting subscription terms and capturing patient e-signature and Direct Debit mandate setup, inferred from Technical Spec §5.1 and §5.3.
• Recording first-kit handed-out-in-clinic fulfilment to prevent duplicate shipment, inferred from Technical Spec §10.3.
• Saving a plan to Pending Enrolment state for the patient to complete later via the mobile app, inferred from Technical Spec §5.1 and §3.2.

Touch ergonomics: the plan builder must use glove-friendly tap targets (minimum 48 × 48 px for product selection controls, quantity steppers, and interval selectors). One-handed reach for the most common builder actions (add product, confirm step). The monthly price summary must remain anchored and visible while the hygienist scrolls through product categories, inferred from Technical Spec §4 and the tablet-primary use context of §11.2.

4.3 Mobile App (Patient)

Who uses it: Patients completing deferred enrolment outside the clinic, and active subscribers managing their subscription, inferred from Technical Spec §11.3.

Key tasks performed here:

• Completing a deferred enrolment — reviewing the saved plan, accepting terms, providing e-signature, and setting up the Direct Debit mandate via GoCardless, inferred from Technical Spec §5.1 and §5.3.
• Viewing the active subscription: products, supply intervals, next delivery date, and current monthly price, inferred from Technical Spec §11.3.
• Viewing upcoming and past deliveries with tracking information where available, inferred from Technical Spec §10.4.
• Receiving and acting on subscription lifecycle notifications: payment failures, shipping updates, enrolment reminders, and cancellation confirmations, inferred from Technical Spec §11.3 and §12.
• Requesting cancellation, with clear presentation of the effective end date, the remaining commitment period if applicable, and the final payment amount before confirmation, inferred from Technical Spec §6.2.

5. Interaction Model

5.1 Primary Flows

Flow 1 — Chair-side plan composition and in-clinic enrolment

Inferred from Technical Spec §4 and §5.1.

1. Hygienist opens the plan builder for the current patient on the tablet.
2. Hygienist selects products from supported categories; sets per-item supply interval for each line item.
3. Monthly price updates in real time with each change.
4. Hygienist reviews the completed plan and monthly total.
5. Hygienist presents the plan to the patient on the tablet (read-only patient-facing view).
6. If the patient wishes to enrol now: hygienist initiates the in-clinic enrolment flow.
7. a. Patient is presented with subscription terms.
8. b. Patient provides e-signature.
9. c. Direct Debit mandate is set up via GoCardless (patient enters banking details in the GoCardless-hosted flow).
10. d. Signed agreement is generated, sent to Document Hub, and linked to the patient record.
11. e. Subscription transitions to Active.
12. f. First fulfilment mode is confirmed (ship immediately or hand out in clinic).
13. If the patient wishes to enrol later: hygienist saves the plan to Pending Enrolment. Patient receives a mobile-app reminder to complete enrolment.

Flow 2 — Deferred enrolment via patient mobile app

Inferred from Technical Spec §5.1 and §3.2.

1. Patient receives a push notification reminding them to complete their saved plan.
2. Patient opens the mobile app and navigates to the pending subscription.
3. Patient reviews the saved plan details and monthly price.
4. Patient accepts subscription terms and provides e-signature.
5. Patient completes Direct Debit mandate setup via GoCardless-hosted flow.
6. Subscription transitions to Active; patient receives confirmation notification.

Flow 3 — Payment failure, pause, and resolution

Inferred from Technical Spec §6.3.

1. A Direct Debit payment fails; Integrated Payments notifies the module.
2. Subscription transitions to Paused; fulfilment is suspended immediately.
3. Patient receives a mobile-app notification of the payment failure.
4. A staff intervention task is created in Communication Hub.
5. GoCardless retries the payment per its retry rules.
6. If retry succeeds: subscription transitions back to Active; fulfilment resumes; patient is notified.
7. If all retries are exhausted: an escalated mandatory intervention task is created in Communication Hub and remains open until staff explicitly resolve it.
8. Staff action options: assist payment recovery, initiate a staff-led pause, or end the subscription.

Flow 4 — Patient-initiated cancellation

Inferred from Technical Spec §6.2.

1. Patient requests cancellation via the mobile app.
2. System evaluates whether the minimum 3-month commitment has been met.
3. If not met: cancellation is deferred to the end of the minimum term; patient is shown the earliest effective end date and the final payment amount.
4. If met: rolling one-month notice is applied; patient is shown the effective end date and the final payment amount.
5. Patient confirms the cancellation request.
6. Subscription transitions to Cancelling.
7. Final payment cycle completes; GoCardless mandate is cancelled.
8. Subscription transitions to Ended; patient's Primoro record is updated.

Flow 5 — Fulfilment order generation and shipping notification

Inferred from Technical Spec §10 and §10.4.

1. System evaluates each line item's NextDueDate on the fulfilment schedule.
2. For each item that is due: a fulfilment order is generated with patient name, delivery address, and supplier SKU.
3. Order is dispatched to the supplier.
4. When the order ships, the patient receives a mobile-app notification including tracking information where available.
5. Communication Hub records the shipment event.

5.2 State Machines (Mirror of Technical Spec § 3.2)

The following UI treatments are inferred from the state machine defined in Technical Spec §3.2.

• Draft
• Entry condition visible: plan builder is open and incomplete or unsaved; no pricing total is displayed until at least one line item is added.
• Visual treatment: (needs UX writer input — badge label and colour token for Draft state).
• No billing or fulfilment actions are available from this state; the only available transitions are to save as Pending Enrolment or to discard.

• Transition to Pending Enrolment requires hygienist or authorised clinician confirmation; a summary of the plan and price is shown before the transition is committed.

• Pending Enrolment

• Entry condition visible: plan is saved and a prompt to complete enrolment is shown to both staff (on the dashboard) and the patient (on the mobile app via notification).
• Visual treatment: (needs UX writer input — badge label and colour token for Pending Enrolment state).
• Staff dashboard shows time elapsed since the plan was saved and enrolment follow-up status.

• Product selection is locked; only authorised clinicians may modify.

• Active

• Entry condition visible: mandate confirmed indicator shown; billing schedule and next billing date displayed.
• Visual treatment: (needs UX writer input — badge label and colour token for Active state).

• Full subscription detail available to staff and patient; fulfilment schedule visible.

• Paused

• Entry condition visible: payment failure reason displayed; fulfilment suspended indicator shown; outstanding staff task referenced.
• Visual treatment: (needs UX writer input — badge label and colour token for Paused state; should communicate urgency without alarm for routine retries, and elevated urgency for escalated failures).
• No fulfilment actions are available while Paused; the only actionable path shown is payment resolution.

• Transition back to Active requires confirmed payment resolution and is audited.

• Cancelling

• Entry condition visible: effective end date and final payment amount shown; notice period countdown displayed to both staff and patient.
• Visual treatment: (needs UX writer input — badge label and colour token for Cancelling state).
• No new fulfilment orders beyond the notice period are generated; the UI should make this clear.

• Irreversible transition warning shown at the point of confirmation.

• Ended

• Entry condition visible: mandate cancellation confirmed; all payments settled.
• Visual treatment: (needs UX writer input — badge label and colour token for Ended state).
• Record is read-only; audit trail remains accessible to admin.
• Patient's Primoro record shows subscription status as Ended.

All state transitions are time-stamped and attributed to the acting user; the UI must surface the "last changed by" actor and timestamp in the subscription detail view for staff, inferred from Technical Spec §3.2 and §8.

MFA confirmation is required at the UI level before any action that creates or cancels a GoCardless mandate; the UX must present an explicit MFA step as part of those flows, inferred from Technical Spec §9 enriched note.

5.3 Empty / Loading / Error / Offline States

Plan builder (tablet)

• Empty state: (needs UX writer input — prompt copy inviting hygienist to add the first product for this patient) with category navigation visible immediately.
• Loading state: skeleton rows for product category lists; the monthly price area shows a neutral placeholder until the first item is added.
• Error state: if product catalogue fails to load, a blocking error with a retry action is shown; the builder must not allow a plan to be saved with stale or incomplete catalogue data.
• Offline state: the plan builder requires live catalogue data and real-time pricing; if connectivity is lost, the hygienist must be clearly informed that saving or submitting is not available until connection is restored. A read-only view of any in-progress draft saved locally may be shown, but submission is blocked, inferred from Technical Spec §4.4 and §17.2 rule 4.

Subscription dashboard (web portal)

• Empty state: (needs UX writer input — confirmation message that no subscriptions match the current filters, with a prompt to adjust filters or create a new plan).
• Loading state: skeleton list rows while subscription records are fetched.
• Error state: if the dashboard fails to load, an inline error with a retry action is shown; partial data must not be displayed without a clear stale-data indicator.
• Offline state: the dashboard is a read-only view in degraded connectivity; a banner indicates data may not be current and actions that write state (e.g. resolving a task) are disabled until connectivity is restored, inferred from general platform posture and audit-integrity requirements in Technical Spec §8.

Patient mobile app — subscription view

• Empty state (no active subscription): if the patient has no subscription, the section is hidden or shows a contextual prompt if a Pending Enrolment plan exists for them. (needs UX writer input — copy for the pending enrolment nudge card).
• Loading state: skeleton card for subscription summary and delivery list.
• Error state: if subscription data cannot be fetched, a friendly error with a retry action is shown; cancellation and other write actions are disabled.
• Offline state: the patient's last-loaded subscription summary may be shown in a clearly-labelled read-only cached state; cancellation requests require connectivity and must be blocked with an explanatory message, inferred from Technical Spec §6.2 and §11.3.

6. Component Inventory

New components introduced or extended by this module:

• Plan builder panel — multi-step, scrollable product selection interface for hygienists; contains category tabs, product cards with quantity and interval controls, and an anchored monthly price summary footer. Appears on tablet (primary) and web portal. Inferred from Technical Spec §4.
• Monthly price ticker — real-time computed monthly total, anchored to the plan builder footer; updates within 500 ms of any line item change. Inferred from Technical Spec §4.4 and §18.
• Subscription state badge — a labelled status indicator displayed on subscription list rows and detail views; one of six states (Draft, Pending Enrolment, Active, Paused, Cancelling, Ended). Inferred from Technical Spec §3.2.
• Enrolment wizard — linear multi-step flow for consent presentation, e-signature capture, and GoCardless mandate setup; used on both tablet (in-clinic) and mobile app (deferred). Inferred from Technical Spec §5.3.
• Subscription detail card — read-only summary of a patient's active subscription including products, intervals, next delivery, and monthly price; shown on the patient mobile app and in staff detail pane. Inferred from Technical Spec §11.3.
• Fulfilment exception card — staff-facing component surfacing a stock unavailability or deferred order exception; contains the affected line item, reason, and an action trigger. Appears on web portal. Inferred from Technical Spec §10.2.
• Payment failure alert row — inline alert within the subscription detail view indicating the failure state, retry status, and escalation level; links to the Communication Hub intervention task. Appears on web portal and tablet. Inferred from Technical Spec §6.3.
• Cancellation confirmation modal — presents effective end date, notice period remaining, minimum commitment status, and final payment amount before the patient or staff confirms cancellation. Inferred from Technical Spec §6.2.
• Pending enrolment follow-up row — staff dashboard row showing a saved plan in Pending Enrolment state with elapsed time since saving and a follow-up action. Appears on web portal. Inferred from Technical Spec §5.1 and §11.4.
• Eligibility gate block — displayed when a patient does not meet configured eligibility criteria; shows a human-readable reason and does not allow enrolment to proceed. Inferred from Technical Spec §5.2 and §17.2 rule 13.

Reused from the design system:

• Form field with programmatic label (used throughout enrolment wizard)
• Filter bar with multi-select (used on subscription dashboard)
• Toast notification (used for save confirmations and plan submission feedback)
• Skeleton loader (used across all data-loading surfaces)
• Confirmation modal (base pattern; extended by cancellation confirmation modal)
• Audit trail timeline (used in subscription detail view to surface state transition history)

7. Visual Design Notes

• Typography: (needs UX writer input — heading scale, body scale, and monospace usage to be defined by design system application).
• Colour: semantic colour usage must clearly differentiate the six subscription states; Paused and escalated-failure states require distinct visual weight to signal urgency without defaulting to alarm-red for routine retries. Specific colour tokens to be defined by the design system; no hex values are specified here, inferred from Technical Spec §6.3 and the calm-by-default principle.
• Iconography: icon set, sizing, and labelling to follow platform design system; icons must never appear without a visible label or accessible text equivalent.
• Motion: transitions within the plan builder (adding/removing a line item, price update) should be subtle and non-distracting; the price ticker update must not use motion that draws the eye away from the product selection task. All motion must respect prefers-reduced-motion. No motion should be used on state badges or alert rows — static visual changes only, inferred from the calm-by-default principle and §18 performance requirements.

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 / VoiceOver / TalkBack

The plan builder's quantity steppers and interval selectors on the tablet must meet the 44 × 44 px minimum and additionally target 48 × 48 px for glove-friendly use in the clinical environment, inferred from Technical Spec §11.2 and the tablet touch-ergonomics requirement.

The enrolment wizard's e-signature capture step must be accessible to patients using assistive technology; a keyboard-accessible alternative to a freehand signature must be evaluated during design, inferred from Technical Spec §5.3 and WCAG 2.2 AA obligations.

The monthly price summary displayed to the patient before enrolment must be unambiguously readable at the font size used in the patient-facing view; this is a financial commitment surface and clarity is non-negotiable, inferred from Technical Spec §4.4.

Error and eligibility-gate block messages must be programmatically associated with their context using ARIA aria-describedby or equivalent so that screen reader users receive the reason inline, inferred from Technical Spec §5.2 and §17.2 rule 13.

9. Internationalisation

• Locale-aware date/time/number formatting
• All user-facing strings externalised
• Layouts tolerant of 30% string-length growth (German, French)
• RTL support: not required at this tier (to be revisited if the platform expands to RTL markets)

Currency formatting must respect the locale of the practice; all monthly price displays must use the locale-correct currency symbol and decimal/thousands separator, inferred from Technical Spec §4.4 and the platform's multi-tenant, multi-site posture in §18.

Subscription terms presented to patients at enrolment must be rendered in the locale/language configured for the practice; the module emits the terms to the patient-facing surface but does not own the content of the terms document itself, inferred from Technical Spec §5.3.

10. Cross-Module UX Touchpoints

Where this module's UX intersects with related modules:

• Integrated Payments — staff managing a subscription in Paused state (payment failure) will navigate to Integrated Payments to view the payment status dashboard and exception banners for that subscription. The handoff from the Hygiene Subscriptions detail view to Integrated Payments must be a clear, labelled navigation action; staff should not need to re-search for the patient. On return, the subscription status should reflect any resolved payment state. Inferred from Technical Spec §6.4 and §12.
• Communication Hub — all patient and staff notifications related to subscription lifecycle events originate from this module but are delivered via Communication Hub. Staff intervention tasks (payment failure, fulfilment exception) are surfaced in Communication Hub and must be reachable from the Hygiene Subscriptions dashboard via a direct link to the relevant task. Closing a task in Communication Hub must be reflected in the subscription's exception status. Inferred from Technical Spec §6.3 and §12.2.
• Document Hub — once enrolment is complete, the signed subscription agreement is stored in Document Hub and linked to the patient record. Staff accessing the subscription detail view must be able to navigate to the stored agreement in Document Hub from within the module; this is a read-only outbound link. Inferred from Technical Spec §5.3 and §12.2.
• Access Manager — role and permission context is consumed silently; the UI must reflect the current user's role by showing or hiding authoring controls (e.g. product selection in the plan builder is only rendered for hygienists and authorised clinicians). No explicit Access Manager navigation touchpoint is required for the typical user journey. Inferred from Technical Spec §9 and §12.1.
• Admin Control Plane — admins configure the product catalogue, pricing rules, eligibility gate, billing day, and supplier SKU mappings via the Admin Control Plane. These configuration screens are not part of the Hygiene Subscriptions module UX; however, misconfiguration (e.g. empty catalogue, disabled eligibility gate) must surface informative errors in the plan builder, not silent failures. Inferred from Technical Spec §17.3 and §12.1.
• Audit & Compliance — admins exporting audit logs from the subscription detail view are handed off to the Audit & Compliance module's export surface. The trigger is a clearly-labelled "Export audit log" action visible only to admin-role users in the subscription detail view. Inferred from Technical Spec §9 and §12.2.

UX consistency rules:

• The subscription state badge must use the same visual language (shape, position, label style) as status badges in other Primoro modules to support staff cross-module literacy, inferred from the suite-level design system expectation.
• Staff intervention task links from this module into Communication Hub must open in context (i.e. directly to the relevant task), not to the Communication Hub home screen, inferred from the action-first principle and Technical Spec §6.3.
• Navigation back from Document Hub or Integrated Payments to the originating subscription record must be supported; deeplinks to subscription detail views are required, inferred from the multi-module handoff pattern.

11. Governance & Auditability

The subscription detail view (staff-facing, web portal and tablet) must display an audit trail section showing all state transitions with timestamp and acting user identity, inferred from Technical Spec §8 and §3.2.

AI surfaces are not present in this module's initial release. If AI suggestion features are introduced in a future release, they must be visually distinct from hygienist-authored selections (e.g. a clearly labelled suggestion chip that requires explicit hygienist adoption), and must never appear as pre-populated fields, inferred from Technical Spec §7.

The plan builder must make the hygienist's authorship role visible — the plan is attributed to the creating hygienist and that attribution is shown to both staff and the patient at the point of enrolment, inferred from Technical Spec §3.1 field CreatedBy and §4.1.

Audit-significant actions — transitioning to Pending Enrolment, completing enrolment, pausing, cancelling, resolving a payment failure — each require a confirmation step that states what will happen and is not dismissible by accident. Irreversible transitions (e.g. confirming cancellation once past the minimum term) must carry an explicit irreversibility warning, inferred from Technical Spec §6.2, §17.2.

MFA-gated actions (mandate creation and mandate cancellation) must present the MFA step as a clearly-labelled security checkpoint within the flow, not as an opaque system error if the factor is not yet satisfied, inferred from Technical Spec §9.

Read-only subscription records (e.g. Ended state, or a record viewed by reception staff who cannot edit) must carry an unambiguous read-only indicator so users do not attempt edits that will silently fail, inferred from Technical Spec §3.2 and §9.

The eligibility gate block shown to staff must include the specific reason the patient does not meet the configured criteria; a generic "not eligible" message is not sufficient, inferred from Technical Spec §5.2 and §17.2 rule 13.

12. Notification & Communication Patterns

This module does not send notifications directly. All patient and staff communications are emitted as events to Communication Hub, which owns delivery. The following patterns are used, inferred from Technical Spec §6, §10.4, §12.2, and §5.1:

• Push notification (via Communication Hub):
• Deferred enrolment reminder — sent to patient when a plan is saved in Pending Enrolment state, prompting completion via the mobile app.
• Payment failure alert — sent to patient when a Direct Debit payment fails.
• Shipping notification — sent to patient when an order ships, including tracking information where available.

• Cancellation confirmation — sent to patient when a cancellation is confirmed, including effective end date and final payment amount.

• Email / SMS fallback (via Communication Hub):

• Applied per Communication Hub's fallback policy when push notification cannot be delivered (e.g. app not installed, notifications disabled). Covers payment failure alerts and shipping notifications as a minimum.

• In-app banner (web portal and tablet):

• Pending enrolment count indicator — shown on the staff subscription dashboard when one or more plans are awaiting patient completion, inferred from Technical Spec §11.4 engagement signals.
• Fulfilment exception banner — shown when one or more active subscriptions have an outstanding stock or fulfilment exception requiring staff action, inferred from Technical Spec §10.2 and §11.4.

• Escalated payment failure banner — shown when one or more subscriptions have an unresolved escalated intervention task, inferred from Technical Spec §6.3.

• Toast:

• Confirmation of plan saved to Pending Enrolment state, inferred from Technical Spec §5.1.
• Confirmation of in-clinic first-kit handout recorded, inferred from Technical Spec §10.3.

• Confirmation of audit log export initiated, inferred from Technical Spec §9.

• Staff intervention task (surfaced via Communication Hub):

• Created on initial payment failure; escalated to mandatory open task on exhausted GoCardless retries; created on stock unavailability exception. These are not in-app notifications within this module — they are tasks in Communication Hub, linked from the subscription detail view, inferred from Technical Spec §6.3 and §10.2.

Service communications (enrolment confirmation, payment notices, shipping updates, cancellation confirmations) are sent regardless of patient marketing opt-in status. Marketing or promotional communications require explicit patient consent managed separately via Communication Hub, inferred from Technical Spec §8.

13. Open Questions

The following UX decisions must be resolved before this spec is promoted from draft to published.

1. Billing day display to patient — if the billing day is configured per-patient (aligned to first payment date) rather than practice-wide, the patient-facing subscription view must show their specific billing date. It is unresolved at the technical spec level which billing day mode is supported at launch (Technical Spec open question 1); the UX design for billing day display depends on this resolution.

2. Deferred enrolment reminder cadence and expiry — the reminder notification pattern requires a defined schedule (e.g. day 1, day 3, day 7 after plan save) and a maximum reminder count before a plan is considered abandoned and archived. These are undefined in the technical spec (Technical Spec open question 2); the notification design cannot be finalised until the business rules are agreed.

3. Eligibility gate — staff-facing criteria display — the plan builder must show a human-readable eligibility block when a patient does not qualify. The full set of configurable eligibility criteria is not yet defined (Technical Spec open question 3); the component design must be flexible enough to render any configured reason string without layout assumptions about its length or structure.

4. Substitution approval UX — when a stock exception is raised for an existing subscriber, the staff-facing exception card must support either an "approve substitution" action or a "review and ship" action depending on whether auto-substitution is configured. The approval workflow model is unresolved (Technical Spec open question 4); the exception card design should accommodate both models as variants pending resolution.

5. Staff-initiated cancellation — it is unresolved whether staff may initiate cancellation on behalf of a patient via the web portal. If this is supported, the cancellation confirmation modal will require an additional audit and consent step beyond the patient self-service flow (Technical Spec open question 5); the modal design should not assume a single actor model until this is resolved.

6. (Carries forward from Technical Spec open question 6) PMS status flagging discrepancy — the acceptance criteria in the technical spec reference PMS status flagging, which contradicts the explicit prohibition on PMS write-back in §8.1. Until this contradiction is resolved, no PMS-related UI element should be designed for or implied by this module.

7. In-clinic enrolment device handover UX — during the in-clinic enrolment flow on the tablet, there is a point at which the device transitions from the hygienist's use (plan presentation) to the patient's use (terms review, e-signature, Direct Debit setup). The handover moment — including any privacy screen, device orientation guidance, or mode switch — requires explicit UX design that is not addressed in the technical spec. (needs UX writer input — handover interaction pattern and any supporting copy).

8. (needs UX writer input — all badge labels, state names as shown to patients vs staff, button labels in the plan builder, confirmation modal copy, eligibility block reason copy, and cancellation confirmation microcopy across all surfaces.)