Surgery & Decon Day View – UX Specification

Related Technical Authority: Surgery & Decon Day View – Technical Specification

1. Purpose

This UX specification governs the nurse-facing, shared-tablet experiences through which today's surgical and decontamination work is made visible, actionable, and attributable. It covers two distinct tablet surfaces — the Decon Wall Tablet and the Surgery Tablet — and ensures that readiness, compliance, and clinical context are surfaced in a way that supports safe, fast, day-of clinical operations. The primary roles served are nurses working in surgery or decontamination, and practice administrators who configure device and work-package policy.

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.
• Separation of concerns is inviolable — the Decon Wall Tablet and Surgery Tablet are distinct surfaces with enforced, non-collapsible responsibilities; no design decision may blur the boundary between awareness and action. Inferred from technical spec §4.1.
• Attribution always — every write action (tray confirmation, task completion, workflow step) is recorded against a named, authenticated nurse; anonymous or unattended display is architecturally prohibited. Inferred from technical spec §2.1 and §9.
• Imminent first — the default ordering on both surfaces prioritises what is happening now and what is coming next; retrospective data is present but visually subordinate. Inferred from technical spec §4.4 and §13.4.
• Safety context always present — tooth numbers, lab-required flags, and mandatory form gate states are never hidden or progressively collapsed by default; they are first-class visible fields on every appointment row. Inferred from technical spec §4.2, §4.3, and build rule 5.

3. Design Philosophy

The mental model is a clinical operations board, not a task management app. The interface does not ask nurses to manage or navigate complexity — it presents the day's work in time order, makes the next required action obvious, and steps out of the way. Inferred from technical spec §1 and §4.4.

Empty states signal readiness rather than absence: if there are no outstanding tasks or no upcoming appointments in the current window, the surface should communicate "all clear" rather than "nothing here". Inferred from the operational intent described in technical spec §4.2.

Error states distinguish between recoverable connectivity issues (last-known-good state is shown with a staleness indicator) and genuinely blocked states (a mandatory form gate, a blocked task) that require a named action to resolve. A blank or unrecoverable screen is never an acceptable error state on a clinical surface. Inferred from technical spec §14 (Reliability) and build rule 7.

AI suggestions are out of scope for MVP. Should they appear in future, they will be visually distinct, non-executable, and subject to platform AI governance rules. Inferred from technical spec §7.

Multi-step flows (in-chair workflow, Finish & Send) are linear and gated: each step must be completed or explicitly acknowledged before the next is available. There is no free navigation to a later step. Inferred from technical spec §4.3.

Undo/redo is not available for governed write actions (tray readiness, task completion, Finish & Send). These are attributable, timestamped records; reversing them requires a separate governed action. Inferred from the immutability requirements in technical spec §8 and §13.1.

Read-only vs editable surfaces are contextually clear: the Decon Wall Tablet is a read and awareness surface; the Surgery Tablet is the action and completion surface. On the Surgery Tablet, editable controls are only visible when a nurse has an active, authenticated session. Inferred from technical spec §4.1 and §4.3.

4. Primary Surfaces

4.1 Web Portal

The technical specification does not define a web portal surface for this module (§5.1 is explicitly left undefined). Whether a read-only management view of day-view data is in scope is an open question. See Open Questions §13. Inferred from technical spec §5.1 and Open Question 6.

(needs UX writer input — if a web portal surface is confirmed in scope, define who uses it and what key tasks it supports)

4.2 Tablet App

The tablet app is the primary and only confirmed delivery surface for this module. It is delivered as two physically and functionally distinct experiences. Inferred from technical spec §5.2 and §4.1.

Decon Wall Tablet

Who uses it: nurses and decontamination staff monitoring today's schedule and compliance work packages; the device is wall-mounted or shared in the decontamination area. Inferred from technical spec §4.2.

Key tasks performed here:

• Scanning today's appointment schedule in time order, filtered to the authenticated nurse's rota context. Inferred from technical spec §4.2.
• Monitoring decon work package status — due times, completion attribution, and overdue highlighting. Inferred from technical spec §4.2.
• Identifying lab-required appointments and unreceipted lab cases (when Lab Manager is enabled). Inferred from technical spec §4.2 and §13.5.
• Viewing the "4-tray lookahead" — the next four upcoming appointments emphasised for advance preparation. Inferred from technical spec §4.2.

Layout pattern: glanceable single-pane board layout, optimised for wall-mounted viewing at arm's length. Time-ordered appointment list with a persistent work package compliance strip. No deep navigation. Inferred from technical spec §4.2 and §4.4.

Touch ergonomics: glove-friendly tap targets ≥48 px; minimal interaction depth; large, high-contrast status indicators readable at a distance. The surface is designed to be informative with minimal touch interaction. Inferred from technical spec §5.2 and §14 (Accessibility).

Surgery Tablet (Nurse View)

Who uses it: the named, authenticated nurse assigned to the surgery; the device is located at the point of work in the surgery. Inferred from technical spec §4.3.

Key tasks performed here:

• Confirming tray readiness for an appointment (single-tap, recorded with nurse identity and timestamp). Inferred from technical spec §4.3 and build rule 3.
• Progressing through in-chair workflow steps for the current appointment. Inferred from technical spec §4.3.
• Checking and acting on form and consent status before the clinician enters the surgery. Inferred from technical spec §4.3.
• Delegating to Digital Forms for signature capture. Inferred from technical spec §4.3.
• Completing the appointment via Finish & Send, triggering PMS synchronisation and aftercare trigger. Inferred from technical spec §6.2 and §4.3.
• Viewing appointment header context: patient name, appointment type, tooth numbers, lab flag, lab case reference, and notes. Inferred from technical spec §4.3.

Layout pattern: list-detail layout with an appointment header persistently visible at the top and a scrollable workflow step list below. The active step is visually prominent; completed and upcoming steps are progressively disclosed. Inferred from technical spec §4.3 and the "action-first" principle.

Touch ergonomics: glove-friendly tap targets ≥48 px; Tray Ready and step-completion actions must be reachable without deep navigation; single-tap confirmation is the standard interaction pattern for governed write actions. Inferred from technical spec §5.2 and §14 (Accessibility).

4.3 Mobile App (Patient or Staff)

This module does not deliver a patient-facing surface. No staff mobile surface is defined in the technical specification. Inferred from technical spec §5.3.

5. Interaction Model

5.1 Primary Flows

Flow A — Nurse authentication on a shared tablet

Inferred from technical spec §9 and §13.2 (build rule 1).

1. Tablet displays a locked/unauthenticated state — no appointment or task data visible.
2. Nurse authenticates via badge tap, PIN entry, or QR scan (method determined by device policy).
3. Session established: nurse identity confirmed, rota assignment loaded, today-only filtered view rendered.
4. On explicit logout, inactivity timeout, or rota end time: session is cleanly terminated, tablet returns to locked state.

Flow B — Nurse user switching on a shared tablet

Inferred from technical spec §9.

1. Incoming nurse initiates user switch ((needs UX writer input — trigger mechanism: dedicated switch button, badge tap on active session, or both?)).
2. Outgoing nurse's session is cleanly terminated and audit event emitted.
3. Incoming nurse authenticates (same auth flow as Flow A).
4. New session established with incoming nurse's rota context loaded.

Flow C — Tray readiness confirmation (Surgery Tablet)

Inferred from technical spec §4.3 and build rule 3.

1. Nurse views appointment header: patient name, appointment type, tooth numbers, lab flag, notes.
2. Nurse performs single-tap Tray Ready confirmation.
3. System records TrayReadyTimestamp and TrayReadyByUserId immediately.
4. Tray Ready status is visually updated in the appointment header; confirmation is not reversible via the UI.

Flow D — In-chair workflow with mandatory form gate (Surgery Tablet)

Inferred from technical spec §4.3 and build rules 11 and 12.

1. Nurse opens the in-chair workflow step list for the current appointment.
2. If a mandatory form is missing or out of date: a visible blocking state is displayed; the affected workflow step is marked as blocked and cannot be progressed.
3. Nurse delegates form/consent to Digital Forms (signature capture is fully governed by Digital Forms' rules).
4. Once the form gate is satisfied, the blocked step clears and the workflow step becomes actionable.
5. Nurse completes all in-chair steps.
6. Nurse triggers Finish & Send — confirmation step presented before submission ((needs UX writer input — exact confirmation modal copy and button labels)).
7. Finish & Send emits: PMS synchronisation, aftercare trigger to Aftercare Manager, audit event.

Flow E — Decon work package task completion (either surface)

Inferred from technical spec §3.3, §3.5, and §6.2. Interaction patterns for this flow must be consistent with Task Manager's owner-explicit, audit-as-feature, and checklist-first execution model (Task Manager §4.2), as both modules surface the same underlying work packages on shared tablet devices. Specifically: task completion interactions must require explicit single-tap confirmation by the authenticated nurse (never implicit or bulk-complete), completed task rows must remain visible for the remainder of the day with the completing nurse's name displayed inline, and the checklist presentation must mirror the Task Manager tablet pattern — tasks listed in due-time order with glove-friendly tap targets — so that nurses moving between surfaces encounter a consistent mental model for work package ownership and completion.

1. Work package tasks are listed in due-time order on the relevant tablet surface.
2. Nurse taps to complete an Active or In Progress task.
3. System records CompletedTimestamp and CompletedByUserId; completion event emitted to Task Manager.
4. Task row updates to Completed state with attribution and timestamp visible; row is retained in view for the remainder of the day.
5. Overdue tasks (due time passed, not yet Completed) display a persistent overdue indicator until resolved.

5.2 State Machines (Mirror of Technical Spec §3)

SharedDeviceSession states

Inferred from technical spec §3.4 and §9.

Session termination (timeout or rota-end) must not be silent — a brief visible transition must confirm the session has ended before the lock state is displayed, so nurses are aware their session has closed. Inferred from technical spec §9 and the attribution principle.

WorkPackageTaskRow states

Inferred from technical spec §3.5.

Overdue = a task in Active or In Progress state whose DueTime has passed. This is a visual overlay on the existing state treatment, not a separate state. A distinct overdue indicator ((needs UX writer input — exact colour, icon, label)) must be applied persistently until the task reaches Completed or Cancelled. Inferred from technical spec §3.5 and §13.4.

Appointment completion state (Surgery Tablet)

Inferred from technical spec §4.3 and build rule 14.

5.3 Empty / Loading / Error / Offline States

Every screen definition below is inferred from technical spec §14 (Reliability and Accessibility) and build rules 7 and 8.

Decon Wall Tablet

• Empty state: If no appointments or work packages are scheduled for today in the authenticated nurse's rota context, the surface displays a positive "no appointments scheduled for today" confirmation — not a blank screen. Inferred from technical spec §4.2 and the operational intent.
• Loading state: On initial load and rota-filtered data fetch, a skeleton layout is displayed — appointment row placeholders in time order — so the structure is visible before data arrives. Inferred from technical spec §14 (Performance).
• Error state: If upstream data (Appointment Manager, Rota Manager, Task Manager) is temporarily unavailable, the last successfully loaded state is displayed with a clear, persistent staleness indicator ((needs UX writer input — exact label and visual treatment)). A blank screen is never acceptable. Inferred from technical spec §14 (Reliability).
• Offline state: The last successfully loaded state remains visible with a staleness indicator. Write actions (task completions) must queue locally and confirm to the nurse that completion will be submitted when connectivity is restored. Inferred from technical spec §14 (Reliability).

Surgery Tablet

• Empty state: If no appointments are scheduled for the authenticated nurse's rota assignment today, the surface displays a "no appointments for today" confirmation. If an appointment has no notes or no lab case reference, those fields are not shown (not shown as blank). Inferred from technical spec §3.1 (nullable fields) and operational intent.
• Loading state: Appointment header and workflow step list display skeleton placeholders while data is fetched. Tray Ready and step-completion controls are not shown until data has loaded, to prevent premature interaction. Inferred from technical spec §14 (Performance) and build rule 3.
• Error state: If the workflow step list or form gate status cannot be loaded, a clear error state is displayed with a retry action. Finish & Send is not available if appointment data cannot be confirmed as current. Inferred from technical spec §14 (Reliability) and build rule 14.
• Offline state: The last successfully loaded appointment state is displayed. Tray Ready confirmation may be queued locally with nurse identity and timestamp and submitted on reconnection. Finish & Send must not be permitted on stale data; a staleness warning must be shown before the action is available. Inferred from technical spec §14 (Reliability) and the attribution principle.

6. Component Inventory

New components introduced or extended by this module:

• AppointmentDayRow — a single appointment card rendered in both tablet views, displaying time, surgery, clinician, appointment type, tooth numbers, lab-required flag, and (where present) lab case reference and notes. Inferred from technical spec §3.1 and §4.2.
• TrayReadinessControl — a single-tap confirmation control on the Surgery Tablet only; displays unconfirmed and confirmed states with nurse attribution and timestamp. Inferred from technical spec §3.2 and §4.3.
• WorkPackageTaskRow — a task row component rendering due time, task name, status badge (Active / In Progress / Blocked / Completed / Cancelled), completed-by attribution, and overdue indicator. Appears on both tablet surfaces. Inferred from technical spec §3.3 and §3.5.
• MandatoryFormGateBanner — a blocking state component displayed in the appointment header and on the affected workflow step when a mandatory form is missing or out of date; includes a direct action to open Digital Forms. Inferred from technical spec §4.3 and build rule 11.
• SharedDeviceAuthScreen — the full-screen authentication surface presented on session start or after termination; supports badge tap, PIN, and QR inputs per device policy. Inferred from technical spec §3.4 and §9.
• SessionHeader — a persistent header strip visible on both tablet surfaces during an active session, displaying the authenticated nurse's name, current time, and a session-end action. Inferred from technical spec §9 and the attribution principle.
• StalenessIndicator — a persistent banner displayed when the view is showing data from the last successful load rather than live data; includes a retry action and time of last successful sync. Inferred from technical spec §14 (Reliability).
• FinishAndSendConfirmation — a modal confirmation step presented before Finish & Send is submitted; irreversible action confirmation pattern. Inferred from technical spec §4.3 and §6.2.

Reused from the design system:

• Toast notification (for non-critical action confirmations such as task completion). Inferred from platform-standard notification patterns.
• Skeleton loader (for loading states on both surfaces). Inferred from technical spec §14 (Performance).
• Modal dialog (for Finish & Send confirmation). Inferred from technical spec §4.3.
• Status badge (reused with module-specific state values for task lifecycle states). Inferred from technical spec §3.5.

7. Visual Design Notes

• Typography: heading and body scale must be legible at arm's length on a wall-mounted tablet for the Decon Wall Tablet; body text size must be larger than standard web defaults. Monospace is appropriate for timestamps (e.g. completed-at, due time). Exact scale to be defined by the design system. Inferred from technical spec §4.2 and §14 (Accessibility).
• Colour: semantic colour is required for task states — at minimum: overdue (warning/urgent), blocked (warning/attention), completed (success/neutral), cancelled (muted/disabled). Lab-required flags require a distinct, non-error colour treatment to distinguish clinical context from compliance failure. Exact palette values are design system decisions. Inferred from technical spec §3.5 and §13.4.
• Iconography: icons must always be accompanied by a visible label on clinical surfaces; icon-only controls are not permitted on either tablet surface given the glove-use environment and the diversity of nursing staff. Icon set is a design system decision. Inferred from technical spec §14 (Accessibility) and the clinical operations context.
• Motion: transitions must respect prefers-reduced-motion. State changes (task completion, tray readiness confirmation) may use a brief completion animation to provide clear feedback on touch. Loading transitions use skeleton layouts rather than spinner-only. No decorative animation is appropriate on clinical surfaces. Inferred from technical spec §14 (Accessibility) and the calm-by-default principle.

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
• Touch targets on both tablet surfaces MUST be ≥48 px to support gloved use in a clinical environment — this exceeds the WCAG 44 px minimum and is a non-negotiable clinical requirement. Inferred from technical spec §5.2 and §14 (Accessibility).
• Status indicators (overdue, blocked, completed) must never rely on colour alone; each state must carry a distinct icon or text label so the surface is usable for colour-blind staff. Inferred from technical spec §3.5 and §14 (Accessibility).
• The SharedDeviceAuthScreen must be accessible to nurses with motor impairments; PIN and QR auth methods provide alternatives to badge tap where device policy permits. Inferred from technical spec §9.

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 for MVP (to be confirmed for future locale expansion)
• Timestamps (login time, tray readiness, task completion) must be formatted according to the practice's configured locale and time zone, not the device's system locale, to ensure clinical records are unambiguous. Inferred from technical spec §3.1–§3.4 (all timestamp fields) and the multi-site deployment requirement in §14 (Scalability).

10. Cross-Module UX Touchpoints

Where this module's UX intersects with related modules:

• Appointment Manager — the Day View consumes today's appointment schedule from Appointment Manager. Nurses do not navigate to Appointment Manager from the tablet surface; the integration is invisible. If appointment data is stale or unavailable, the StalenessIndicator is shown. No back-navigation to Appointment Manager is expected from either tablet view. Inferred from technical spec §6.1.
• Rota Manager — rota assignment data governs which appointments and work packages are visible to the authenticated nurse. Nurses do not interact with Rota Manager directly from this surface; the integration is invisible. Rota end time drives automatic session termination. Inferred from technical spec §6.1 and §9.
• Task Manager — work package task rows are sourced from Task Manager. Task completions are emitted back to Task Manager as async events. The handoff is invisible to nurses; the Task Manager lifecycle states are rendered via WorkPackageTaskRow without navigation away from the Day View. The interaction model for task completion on both tablet surfaces (explicit single-tap attribution, checklist-first presentation, retained completed rows) is aligned with Task Manager's owner-explicit and audit-as-feature design principles, ensuring a consistent nurse experience across both modules. Inferred from technical spec §6.1 and §6.2, and Task Manager §4.2.
• Digital Forms — when a mandatory form gate is active, the MandatoryFormGateBanner provides a direct action that opens the Digital Forms governed signing flow. Signature capture is fully delegated to Digital Forms; the nurse returns to the Surgery Tablet workflow after completion. This is the only navigational handoff out of the Surgery Tablet in the MVP. Inferred from technical spec §4.3 and §6.2.
• Aftercare Manager — the aftercare trigger is emitted on Finish & Send completion; there is no nurse-facing Aftercare Manager surface within this module's scope. The handoff is invisible to nurses. Inferred from technical spec §6.2.
• Access Manager — governs authentication methods, inactivity timeout, and role-scoped access. Nurses interact with Access Manager behaviour via the SharedDeviceAuthScreen; they do not navigate to Access Manager directly. Inferred from technical spec §9.
• Audit & Compliance — all governed actions emit immutable audit events. Nurses are not shown audit log data during the workflow; the audit trail is not a nurse-facing surface within this module. Inferred from technical spec §8.
• PMS — appointment progress is synchronised to the PMS via Finish & Send. The PMS integration is invisible to nurses on the tablet surface. Inferred from technical spec §6.2 and §6.3.
• Lab Manager (future) — when enabled, lab case status enrichment appears on AppointmentDayRow components on both surfaces, and a distinct pre-session readiness signal surfaces for unreceipted lab cases. This is an additive overlay; no new navigation surface is introduced. Inferred from technical spec §13.5.
• Inventory & Compliance Manager (future) — when enabled, instrument and consumable context overlays appear on appointment rows and workflow steps. Additive only. Inferred from technical spec §13.5.

UX consistency rules:

• The Decon Wall Tablet must never surface action controls that belong to the Surgery Tablet; any design review that adds an actionable write control to the Decon Wall Tablet is a violation of the separation-of-concerns principle and must be rejected. Inferred from technical spec §4.1 and §13.2 (build rule 2).
• Tooth numbers must be visible as first-class fields on every AppointmentDayRow on both surfaces — they must not be collapsed behind a "more details" control in any surface state. Inferred from technical spec §4.2, §4.3, and build rule 5.
• Nurse attribution (name, not just user ID) must be displayed on all completed records (tray readiness, task completion) on both surfaces for the remainder of the day. Inferred from technical spec §2.1 and §3.2–§3.3.
• All handoffs to Digital Forms must be clearly signposted — the nurse must know they are leaving the Surgery Tablet workflow temporarily and that they will return. Inferred from technical spec §4.3.

11. Governance & Auditability

This module surfaces governance concerns at multiple points in the nurse workflow. The following patterns apply. Inferred from technical spec §8 and §9.

• Named session always visible — the authenticated nurse's name is displayed persistently in the SessionHeader on both tablet surfaces throughout the active session. Nurses are never in doubt about whose session is active. Inferred from technical spec §9 and the attribution principle.
• Completion attribution — every completed tray readiness record and every completed work package task row displays the completing nurse's name and the completion timestamp. Attribution is shown inline, not behind a drill-down. Inferred from technical spec §3.2 and §3.3.
• Irreversible action confirmation — Finish & Send triggers a confirmation modal before submission; this is the single most consequential write action in the module. The confirmation step must clearly describe what will happen (PMS synchronisation, aftercare trigger) and name the authenticated nurse as the actor. Inferred from technical spec §4.3 and §6.2.
• Mandatory form gate visibility — the blocking state for an unsatisfied form gate is surfaced in the appointment header before the nurse reaches the affected workflow step, not only at the point of blocking. Inferred from technical spec §4.3 and build rule 11.
• Blocked task visibility — Blocked tasks receive a distinct visual treatment on both surfaces; a blocked task is never silently hidden or collapsed. Inferred from technical spec §3.5 and build rule 7.
• AI suggestions are visually distinct from user actions (e.g. dotted border, AI badge) — not applicable in MVP scope; placeholder for future AI surface governance.
• Read-only vs editable surfaces — the Decon Wall Tablet is a read-only awareness surface; no write controls appear on it. The Surgery Tablet is the editable surface; write controls are only available to a named, authenticated nurse within an active session. Inferred from technical spec §4.1 and §13.2 (build rule 2).
• Audit log is not nurse-facing — nurses do not see the raw audit log during their workflow; auditability is expressed through visible attribution on completed records, not through an audit log viewer surface within this module. Inferred from technical spec §8.

12. Notification & Communication Patterns

This module does not have a confirmed direct integration with Communication Hub in the MVP technical specification (see Open Question 5 in the technical spec). The following patterns apply within the module's own surfaces. Inferred from technical spec §10 (Communication Hub: no direct integration captured).

• In-app banner — StalenessIndicator — displayed persistently across the top of either tablet surface when the view is showing last-known-good data due to an upstream connectivity issue. Dismissed automatically when live data resumes. Inferred from technical spec §14 (Reliability).
• In-app banner — MandatoryFormGateBanner — displayed in the appointment header on the Surgery Tablet when a mandatory form gate is active. Dismissed when the form gate is satisfied. Inferred from technical spec §4.3 and build rule 11.
• In-app — overdue task indicator — a persistent visual indicator on WorkPackageTaskRow applied when a task's DueTime has passed and the task is not yet Completed. This is not a dismissible notification; it is a state overlay that clears on completion. Inferred from technical spec §3.5 and §13.4.
• Toast — governed write action confirmation — a brief, auto-dismissing toast is shown on successful tray readiness confirmation and on successful task completion, providing clear feedback that the write action was recorded. Inferred from the action-first and calm-by-default principles and the single-tap interaction model described in technical spec §4.3.
• Session termination notice — a brief on-screen notice is displayed immediately before session termination due to inactivity timeout or rota end time, so the nurse is aware their session is closing. Exact timing and copy: (needs UX writer input). Inferred from technical spec §9.
• Push notification / email / SMS — no direct notification transport is confirmed for this module in the MVP technical specification. If overdue task escalation alerts or other out-of-app notifications are required, they must be routed via Communication Hub; this module must not implement its own transport. Inferred from technical spec §10 and §2.2.

13. Open Questions

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

1. Web portal surface — the technical specification does not define a web portal surface for this module (§5.1 is undefined). Is any read-only or management web view in scope for MVP, or is the tablet the only confirmed surface? This must be resolved before the component inventory and primary flows are considered complete. Inferred from technical spec §5.1 and Open Question 6.
2. User-switching trigger — the technical spec requires fast, secure user switching but does not specify the trigger mechanism. Is it a dedicated "switch user" button in the SessionHeader, a badge tap on an active session, or both? This affects the SessionHeader component design. Inferred from technical spec §9.
3. Session termination notice timing and copy — the spec requires a visible notice before session termination on timeout or rota end; the duration and wording of that notice are unspecified. (needs UX writer input — copy and timing for session-ending notice). Inferred from technical spec §9.
4. Finish & Send confirmation modal copy — the confirmation modal for Finish & Send is a governance-critical interaction; exact copy, button labels, and the specific consequences described in the modal need UX writer authoring. (needs UX writer input). Inferred from technical spec §4.3.
5. Overdue indicator visual treatment — the technical spec mandates a distinct overdue visual indicator but does not specify the design. Colour, icon, and label must be defined and must not rely on colour alone. (needs UX writer input — overdue indicator label and design). Inferred from technical spec §3.5 and §13.4.
6. Blocked task visual treatment — the technical spec mandates a distinct visual treatment for Blocked tasks but does not specify it. Must be designed to be immediately distinguishable from Overdue. (needs UX writer input). Inferred from technical spec §3.5 and build rule 7.
7. Communication Hub integration — whether any out-of-app notification (e.g. overdue task escalation) is in scope for MVP is unresolved. If confirmed, notification content and triggers need UX definition. Inferred from technical spec Open Question 5.
8. Inactivity timeout default and range — the configurable timeout value is not specified in the technical spec. The UX must accommodate the full permitted range; if the minimum timeout is very short, the session-termination notice timing is affected. Inferred from technical spec Open Question 1.
9. Decon Wall Tablet authentication frequency — the wall-mounted Decon Wall Tablet requires authenticated sessions, but the expected interaction pattern for a wall-mounted awareness display is different from the Surgery Tablet. Is the auth model (badge tap, PIN, QR) identical on both surfaces, or does the Decon Wall Tablet have a different session length expectation? Inferred from technical spec §4.2 and §9.
10. 4-tray lookahead — confirmation of scope — the technical spec notes that the Decon Wall Tablet "MAY" emphasise the next four upcoming appointments prominently. Is this confirmed for MVP or optional? The component design (and what constitutes "prominent" emphasis) should be pinned before build. Inferred from technical spec §4.2.