← Appointment Manager
Appointment Manager
Editing ux
v0.2 — draft
📝 1 past meeting
Save draft
Promote to published
✕ Discard draft
Tab to switch the tab. Save writes a vNEW-DRAFT.md alongside the published file.
Markdown source
# Appointment Manager – UX Specification Related Technical Authority: Appointment Manager – Technical Specification --- ## 1. Purpose This UX specification governs the user experience of the Appointment Manager module across all surfaces on which it appears: the staff web portal, the in-practice tablet app, and the patient-facing mobile app. It defines interaction models, state representations, cross-module handoffs, and governance visibility for the complete appointment lifecycle — from availability discovery and booking through arrival, completion, and cancellation, including the Digital Waitlist and practitioner absence–driven rescheduling workflows. The primary roles served are reception staff, practice managers, clinical staff, and patients engaging via self-booking. --- ## 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. - **Constraints are visible and explainable** — when a booking cannot be made, the system must always say why; silent empty states are prohibited. Inferred from technical spec §4.3 and §22.2 rule 3. - **Automation is always observable** — no silent state changes from the Digital Waitlist or Reschedule Job workflows; staff can see what the system did and why. Inferred from technical spec §7.4, §8.3, and §18. - **AI is advisory, never authoritative** — AI suggestions are visually distinct, labelled, and require explicit human confirmation before any booking action proceeds. Inferred from technical spec §10. - **Context is never ejected** — switching diary views, lenses, or opening Find Next preserves date, filter, and selection state. Inferred from technical spec §5.1 and §6. - **Terminal states are irreversible** — appointments in `completed`, `no-show`, or `cancelled` states must be visually and interactively distinct from states that can still be acted upon. Inferred from technical spec §3.2. --- ## 3. Design Philosophy The Appointment Manager's mental model is that of a **governed scheduling engine**, not a free-form diary. Every slot shown to a user is a confirmed, constraint-validated availability; the interface never implies that booking is possible where it is not. Inferred from technical spec §1 and §4.1. **Empty states:** When no availability exists, the system must explain the specific reason — booking window limit, zone exhaustion, break segment, practitioner ineligibility, or accessibility constraint. "No slots available" without context is not a valid empty state. Inferred from technical spec §4.3. *(Exact empty-state messaging needs UX writer input.)* **Error states:** Constraint violations (e.g. attempting to book against a break segment, a rejected state transition, or a failed care plan entitlement check) must surface as explicit, actionable errors that name the violated rule. Generic error messages are insufficient. Inferred from technical spec §22.2.* **AI suggestions:** AI output (from AI Concierge recovery flows or any advisory layer) must be visually distinct from user-initiated or system-confirmed actions — for example, via a clearly labelled badge or border treatment. Each suggestion must be accompanied by a plain-language explanation. Whether a suggestion was accepted or rejected must be logged and visible in the audit trail. Inferred from technical spec §10 and §17. **Multi-step flows:** Booking, rescheduling, and waitlist confirmation are multi-step flows that must preserve constraint context at every step. Users must never arrive at a confirmation step without having seen the constraints that apply. Inferred from technical spec §6 and §7.3. **Undo/redo:** Terminal state transitions (`completed`, `no-show`, `cancelled`) are irreversible by system rule. The UI must make this clear at the point of confirmation — a reversible-feeling control (e.g. a plain toggle) must not be used for these transitions. Inferred from technical spec §3.2. *(Exact confirmation modal pattern and copy need UX writer input.)* **Read-only vs editable surfaces:** The Offer Monitor and Reschedule Job Monitor are observational, not control surfaces, except where proportionate manual takeover is explicitly permitted per patient. Read-only surfaces must be visually distinct from editable ones. The today-only operational feed consumed by Surgery & Decon Day View is entirely read-only. Inferred from technical spec §7.4, §8.3, and §14. **Month view:** Month view is decision-support only and carries no booking affordances. This must be communicated clearly in the view itself — clickable elements should only drill down to Day View. Inferred from technical spec §5.1. --- ## 4. Primary Surfaces ### 4.1 Web Portal **Who uses it:** Reception staff, practice managers, clinical staff (role-gated per Access Manager RBAC). **Key tasks performed here:** - View and navigate the appointment diary in Day, Week, and Month views, using either the practitioner-first or surgery-first lens. Inferred from technical spec §5.1. - Create, reschedule, and cancel appointments, subject to RBAC role. Inferred from technical spec §9. - Use Find Next to discover and book governed availability for a patient, with explicit confirmation before any booking is made. Inferred from technical spec §6. - Monitor Digital Waitlist automation state via the Offer Monitor. Inferred from technical spec §7.4. - Monitor and, where permitted, manually take over individual patients within a Reschedule Job via the Reschedule Job Monitor. Inferred from technical spec §8.3. - Configure appointment types, deposit policies, and waitlist broadcast eligibility rules (practice manager / admin role only). Inferred from technical spec §22.3. - View the audit trail for appointments, waitlist offers, and reschedule jobs. Inferred from technical spec §17. **Layout pattern:** The primary diary view uses a **grid-based calendar layout** (time × practitioner or time × surgery). Find Next operates as a **persistent modal overlay** with a multi-pane structure (constraints / results / diary preview). The Offer Monitor and Reschedule Job Monitor use **list-detail** layouts. Configuration surfaces use **form / wizard** patterns. Inferred from technical spec §5.1, §6, §7.4, and §8.3. **Diary lens toggle:** A single toggle switches between practitioner-first (default) and surgery-first views. Lens changes re-render the same underlying data and must not reset date, filter, or selection state, and must not trigger availability recomputation. Inferred from technical spec §5.1. **View switching:** Day, Week, and Month views share date and filter state. Switching views is a zoom gesture, not navigation. Inferred from technical spec §5.1. **Real-time current-time indicator:** In Day View only, a continuous "now" line renders across the full diary grid, updating without full diary re-render. It is presentational only and must not function as a workflow trigger. The active appointment (if any is intersected) may be visually emphasised. Elapsed vs upcoming time may be differentiated via presentation state. Inferred from technical spec §5.4. **Rota availability vs booking constraints:** The diary and Find Next surfaces must make the distinction between rota-derived availability (when a practitioner or surgery is scheduled to work, as generated by Rota Manager) and bookability (whether a slot passes all Appointment Manager constraints) legible to users. Slots that exist in the rota but are blocked by a booking constraint (zone exhaustion, booking window limit, break segment, accessibility requirement) must be visually distinguished from slots that are genuinely open for booking. Staff must never be left to infer which authority is responsible for a slot being unavailable. Where a slot is constrained by rota data, the explanation must attribute this to rota availability; where it is constrained by booking rules, the explanation must name the booking rule. Inferred from Rota Manager UX principle on separation of authority and technical spec §4.1 and §4.3. --- <!-- From meeting --> **Huddle Box (Diary Day View — top panel)** The Huddle Box is a persistent panel fixed at the top of the Day View diary screen. It is designed to replace the practice of placing informal sticky-note annotations directly on the diary column (a pattern observed in tools such as Dentally), which is messy and inconsistent with the governed diary model. Behaviour: - Staff may add freeform notes to the Huddle Box at any time during the day. Notes do not require a linked appointment. - A note MAY be optionally linked to a specific appointment on that day's diary. Linking is optional. - When a user clicks a note that has a linked appointment, the diary scrolls to and visually highlights the linked appointment (a 'flash' or emphasis treatment). - The Huddle Box acts as the practice's daily checklist and focus list — a structured home for things the team needs to remember on that day (e.g. "Patient X needs ground-floor surgery", "Nurse Y is off today"). - Notes are scoped to the practice day and are not carried forward automatically. The Huddle Box is intended to support the morning 'huddle' workflow where the practice team reviews priorities for the day before sessions begin. *(Exact panel heading, note-entry placeholder copy, link-appointment control label, and highlight animation treatment need UX writer and design system input.)* ### 4.2 Tablet App **Who uses it:** Clinical staff and reception staff in-practice, operating under the same RBAC constraints as the web portal. Inferred from technical spec §5.2. **Key tasks performed here:** - View today's appointments for the assigned practitioner or surgery context. Inferred from technical spec §5.2 and §14. - Update appointment lifecycle state: mark a patient as arrived, complete an appointment, or record a no-show. Inferred from technical spec §5.2. - Look up appointment detail for a specific patient on the day. Inferred from technical spec §5.2. **Touch ergonomics:** Touch targets ≥44×44 px on mobile/tablet. One-handed reach considered for primary lifecycle action controls. Glove-friendly tap targets where clinical context requires. **Session interruption (Access Manager):** The tablet surface is subject to Access Manager–driven session lifecycle events: forced logout on role suspension or revocation, role scope updates, and idle timeout. When one of these events occurs mid-workflow, the tablet must: (a) immediately disable all booking and state-transition actions; (b) display a clearly labelled session-interrupted state explaining that the session has ended and re-authentication is required; (c) preserve read-only appointment data on screen where possible so that clinical context is not lost on re-login. An in-progress state transition (e.g. a tap on "Mark arrived" mid-flight) that has not yet been committed must be treated as abandoned and must not be silently applied. Staff must re-authenticate and repeat the action. Inferred from Access Manager §4.2 and §4.3. *(Detailed in-context task flows for the tablet surface need UX writer input — particularly the arrival and departure confirmation patterns.)* --- ### 4.3 Mobile App (Patient) **Who uses it:** Patients initiating or managing their own appointments via patient self-booking. Inferred from technical spec §5.3. **Key tasks performed here:** - Browse available appointment slots, subject to governed availability (booking window, practitioner eligibility, zone, accessibility needs, care plan entitlement). Inferred from technical spec §5.3 and §4.3. - Book an appointment, including completing any required deposit payment step before confirmation is finalised. Inferred from technical spec §5.3 and §12. - View upcoming appointments. Inferred from technical spec §5.3. - Cancel an appointment within the configured policy window. Inferred from technical spec §5.3. - Receive and act on a Digital Waitlist offer — including engaging with a slot offer, completing booking, and understanding the engagement lock window and its expiry. Inferred from technical spec §7.2 and §7.3. - Receive and respond to AI Concierge–presented recovery options following a short-notice cancellation, with any resulting booking routed through the standard governed flow. Inferred from technical spec §10.1. *(Patient-facing copy, onboarding, and empty states throughout the mobile app need UX writer input.)* --- ## 5. Interaction Model ### 5.1 Primary Flows --- **Flow 1: Staff-initiated appointment booking via Find Next** Inferred from technical spec §6, §4.3, §9, and §12. ``` Start: Staff opens Find Next from diary or patient record │ ├─ Enter constraints (patient, appointment type, practitioner preference, date range) │ ├─ [BookingEligibility gate] System checks Treatment Pipeline BookingEligibility status │ └─ If eligibility is false → booking action is blocked; explicit reason displayed; │ staff may view eligibility detail but may not override the gate │ ├─ System returns ranked governed availability results │ └─ If no results → system explains why (booking window / zone / practitioner / accessibility) │ ├─ Staff selects a slot │ └─ Diary preview renders inline — context preserved │ ├─ Staff confirms booking │ ├─ Care plan entitlement check runs; result shown before confirmation proceeds │ ├─ If deposit policy applies → DepositCollectionEvent emitted to Integrated Payments │ └─ Appointment state transitions: created → confirmed │ └─ End: Appointment confirmed; audit trail written; task trigger event emitted if configured ``` --- **Flow 2: Patient self-booking (mobile app)** Inferred from technical spec §5.3, §4.3, §12, and §3.2. ``` Start: Patient opens self-booking surface in mobile app │ ├─ [Delegated context check] If acting as guardian for a dependant via Family Profiles, │ a persistent banner identifies the dependant being booked for throughout the flow; │ all booking actions are labelled as delegated (see §5.1 Delegated booking note below) │ ├─ [Recall context check] If entry point is a recall deep-link from Recall & Reconnect, │ appointment type and recall reason are pre-populated from the recall context; │ patient must confirm or adjust before proceeding (see §5.1 Recall context note below) │ ├─ Select appointment type │ ├─ [BookingEligibility gate] System checks Treatment Pipeline BookingEligibility status │ └─ If eligibility is false → patient sees a plain-language explanation that booking │ is not currently available and is directed to contact the practice │ ├─ System returns governed available slots │ └─ If no slots → system explains why; offers Digital Waitlist enrolment if applicable │ ├─ Patient selects a slot │ ├─ Care plan entitlement validated; deposit requirement shown if applicable │ ├─ If deposit required → patient completes deposit payment step │ ├─ Patient confirms booking │ └─ Appointment state transitions: created → confirmed │ └─ End: Confirmation displayed; Communication Hub notified via event ``` --- **Flow 3: Digital Waitlist – offer lifecycle (staff view and patient view)** Inferred from technical spec §7.2, §7.3, §7.4. ``` Trigger: Appointment cancelled → slot enters waitlist pool │ ├─ [Staff] Offer Monitor shows: offer broadcast to eligible patients │ ├─ [Patient] Waitlist offer delivered (via Communication Hub) │ ├─ Patient engages with offer │ └─ Engagement lock applied; lock expiry timer visible to patient │ ├─ [Staff] Offer Monitor updates: engaged_locked state, lock expiry shown │ ├─ Patient completes booking (and deposit if required) within lock window │ └─ Offer state: confirmed; slot closed │ OR │ Patient does not complete within lock window │ └─ Offer state: expired; slot returns to pool; Offer Monitor updates │ └─ End: Outcome (confirmed / expired) visible in Offer Monitor; audit trail written ``` --- **Flow 4: Practitioner absence–driven rescheduling** Inferred from technical spec §8.2, §8.3, §3.2, and §3.3. ``` Trigger: Rota Manager confirms practitioner absence affecting booked appointments │ ├─ Appointment Manager creates Reschedule Job │ ├─ [Staff] Reschedule Job Monitor shows: job-level progress + per-patient status │ ├─ Automation handles each affected patient independently │ └─ Per-patient status updates in real time │ ├─ Staff may invoke manual takeover per patient │ └─ Automation paused for that patient only; other patients unaffected │ └─ Manual takeover state visible in Reschedule Job Monitor │ └─ End: All patients resolved (automated or manual); audit trail written ``` --- **Flow 5: AI Concierge short-notice cancellation recovery (patient)** Inferred from technical spec §10.1. ``` Trigger: Appointment cancelled within short-notice window │ ├─ RotaCancellationEvent emitted to AI Concierge │ ├─ [Patient] AI Concierge presents recovery options (advisory; clearly labelled as AI suggestion) │ ├─ Patient selects a recovery slot │ ├─ Booking routed through standard Appointment Manager governed booking flow │ └─ All constraints apply (booking window, practitioner eligibility, zone, deposit, care plan) │ └─ Original appointmentId referenced in replacement booking's audit record │ └─ End: Replacement booking confirmed; audit trail links original and replacement ``` --- **Flow 6: Digital Forms gate within appointment workflow** Inferred from Digital Forms spec §3 and §5.2. Forms may be assigned to appointments as mandatory pre- or post-appointment checkpoints. Where a mandatory form has not been completed by the patient, the following gates apply: ``` Appointment workflow stage where form is due: │ ├─ Pre-appointment (e.g. medical history, consent form) │ └─ Appointment tile carries a visible outstanding-forms indicator │ └─ Staff are notified at check-in (arrived transition) if mandatory forms remain incomplete │ └─ Clinical decision to proceed is recorded; form completion is not automatically enforced │ as a hard block on arrived transition, but the outstanding status must be visible │ ├─ Post-appointment / Surgery Tablet completion gate │ └─ If a mandatory form is flagged as required before the appointment can be marked complete, │ the "Finish & Send" / complete action on the Surgery Tablet is blocked until the form │ milestone is satisfied │ └─ Block state is explicit: the completion control is disabled with a labelled explanation │ naming the outstanding form; it is not hidden │ └─ Staff may navigate to the Digital Forms surface from the appointment detail to resolve │ the outstanding form before returning to complete the appointment │ └─ Form completion unblocks the gate; appointment can then be marked completed normally ``` The appointment tile and detail view must always reflect the current form-completion status for assigned forms. Form assignment and content are owned by Digital Forms; Appointment Manager surfaces the completion state only and does not render form content inline. --- **Delegated booking note (Family Profiles):** When a patient in the mobile app is acting as a guardian booking on behalf of a linked dependant, the entire booking flow (slot selection, deposit payment, confirmation, cancellation, rescheduling) must operate in delegated context. A persistent, non-dismissible banner identifying the dependant by name must appear at the top of every screen in the flow. All confirmation steps must clearly state the name of the dependant being booked for, not the guardian's name. Actions taken in delegated context are attributed to the guardian in the audit trail, with the dependant identified as the appointment subject. The profile switcher (as defined in Family Profiles UX) gates entry to the delegated context; once inside a booking flow, the context must not be switchable mid-flow. Inferred from Family Profiles UX §4.3 and delegated-context principles. **Recall context deep-link note (Recall & Reconnect):** When the patient mobile app booking flow is entered via a deep-link from a Recall & Reconnect outreach message, the appointment type and recall reason passed in the deep-link context must be pre-populated in the booking flow. The patient must be able to see that these values have been pre-filled and where they originated (a labelled "from your recall invitation" indicator is recommended). The patient may adjust the appointment type if the practice permits; the recall reason is read-only context. If the recall context is malformed or has expired, the flow must degrade gracefully to a standard booking flow with a plain-language explanation. The recall context reference must be carried through to the audit trail entry for the resulting booking. Inferred from Recall & Reconnect UX §4.3 and integration contract §10.2. **Smart Dashboards inline actions note:** FOH staff may perform appointment lifecycle actions (confirm arrival, cancel) directly from Smart Dashboards cards without navigating to the full Appointment Manager diary view. These inline actions are governed by the same RBAC controls, confirmation steps, and audit-trail requirements as the equivalent actions performed within the Appointment Manager itself. Appointment Manager's state machine is the authority; Smart Dashboards actions are routed through the same lifecycle transition API. From the Appointment Manager's perspective, these transitions are indistinguishable from portal-originated transitions except for the `booking_source` field in the audit record (which reflects `dashboard`). When a user navigates from a Smart Dashboards card to the full appointment record in Appointment Manager, context (patient, appointment) must be preserved — the diary must open at the correct date and appointment without requiring re-navigation. Inferred from Smart Dashboards §4.1 and §4.4 and technical spec §15. **Payment drawer concurrency note (Integrated Payments):** The Integrated Payments payment drawer may be opened from an appointment context (e.g. from the appointment detail panel or from a dashboard card). When the payment drawer is open and associated with an appointment record, appointment state-transition actions (arrived, completed, no-show, cancelled) remain available — the payment drawer does not lock the appointment for editing. However, if a deposit payment is in progress (i.e. the deposit flow has been initiated but not yet confirmed), the appointment booking confirmation step must not be presented as complete until the deposit outcome is received from Integrated Payments. The appointment detail view must display the current payment status (deposit collected / care plan covered / outstanding / £0) as a read-only field; this field is owned by Integrated Payments and is not editable from within Appointment Manager. Inferred from Integrated Payments spec §3 and §4.1. **Aftercare handoff note:** When an appointment is transitioned to `completed`, Appointment Manager emits a completion event that Aftercare Manager consumes to trigger aftercare instruction issuance. No UX affordance for selecting or previewing aftercare templates is required within Appointment Manager itself — template selection and content are owned by Aftercare Manager. However, if the practice has configured aftercare template mapping for the appointment type, the appointment completion confirmation step should include a brief, read-only indicator that aftercare instructions will be issued automatically (e.g. "Aftercare instructions will be sent to the patient via Aftercare Manager"). This is informational only and does not gate the completion action. Inferred from Aftercare Manager technical spec §4.1. **Lab linkage note (Lab Manager):** Where an appointment has an associated Lab Case (surfaced via the `LabRequired` flag and `LabCaseReference`), these fields must appear in the appointment detail view as read-only fields. They are not editable from within Appointment Manager. On the Surgery Tablet view, the `LabRequired` flag must be clearly visible in the appointment header so that clinical staff are aware of the lab dependency before beginning the appointment. If the linked appointment's state changes to `cancelled` or `no-show`, this is relevant context that may affect Lab Manager workflows; the appointment detail view should surface a visible advisory note indicating that a linked lab case exists and may require attention. The exact copy and escalation path for this advisory note are subject to UX writer input. Inferred from Lab Manager §4.1 and §4.2 and technical spec §13. **Smart Treatment Proposals (STP) completion decoupling:** The appointment completion action (`completed` state transition) must not be blocked by the status of any associated Smart Treatment Proposal. STP follows a two-step model (clinician acknowledges in-chair; patient formally accepts during follow-up), and the patient's formal acceptance of a proposal may occur after the appointment has ended. Appointment Manager must not gate the `completed` transition on proposal acceptance status. Conversely, Appointment Manager must not trigger or force a proposal state transition as a side-effect of marking an appointment complete. The completed appointment state and the proposal state are independent; each follows its own lifecycle. Inferred from Smart Treatment Proposals §4.2 and §7. **Product Shop handoff note:** On the tablet surface, following an appointment being marked `completed`, the clinical staff member may be offered a prompt to enter the Product Shop recommendation flow for the patient (e.g. "Review product recommendations for this patient"). This entry point is a post-completion affordance — it must appear after the completion transition is confirmed, not before or during it. The prompt must be dismissible and must not obstruct the workflow if not required. The product recommendation flow itself is owned by Product Shop; Appointment Manager surfaces the entry point only. Inferred from Product Shop UX §4.2. **Hygiene subscription enrolment note:** On the tablet surface, where the completed appointment is of a hygiene-relevant type, the clinical staff member may be offered a prompt to enter the Hygiene Subscriptions plan-builder flow for the patient following appointment completion. When this entry point is used, the appointment context (patient identity, appointment date, appointment type) must be passed to the plan-builder so that it does not need to be re-entered. The subscription enrolment flow is owned by Hygiene Subscriptions; Appointment Manager surfaces the entry point and passes context only. This prompt must be dismissible and must not gate the completion action. Inferred from Hygiene Subscriptions §4.2. --- ### 5.2 State Machines (Mirror of Technical Spec §3.2) The following maps each appointment lifecycle state to its required UI treatment. Inferred from technical spec §3.2. | State | Entry condition visible before transition | Confirmation pattern | Visual treatment | |---|---|---|---| | `created` | Slot selected, constraints validated, entitlement check passed | — (intermediate state; not shown to user as a resting state) | *(needs UX writer input — e.g. muted / pending badge)* | | `confirmed` | Deposit paid (if required); entitlement confirmed | Explicit confirmation step with summary of constraints applied | Positive / active visual treatment; action badge *(needs UX writer input)* | | `arrived` | Staff marks patient as checked in | Single tap / click confirmation; irreversible without cancellation | Distinct "in-practice" visual treatment *(needs UX writer input)* | | `completed` | Appointment concluded | Single explicit action; terminal — cannot be undone | Neutral completed treatment; no active affordances *(needs UX writer input)* | | `no-show` | Patient did not attend; staff records outcome | Single explicit action with confirmation; terminal | Warning-level visual treatment; no active affordances *(needs UX writer input)* | | `cancelled` | Cancellation initiated by staff, patient, or system | Confirmation step required; if within short-notice window, system labels this explicitly; terminal | Cancelled visual treatment; audit entry visible *(needs UX writer input)* | Terminal states (`completed`, `no-show`, `cancelled`) must be rendered without any edit or re-book affordance on the appointment record itself. Re-booking from a cancelled appointment is a new booking flow, not a state reversal. Inferred from technical spec §3.2. **Waitlist Offer state machine:** Inferred from technical spec §7.2. | State | UI treatment (staff Offer Monitor) | UI treatment (patient) | |---|---|---| | `broadcast_offered` | Row shows offer live; eligible patient count visible | Patient receives offer notification via Communication Hub | | `engaged_locked` | Row shows lock holder (anonymised or role-appropriate); lock expiry countdown visible | Patient sees lock timer; must complete booking before expiry | | `confirmed` | Row shows confirmed outcome; slot closed | Patient sees booking confirmation | | `expired` | Row shows expired; slot returned to pool | Patient sees expiry message *(needs UX writer input)* | --- ### 5.3 Empty / Loading / Error / Offline States The following requirements apply to all Appointment Manager screens. Inferred from technical spec §4.3 and §18. **Diary (Day/Week/Month views):** - *Empty state:* No appointments booked for the selected date/practitioner/surgery — show a clear visual indicator that the view is loaded but empty, not broken. Inferred from technical spec §5.1. *(Exact empty state message needs UX writer input.)* - *Loading state:* Diary grid skeleton renders immediately; appointment tiles populate progressively. Full-diary re-render must not occur on lens toggle or view switch. Inferred from technical spec §5.1. Skeleton loader pattern recommended. - *Error state:* If availability data cannot be loaded (e.g. Rota Manager feed unavailable), display an explicit error explaining that diary data is temporarily unavailable and offer a retry action. Do not show a partial or stale diary without labelling it as such. Inferred from technical spec §18. *(Exact error message needs UX writer input.)* - *Offline state:* Read-only diary access must degrade gracefully when write operations are unavailable (technical spec §18). If fully offline, show a clearly labelled read-only mode indicator. Booking and state-change actions must be disabled, not hidden, in this state.* **Find Next:** - *Empty state:* Must explain specifically why no results were returned — booking window, zone, practitioner, accessibility constraint, or break segment. Never a blank panel. Inferred from technical spec §4.3. *(Exact messaging needs UX writer input.)* - *Loading state:* Progressive result population; constraint panel remains interactive while results load. - *Error state:* Explicit message with retry. *(Needs UX writer input.)* - *Offline state:* Find Next is unavailable; display clear unavailability message. No partial results. **Offer Monitor:** - *Empty state:* No active waitlist offers — show a neutral empty state, not an error. Inferred from technical spec §7.4. *(Needs UX writer input.)* - *Loading state:* Skeleton rows. - *Error state:* Explicit message; real-time feed status indicated. *(Needs UX writer input.)* - *Offline state:* Last-known state displayed with a clearly visible staleness indicator and timestamp. **Reschedule Job Monitor:** - *Empty state:* No active reschedule jobs — neutral empty state. *(Needs UX writer input.)* - *Loading state:* Skeleton list. - *Error state:* Explicit message with retry. *(Needs UX writer input.)* - *Offline state:* As Offer Monitor — last-known state with staleness label. **Patient mobile app:** - *Empty state (upcoming appointments):* Patient has no upcoming appointments — show a clear prompt to book. Inferred from technical spec §5.3. *(Needs UX writer input.)* - *Loading state:* Skeleton card list. - *Error state:* Explicit message; retry option. *(Needs UX writer input.)* - *Offline state:* Cached upcoming appointment list displayed in read-only mode; booking and cancellation actions disabled with explanation. *(Needs UX writer input.)* --- ### 5.4 Day View Ordering and Real-Time Feed Contract The Day View on both the web portal and the tablet app orders appointments by scheduled start time, ascending — the next imminent appointment appears at or near the top of the visible window. The real-time current-time indicator serves as the visual anchor for "now," and the diary must scroll to ensure the current-time indicator is visible on load without requiring manual scroll. Appointments that have already concluded (start time in the past and in a terminal state) are visually differentiated from upcoming and in-progress appointments, but remain visible in the day view for reference. The today-only operational feed that Appointment Manager supplies to Surgery & Decon Day View must provide appointments in time-ordered sequence (imminent first) and must include all fields required to support an imminent-first layout: scheduled start time, appointment type, patient identity, lifecycle state, accessibility flags, `LabRequired` flag, and any outstanding mandatory forms indicator. State changes made in the Appointment Manager diary (arrived, completed, no-show, cancelled) must propagate to this feed in real time. Inferred from Surgery & Decon Day View §2 and §3 and technical spec §14. --- ## 6. Component Inventory **New components introduced by this module:** - **Diary grid (calendar engine)** — time-slotted grid rendering appointments as tiles, supporting practitioner-first and surgery-first lens modes, Day/Week/Month views, and real-time current-time indicator. Appears on web portal. Inferred from technical spec §5.1 and §5.4. - **Find Next modal overlay** — persistent multi-pane modal (constraints / ranked results / diary preview) for governed availability discovery. Appears on web portal. Inferred from technical spec §6. - **Offer Monitor panel** — real-time list view of waitlist offer states (one row per cancelled slot), with state, timing, and outcome columns. Observational only. Appears on web portal. Inferred from technical spec §7.4. - **Reschedule Job Monitor panel** — job-level and per-patient status list with manual takeover controls per patient. Appears on web portal. Inferred from technical spec §8.3. - **Appointment tile** — calendar grid tile representing a single appointment, carrying lifecycle state badge, appointment type colour, and hover/tap preview affordance. Appears on web portal and tablet. Inferred from technical spec §5.1. - **Lifecycle state badge** — visual indicator of current appointment state (`confirmed`, `arrived`, `completed`, `no-show`, `cancelled`). Appears on appointment tiles, side panels, and list views. Inferred from technical spec §3.2. - **Current-time indicator** — full-width horizontal "now" line in Day View, scroll-aware and continuously updating. Presentational only. Appears on web portal Day View only. Inferred from technical spec §5.4. - **Engagement lock timer** — countdown display shown to a patient holding a waitlist offer lock, and surfaced in the Offer Monitor for staff. Inferred from technical spec §7.3 and §7.4. - **AI suggestion label / badge** — visual treatment marking any AI-originated suggestion as distinct from user or system actions. Required on all AI Concierge recovery option surfaces and on any Aiden-initiated booking suggestion. Inferred from technical spec §10 and §17. - **Constraint explanation panel** — inline or contextual panel surfacing why availability is constrained or absent. Appears in Find Next and wherever a booking attempt is blocked, including BookingEligibility gate blocks. Inferred from technical spec §4.3. - **No-availability explanation block** — structured display explaining specific constraint reasons when Find Next or self-booking returns no results. Inferred from technical spec §4.3. - **Delegated context banner** — persistent non-dismissible banner identifying the dependant being booked for when a guardian is acting in delegated context. Appears throughout mobile app booking flows. Inferred from Family Profiles UX §4.3. - **Outstanding forms indicator** — badge or flag on appointment tile and detail view indicating mandatory forms that are not yet complete. Appears on web portal, tablet, and where relevant in the mobile app. Inferred from Digital Forms spec §3 and §5.2. - **Lab linkage field** — read-only field in appointment detail view surfacing `LabRequired` flag and `LabCaseReference`. Appears on web portal and tablet. Inferred from Lab Manager §4.1 and §4.2 and technical spec §13. **Reused from the design system:** - Form fields with programmatic labels - Modal overlay / dialog - Toast / notification banner - Skeleton loader - Confirmation dialog - Role/permission indicator in header - Data table / list view - Badge / chip --- ## 7. Visual Design Notes - **Typography:** *(Needs UX writer / design system input — heading scale, body scale, monospace for time labels.)* - **Colour:** Appointment type colour is the primary semantic colour on diary tiles. Lifecycle state requires a distinct semantic colour layer — success (confirmed/arrived), neutral (completed), warning (no-show), destructive/muted (cancelled). Zone group colours render as horizontal rail backgrounds behind the diary grid and must be distinguishable from appointment type colours. Inferred from technical spec §5.1 and §3.2. Exact palette values are owned by the design system. Colour must never be the sole means of conveying state — always pair with label, icon, or pattern. - **Iconography:** Icon set, sizing, and usage are defined by the design system. Icons must never appear without a visible label or programmatic accessible name. Iconography is needed for: lifecycle state transitions, AI badge/label, engagement lock timer, manual takeover action, real-time feed status indicators, outstanding forms indicator, and lab linkage flag. Inferred from technical spec §7.4, §8.3, §10, and §5.4. - **Motion:** The real-time current-time indicator updates continuously; this must respect `prefers-reduced-motion` — when motion is reduced, the line should re-render at intervals rather than animate continuously. Inferred from technical spec §5.4. Transitions are used for state changes and panel open/close. Loading skeletons are preferred over spinners for content-heavy surfaces. Nothing in the audit trail or governance panels is animated. --- ## 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 (macOS/iOS), and TalkBack (Android). **Module-specific accessibility considerations:** - The diary grid is a complex custom component. Time slots, practitioner columns, and appointment tiles must each have appropriate ARIA roles, labels, and keyboard navigation patterns. Focus management when opening the Find Next modal and appointment side panel must be explicitly specified. Inferred from technical spec §5.1 and §6. - The real-time current-time indicator must not emit screen reader announcements on every update — it should be marked as presentational (`aria-hidden`) or announced only on significant changes, to avoid noise. Inferred from technical spec §5.4. - The engagement lock countdown timer on the patient mobile app must be accessible: time remaining must be announced at meaningful intervals (e.g. at 5 minutes and 1 minute remaining) and not announced continuously. Inferred from technical spec §7.3. - Accessibility and additional needs flags for patients (surfaced in the today-only feed and at booking time) must be clearly visible and not hidden behind progressive disclosure in clinical operational contexts. Inferred from technical spec §14 (`accessibilityFlags`) and §4.3. - The AI suggestion badge/label must carry sufficient contrast and not rely solely on colour or icon to convey its meaning. Inferred from technical spec §10. - The delegated context banner must be announced to screen readers on entry to any delegated booking screen and must not be dismissible via keyboard or assistive technology. Inferred from Family Profiles UX §4.3. - The outstanding forms indicator on appointment tiles must convey its meaning via text label or programmatic accessible name, not icon alone. Inferred from Digital Forms spec §3. --- ## 9. Internationalisation - Locale-aware date, time, and number formatting throughout. - All user-facing strings externalised to resource files; no hardcoded copy in components. - Layouts tolerant of 30% string-length growth (e.g. German, French translations). - All timestamps stored and transmitted as UTC; displayed in the local practice time zone as configured. The real-time current-time indicator is driven by the local practice clock and must be time-zone aware. Inferred from technical spec §5.4 and §14. - The engagement lock expiry countdown is time-sensitive. Locale-aware duration formatting must be applied consistently across staff and patient surfaces. Inferred from technical spec §7.3. - **RTL support:** *(Needs product decision — not addressed in technical spec. Flagged as open question.)* --- ## 10. Cross-Module UX Touchpoints All touchpoints inferred from the integration contracts declared in technical spec §11 and §19. - **Rota Manager** — Availability shown in the diary and Find Next is derived exclusively from Rota Manager–generated Rota Entries. The UX must never surface or imply the ability to edit schedule patterns; it reflects rota output only. Practitioner absence confirmed in Rota Manager is the trigger for Reschedule Job creation — this handoff is system-to-system, but the UI consequence (Reschedule Job Monitor appearing) must be clearly traceable to the absence event. The boundary between rota-derived availability and Appointment Manager booking constraints must be legible to users at all times (see §4.1 for the detailed surfacing requirement). Inferred from technical spec §4.1, §8.1, and §19. - **Communication Hub** — Appointment Manager does not deliver messages directly. Notification triggers (offer state transitions, reschedule actions, booking confirmations) are emitted as events to Communication Hub. The UX must never imply that Appointment Manager sends messages; confirmation states in the UI reflect that a trigger has been emitted, not that a message has been delivered. Inferred from technical spec §11.2 and §2.2. - **Integrated Payments** — When a deposit is required, the booking confirmation flow surfaces the deposit obligation and hands off to Integrated Payments for collection. The UI must show that deposit payment is a prerequisite for booking confirmation, but the payment interface itself is owned by Integrated Payments. The Appointment Manager UI reflects the outcome (deposit collected / care plan covered / £0). The payment drawer may be opened from appointment context without locking the appointment for state transitions; however, a deposit payment in progress gates booking confirmation until the outcome is received (see §5.1 payment drawer concurrency note). Inferred from technical spec §12 and §2.2 and Integrated Payments spec §3 and §4.1. - **Task Manager** — Task trigger events are emitted silently by Appointment Manager on qualifying lifecycle transitions. The UX does not need to surface this handoff directly, but audit trail entries for emitted `AppointmentTaskTriggerEvent`s must be visible in the audit view. Inferred from technical spec §16 and §17. - **AI Concierge** — Short-notice cancellations trigger a `RotaCancellationEvent` to AI Concierge, which may then present recovery options to the patient. Any recovery booking initiated by AI Concierge that is routed back through Appointment Manager's booking flow must be visibly attributed as AI-assisted in both the booking confirmation and the audit trail, with the original appointment referenced. The AI suggestion must be labelled before the patient commits. Additionally, when a staff member initiates a booking from within the AI Concierge Agent Console (e.g. via a "open booking UI" one-click action during a patient call), Appointment Manager's booking surface must open with the patient context pre-populated. This entry point is only available when the patient's identity has been verified in AI Concierge; if the patient is unverified, the booking entry point must not be offered. The verification gate is enforced by AI Concierge and reflected in the launch context passed to Appointment Manager — Appointment Manager must not independently bypass or re-evaluate it. Inferred from technical spec §10.1 and AI Concierge UX §2, §3.3, and §4.1. - **Lab Manager** — Appointment Manager exposes a read-only appointment-linkage interface consumed by Lab Manager. The `LabRequired` flag and `LabCaseReference` are surfaced as read-only fields in the appointment detail view and in the Surgery Tablet appointment header. If the linked appointment's state changes to `cancelled` or `no-show`, an advisory note is displayed in the appointment detail view indicating that a linked lab case exists and may require attention (see §5.1 lab linkage note). Inferred from technical spec §13 and Lab Manager §4.1 and §4.2. - **Surgery & Decon Day View** — The today-only operational feed consumed by Surgery & Decon Day View is read-only and context-filtered. Appointment Manager's diary and Surgery & Decon Day View share appointment state data but are separate UI surfaces; state changes made in the diary (e.g. arrived, completed) must propagate in real time to the day view feed. The feed is supplied in time-ordered (imminent-first) sequence to support Surgery & Decon Day View's imminent-first layout principle (see §5.4 for the feed contract). Inferred from technical spec §14 and Surgery & Decon Day View §2 and §3. - **Smart Dashboards** — Live appointment state is exposed via the governed read-only interface. FOH staff may perform lifecycle actions (confirm arrival, cancel) directly from Smart Dashboards without navigating to Appointment Manager; these actions are governed by the same constraints and audit requirements as portal-originated actions (see §5.1 Smart Dashboards inline actions note). All reads must be logged in the audit trail. Inferred from technical spec §15 and §17 and Smart Dashboards §4.1 and §4.4. - **Access Manager** — All capability access in the Appointment Manager UI is gated by RBAC role assertions from Access Manager. The current user's active role must be visible in the portal header. Controls that the current user cannot access must not appear (no dead toggles), with the exception of read-only views that may be visible but non-interactive with a clear role-based explanation. Session lifecycle events (suspension, revocation, idle timeout) driven by Access Manager must be handled gracefully on the tablet surface as specified in §4.2. Inferred from technical spec §9 and §22.2 and Access Manager §4.2 and §4.3. - **Audit & Compliance** — All audit-significant actions (lifecycle transitions, manual takeovers, AI suggestions accepted/rejected, waitlist offer events, care plan entitlement checks, deposit policy evaluations) must emit immutable log entries before the action is considered complete. The UI must not present success feedback for an action until the audit write has been confirmed. Inferred from technical spec §17 and §22.2 rule 11. - **Treatment Pipeline Manager** — The `BookingEligibility` status computed by Treatment Pipeline Manager is a hard prerequisite for all booking actions across every surface (staff web, patient mobile, AI Concierge–initiated). When eligibility is false, the booking action must be blocked and a clear, named explanation displayed; no surface may circumvent this gate. The eligibility status must be checked at the start of every booking flow and re-checked before the final confirmation step if the flow has been open for an extended period. The eligibility check result is informational for staff (who see the reason) and plain-language for patients (who are directed to contact the practice). Inferred from Treatment Pipeline Manager UX §2 Principle 6. - **Recall & Reconnect** — Patients may enter the Appointment Manager mobile booking flow via a deep-link from a Recall & Reconnect outreach notification. In this case, appointment type and recall reason context are pre-populated (see §5.1 recall context deep-link note). The recall context reference is carried through to the audit trail. No direct UX surface within Appointment Manager is required for managing recall campaigns; that is owned by Recall & Reconnect. Inferred from Recall & Reconnect UX §4.3 and integration contract §10.2. - **Digital Forms** — Mandatory forms assigned to appointments act as checkpoint gates within the appointment workflow. Outstanding form status is surfaced on appointment tiles and in the appointment detail view. On the Surgery Tablet, an incomplete mandatory form blocks the "Finish & Send" / complete action (see §5.1 Flow 6). Form assignment, content, and completion are owned by Digital Forms; Appointment Manager surfaces completion status only. Inferred from Digital Forms spec §3 and §5.2. - **Aftercare Manager** — Appointment completion emits a trigger event consumed by Aftercare Manager for automated aftercare instruction issuance. A read-only indicator at the completion confirmation step informs staff that aftercare instructions will be sent automatically. No template selection or content review is required within Appointment Manager. Inferred from Aftercare Manager technical spec §4.1. - **Loyalty Insights** — Appointment Manager emits appointment booking and recall-compliance signals that Loyalty Insights consumes for loyalty status calculations, including recall compliance trend metrics for care-plan-linked appointments. No direct UX surface within Appointment Manager is required for loyalty display; that is owned by Loyalty Insights. The signals emitted (appointment booked, recall window opened, recall booking made or missed) must be included in the audit trail and event stream. Inferred from Loyalty Insights §4.1 and technical spec §6.1. - **AI Assistant (Aiden)** — Aiden may surface appointment-related suggested next actions during patient conversations and deep-link the staff user into Appointment Manager's booking or modification flows. When Appointment Manager is launched via an Aiden deep-link, the patient context and suggested action type must be pre-populated. Any booking or modification resulting from an Aiden-initiated deep-link must be attributed as Aiden-assisted in the audit trail (using the same AI-involvement flag mechanism as AI Concierge). The AI suggestion label and plain-language explanation requirements (§3 Design Philosophy, §11 Governance) apply equally to Aiden-originated suggestions. Inferred from AI Assistant (Aiden) UX spec and technical spec §17. - **Product Shop** — Following appointment completion on the tablet, a dismissible post-completion prompt may offer entry to the Product Shop recommendation flow for the patient (see §5.1 product shop handoff note). This entry point is owned by Appointment Manager at the point of trigger but the recommendation flow is owned by Product Shop. Inferred from Product Shop UX §4.2. - **Hygiene Subscriptions** — Following completion of a hygiene-relevant appointment on the tablet, a dismissible post-completion prompt may offer entry to the Hygiene Subscriptions plan-builder, with appointment context pre-populated (see §5.1 hygiene subscription enrolment note). Inferred from Hygiene Subscriptions §4.2. **UX consistency rules:** - Find Next is always a persistent modal overlay — it must not open in a new tab or navigate away from the diary context. Inferred from technical spec §6. - The Offer Monitor and Reschedule Job Monitor are observational panels — they must never be styled or positioned as primary action surfaces. Manual takeover is a proportionate, clearly labelled exception within the Reschedule Job Monitor, not a prominent CTA. Inferred from technical spec §7.4 and §8.3. - AI suggestion labels must use a consistent visual treatment across all surfaces where AI output can appear (AI Concierge recovery options in the patient app; Aiden-initiated suggestions in the staff portal; any advisory overlay in the staff diary). Inferred from technical spec §10. - Booking confirmation always requires an explicit confirmation step — no flow in any surface (staff web, patient mobile, AI Concierge recovery, Aiden deep-link) may confirm a booking without a deliberate user action. Inferred from technical spec §6 and §10. --- ## 11. Governance & Auditability AI suggestions are visually distinct from user actions — use a clearly labelled badge or border treatment, not colour alone. Any AI-originated suggestion (from AI Concierge recovery flows, from Aiden-initiated deep-links, or from any advisory layer) must carry a visible label identifying it as an AI suggestion, a plain-language explanation of why it was suggested, and a clear accept/reject choice before any booking action proceeds. The outcome (accepted or rejected) is logged to the audit trail. Inferred from technical spec §10 and §17. Audit-significant actions show a confirmation step before they are committed. Audit-significant actions in this module include: booking confirmation, rescheduling, cancellation (especially within the short-notice window), lifecycle state transitions to `arrived`, `completed`, `no-show`, and `cancelled`, manual takeover in a Reschedule Job, care plan entitlement decisions at booking time, BookingEligibility gate evaluations, and delegated booking actions performed by a guardian on behalf of a dependant. Each must show a summary confirmation step naming the action and its consequences before proceeding. Inferred from technical spec §17. The current user's role and active permissions are visible in the header. Read-only states are visually distinct from editable ones. The Offer Monitor and Reschedule Job Monitor must carry a persistent "read-only / observational" visual indicator at panel level, so that staff understand these are visibility surfaces, not control surfaces (except where proportionate manual takeover is explicitly permitted). Inferred from technical spec §7.4 and §8.3. Terminal appointment states (`completed`, `no-show`, `cancelled`) must render without edit affordances and carry a visual indicator that the state is final. Attempting to act on a terminal state must produce a clear explanation, not a silent failure. Inferred from technical spec §3.2. The audit trail for any appointment, waitlist offer, or reschedule job must be accessible from its detail view. The trail must show actor identity, timestamp, action type, booking source (`staff` / `patient` / `system` / `dashboard` / `ai_concierge` / `aiden`), and — where applicable — AI involvement flags, delegated-action flags, and recall context references. Inferred from technical spec §17. Care plan entitlement outcomes (covered, partially covered, ineligible) must be visible to the booking actor at the confirmation step, not only in the audit trail. Inferred from technical spec §2.1 and §17. Deposit policy decisions (amount, policy rule applied, care plan override) must be visible to the booking actor at the confirmation step. Inferred from technical spec §12 and §17. BookingEligibility gate outcomes must be recorded in the audit trail for every booking flow in which they are evaluated, whether the outcome was eligible (allowed to proceed) or ineligible (blocked). Inferred from Treatment Pipeline Manager UX §2 Principle 6 and technical spec §17. --- ## 12. Notification & Communication Patterns All notification delivery for Appointment Manager events is owned by Communication Hub. Appointment Manager emits trigger events; it does not deliver messages directly. The UX reflects trigger emission, not message delivery. Inferred from technical spec §11.2 and §2.2. **In-app banner:** - Used for: degraded availability (e.g. diary data temporarily unavailable), read-only mode indicator when write operations are unavailable, staleness warnings on the Offer Monitor or Reschedule Job Monitor if the real-time feed is delayed, and session-interrupted state on the tablet following an Access Manager–driven forced logout. Inferred from technical spec §18 and Access Manager §4.2. **Toast:** - Used for: successful appointment booking confirmation, successful lifecycle state transition (arrived, completed, no-show, cancelled), successful manual takeover initiation in a Reschedule Job, and successful waitlist enrolment. Toasts are confirmatory and ephemeral — they must not carry critical information that the user cannot recover if the toast is missed. Inferred from technical spec §3.2, §7, and §8.3. *(Exact toast copy needs UX writer input.)* **Push notification (via Communication Hub — NOT directly):** - Used for: patient waitlist offer notification (broadcast); patient appointment reminder; patient cancellation notification; patient reschedule notification following practitioner absence; patient recall outreach notification (trigger owned by Recall & Reconnect, but Appointment Manager must be prepared to receive deep-linked entry from these notifications). All delivered via Communication Hub; Appointment Manager emits the trigger event only. Inferred from technical spec §11.2. *(Notification content and timing are governed by Communication Hub configuration — out of scope for this spec.)* **Email / SMS (via Communication Hub — NOT directly):** - Used for: appointment confirmation, cancellation, and reschedule notifications to patients; waitlist offer notifications where push is not available. All delivered via Communication Hub; Appointment Manager emits the trigger event only. Inferred from technical spec §11.2. --- ## 13. Open Questions > UX decisions to resolve before this spec is promoted from `draft` to `published`. 1. **RTL support** — the technical spec does not address RTL. A product decision is needed on whether RTL layouts are required for any supported locale. Inferred gap from technical spec §18 (internationalisation not explicitly excluded). 2. **Tablet app — scope of booking capability** — the technical spec describes the tablet as surfacing appointment lookup and lifecycle state updates (arrived, completed, no-show). It is unclear whether staff-initiated booking or rescheduling is also permitted on the tablet surface. This must be resolved before tablet interaction patterns can be fully specified. Inferred from technical spec §5.2. 3. **Patient mobile app — waitlist offer delivery UX** — the lock window duration is practice-configurable (technical spec §7.3), but the UX for communicating lock expiry to a patient (including what happens at the moment of expiry) needs explicit design. Inferred from technical spec §7.3. *(Needs UX writer and product input.)* 4. **AI Concierge recovery flow — entry point on patient app** — it is not yet specified where in the patient mobile app the AI Concierge short-notice cancellation recovery options surface. Is this within the app itself, or delivered via a notification deep-link? Inferred from technical spec §10.1. *(Needs product decision.)* 5. **RBAC role names and UI labels** — role names in the technical spec (Reception, Practice Manager, Admin) are indicative and must be reconciled with the Access Manager role registry before UI labels can be finalised. Inferred from technical spec §9 and open question 5 therein.* 6. **Confirmation modal patterns for terminal state transitions** — the specific interaction design for confirming `no-show`, `completed`, and `cancelled` transitions (particularly the `cancelled` state with its short-notice window warning) requires detailed UX authoring. Inferred from technical spec §3.2 and §10.1. *(Needs UX writer input — exact copy, modal structure, and warning treatment.)* 7. **Diary empty state for a fresh practice (no rota entries yet)** — when a practice has not yet generated any Rota Entries in Rota Manager, the diary will be structurally empty. The onboarding empty state for this condition needs distinct treatment from a "no appointments booked today" empty state. Inferred from technical spec §4.1. *(Needs UX writer and onboarding flow input.)* 8. **Audit trail UI accessibility within appointment detail** — the audit trail is always present on an appointment record (technical spec §3.1). The visual design for surfacing this within the appointment detail panel (progressive disclosure vs always-visible, depth of information shown by default) needs explicit design specification. Inferred from technical spec §17.* 9. **Month view interaction affordances** — the technical spec states Month view is non-interactive (decision support only) and clicking drills into Day View. The exact affordance for this drill-down (which element is clickable, what triggers the navigation) needs design specification. Inferred from technical spec §5.1.* 10. **Short-notice cancellation window default and engagement lock window range** — as noted in technical spec open question 1 and 2: these configuration values are deferred to implementation. UX copy for the patient-facing lock timer and staff-facing short-notice warning cannot be finalised until these values are confirmed. 11. **BookingEligibility gate — patient-facing messaging** — Treatment Pipeline Manager's `BookingEligibility` status may be false for a variety of clinical reasons that are not appropriate to surface verbatim to a patient in the mobile app. The plain-language patient-facing message for an ineligibility block needs UX writer and clinical input to ensure it is accurate, appropriately reassuring, and directs the patient to an actionable next step (e.g. contacting the practice). *(Needs UX writer and clinical governance input.)* 12. **Delegated booking — guardian identity verification** — Family Profiles governs the guardian–dependant relationship and profile switcher gate. It is not yet specified whether Appointment Manager must perform any additional identity re-confirmation step when a guardian initiates a booking in delegated context on the mobile app, or whether the Family Profiles gate is sufficient. *(Needs product and clinical governance decision.)* 13. **Aiden deep-link scope** — the range of appointment-related actions that Aiden may suggest and deep-link into (booking, rescheduling, cancellation, or a subset thereof) needs to be agreed between the AI Assistant (Aiden) and Appointment Manager product teams before the deep-link contract can be fully specified. *(Needs cross-team product decision.)* 14. **Post-completion prompts ordering** — where both a Product Shop recommendation prompt and a Hygiene Subscriptions enrolment prompt are applicable following appointment completion on the tablet, the ordering, stacking, or mutual-exclusion rules for these prompts need to be agreed. Presenting both simultaneously may be disruptive to the clinical workflow. *(Needs product decision.)*
Live preview
💬
Comments
0
💡
Ask
0
📋
Activity
Open panel
→
Working...