Staff App Mode – UX Specification

Related Technical Authority: Staff App Mode – Technical Specification

1. Purpose

This UX specification governs the staff-facing mobile experience within Primoro. It defines how authenticated staff members access role-relevant information, submit requests, coordinate with colleagues, and act on tasks — all within a secure, auditable surface that is entirely separate from the patient-facing app. The primary roles served are Clinician, Nurse/Support Staff, Reception/Front-of-house, Treatment Coordinator, and Manager/Admin, as provisioned via Access Manager.

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
• Work–life boundary respect — the interface never surfaces non-urgent demands outside a staff member's rostered hours; quiet-hours enforcement is invisible to the user unless they are specifically informed a message was suppressed. Inferred from technical spec §6.
• Role-scoped clarity — each staff member sees only the information and actions permitted for their role and assigned site(s); the interface never exposes data that Access Manager has not granted. Inferred from technical spec §9 and §2.1.
• Staff/patient mode integrity — the visual and interaction model makes it structurally impossible for a patient user to encounter the staff surface; the activation path is deliberately non-discoverable. Inferred from technical spec §4.1 and §13.2 rule 1.

3. Design Philosophy

Staff App Mode is a surface layer, not a system of record. Its design stance is one of faithful, role-scoped presentation: it renders what the underlying modules own, enables staff to act, and records those actions — it does not author data independently. Inferred from technical spec §1.

Empty states — when a queue, feed, or list is genuinely empty (no tasks, no messages, no pending requests), the interface should communicate that positively: the staff member is up to date. Empty states are never silent blanks; they confirm the absence of outstanding work. Inferred from technical spec §5.2 which requires overdue and unacknowledged items to be surfaced prominently, implying the inverse must also be communicated clearly.

Error states — errors are attributed to a cause where possible (connectivity, permission, integration failure) and always offer a concrete recovery path. The interface never strands a user in a broken state without guidance.

AI suggestions — AI surfaces (Aiden) present guidance and next-action recommendations as clearly labelled suggestions, never as completed actions. Staff retain full agency; the suggestion is a prompt, not a decision. Inferred from technical spec §7. A suggestion that has been dismissed should not resurface in the same session.

Multi-step flows — Structured request submissions and assisted form completions are multi-step flows with visible progress; staff can review before submitting, and mandatory fields are enforced throughout. Inferred from technical spec §5.4 and §5.6. Submission is always a deliberate final step, never triggered by navigating away.

Undo/redo — Because audit logs are immutable and request state transitions are governed, there is no undo once a submission is confirmed. The confirmation step before irreversible actions (such as submitting a request or recording a document acknowledgement) is the primary safeguard. Inferred from technical spec §3.4 and §5.5.

Read-only vs editable — Rota data is always presented in a visually read-only treatment; there are no edit controls on rota views. Documents surfaced for acknowledgement are read-only; only the acknowledgement action is interactive. Inferred from technical spec §5.3 and §5.5.

4. Primary Surfaces

4.1 Web Portal

Staff App Mode is a mobile-first module; there is no dedicated web portal surface defined in the technical spec. Practice-level configuration (role permissions, quiet hours, request types, document visibility, MFA, feed moderation) is managed via the Admin Control Plane, which is a separate surface not owned by this module. Inferred from technical spec §13.3.

Who uses it: Not applicable for this module's primary surfaces. Configuration is handled via Admin Control Plane (out of scope for this spec).

Key tasks performed here: N/A — see §4.3 for the primary staff surface.

4.2 Tablet App

The technical spec does not define a separate tablet surface; however, the assisted form completion capability (§5.6) is explicitly described as occurring "in surgery and at the point of care", which implies tablet usage at the chairside or consultation desk. The tablet surface shares the same mobile app codebase but must be ergonomically tested at tablet form factor.

Who uses it: Clinical staff (Clinician, Nurse/Support Staff) guiding patients through form completion at the point of care. Inferred from technical spec §5.6.

Key tasks performed here:

• Guided patient form completion — staff guides patient through a structured, step-by-step form flow; mandatory items enforced throughout. Inferred from technical spec §5.6.
• Assisted form submission on behalf of a patient, with attribution recorded in the audit trail. Inferred from technical spec §5.6.
• Signature capture within the form flow. Inferred from technical spec §5.6.
• Review of submitted or in-progress forms for authorised roles. Inferred from technical spec §5.6.
• Accessing and completing assigned learning lessons where a staff member has an active authenticated session on the tablet. Inferred from Knowledge, Training & Learning UX §4.2 and §4.3.

Touch ergonomics: Glove-friendly tap targets ≥48 px; one-handed reachability for primary actions where possible; all interactive controls ≥44×44 px. Assisted form flows must be operable by a staff member holding a device and navigating on behalf of a patient — single-thumb progression through form steps is preferred. Inferred from the point-of-care context described in technical spec §5.6. These ergonomic requirements apply equally to lesson completion controls surfaced on tablet, consistent with Surgery & Decon Day View's authenticated nurse session model and glove-friendly design expectations.

4.3 Mobile App (Staff)

This is the primary surface for Staff App Mode. It is a staff-only authenticated mobile app, distinct from the patient-facing app surface. Access is via a hidden activation gesture not discoverable by patients. Inferred from technical spec §1 and §4.1.

Who uses it: All staff roles — Clinician, Nurse/Support Staff, Reception/Front-of-house, Treatment Coordinator, Manager/Admin — on their personal or practice-issued mobile devices. Locums authenticate via local Primoro credentials. Inferred from technical spec §4.1 and §9.

Key tasks performed here:

• Viewing the personal role-scoped dashboard (Smart Dashboards is the default post-login landing surface). Inferred from technical spec §13.2 rule 13 and §10.
• Reading and sending secure messages, participating in group chats and channels, viewing announcements and praise. Inferred from technical spec §5.1.
• Acknowledging messages and updates. Inferred from technical spec §5.1.
• Viewing personal rota and upcoming shifts; viewing day lists (clinicians and nurses). Inferred from technical spec §5.3.
• Viewing and acting on personal and role-based task queues; claiming tasks; executing checklists with notes, comments, and photo/file evidence. Inferred from technical spec §5.2.
• Submitting structured requests — holiday, sickness, shift swap, expenses (with receipt attachment), errands, ideas, anonymous feedback. Inferred from technical spec §5.4.
• Tracking the status of submitted requests. Inferred from technical spec §3.4 and §5.4.
• Accessing policies and internal documents; uploading documents; actioning document acknowledgement prompts. Inferred from technical spec §5.5.
• Receiving and reviewing AI (Aiden) guidance, at-risk work signals, and next-action suggestions. Inferred from technical spec §7 and §10.
• Accessing and completing assigned learning lessons and pathways within the app during on-shift hours. Inferred from Knowledge, Training & Learning UX §4.3.

5. Interaction Model

5.1 Primary Flows

Flow 1 — Staff mode entry and authentication

Inferred from technical spec §4.1 and §4.2.

User opens the app (patient-facing surface visible by default)
  │
  ▼
User performs hidden activation gesture
  │
  ▼
Authentication screen presented
  ├─ SSO (Microsoft / Google / Azure AD) if configured
  ├─ MFA challenge (if configured by practice)
  └─ Local Primoro login (locums and non-SSO staff)
  │
  ▼
Authentication successful → StaffSession created (Active)
  │
  ▼
Smart Dashboards landing surface rendered (role-scoped)

Flow 2 — Session lock and re-authentication

Inferred from technical spec §3.2 and §4.2. Session lifecycle — including idle timeout thresholds, immediate force-logout on account suspension or revocation, and the non-dismissible session-ended screen — is governed by Access Manager (§4.3) and the Security and Privacy module's session management policy. Staff App Mode renders the outcomes of these decisions; it does not own the timeout or revocation logic itself. Security and Privacy mandates that the session-ended screen presented on automatic logout (whether from inactivity or rota end) is non-dismissible — the staff member must re-authenticate to regain access; they cannot return to the previous view.

Session Active
  │
  ├─ [Inactivity timeout reached — threshold governed by Access Manager] → Session moves to Locked
  │       │
  │       ▼
  │   Re-authentication screen (PIN or biometric)
  │       ├─ Success → Session returns to Active
  │       └─ Failure → Re-prompt (platform-defined attempt limit applies)
  │
  ├─ [Rota end / shift boundary reached — governed by Rota Manager + Security-Privacy policy]
  │       │
  │       ▼
  │   Automatic logout → Non-dismissible session-ended screen presented
  │       └─ Staff member must re-authenticate to resume
  │
  └─ [Server-side revocation by Access Manager — e.g. account suspended] → Session moves to Terminated
          │
          ▼
      Non-dismissible signed-out state; staff member cannot resume session
      without administrator reinstatement

Flow 3 — Submitting a structured request

Inferred from technical spec §5.4 and §3.4.

Staff member opens Requests section
  │
  ▼
Selects request type (Leave | Sickness | Expense | Swap | Errand | Idea | Anonymous)
  │
  ▼
Completes structured form
  │  ├─ Expense: receipt attachment step included
  │  └─ Anonymous: submitter identity withheld from all reviewers
  │
  ▼
Review screen — staff confirms submission details
  │
  ▼
Submit → StaffRequest created (Status: Submitted)
  │
  ▼
Confirmation displayed; request visible in request history with status tracking
  │
  ▼
Manager acknowledges → Status: Under Review → Status: Resolved
  └─ (or) Submitter or manager cancels → Status: Cancelled

Flow 4 — Task queue and checklist execution

Inferred from technical spec §5.2. Task delivery respects quiet-hours and availability boundaries — see §5.2 State Machines for the quiet-hours alignment contract.

Staff member opens task queue (personal or role-based)
  │
  ▼
Views tasks sorted by urgency and overdue status
  │
  ▼
Selects a task → Task detail view
  │
  ▼
Claims / acknowledges task
  │
  ▼
Executes associated checklist
  │  ├─ Adds notes / comments
  │  └─ Attaches photo or file evidence
  │
  ▼
Marks task complete → Evidence stored in Task Manager; action logged in audit trail

Flow 5 — Document acknowledgement

Inferred from technical spec §5.5.

Pending acknowledgement prompt surfaced on dashboard (prominently)
  │
  ▼
Staff member opens document
  │
  ▼
Reads document content (read-only)
  │
  ▼
Acknowledgement prompt presented
  │
  ▼
Staff member confirms reading → Confirmation recorded (user, role, site) in Document Hub
  │
  ▼
Pending prompt dismissed from dashboard
  │
  (On document update/supersession)
  │
  ▼
Prior acknowledgement automatically reset → Pending prompt re-appears on dashboard

Flow 6 — Assisted form completion (point of care)

Inferred from technical spec §5.6.

Authorised staff member initiates assisted form completion
  │
  ▼
Selects patient and form
  │
  ▼
Guided step-by-step form flow
  │  ├─ Mandatory items enforced (cannot be bypassed)
  │  └─ Signature capture step included
  │
  ▼
Review screen before submission
  │
  ▼
Submit → Submission attributed to assisting staff member in audit trail
         Form ownership and storage pass to Digital Forms

Flow 7 — Communication Hub in-surface messaging and thread actions

Inferred from technical spec §5.1 and Communication Hub UX §1. Communication Hub threads, channels, and message-to-work conversion actions are rendered inside Staff App Mode; the staff member never leaves the app to interact with Communication Hub directly. All read/write actions on messages, channels, and announcements are scoped to the staff member's active role and site, consistent with the role-scoped clarity principle.

Staff member opens Messages section (within Staff App Mode)
  │
  ▼
Reads channel list / direct message threads (sourced from Communication Hub)
  │
  ├─ [Sending a message]
  │       │
  │       ▼
  │   Compose view → Send → Message delivered via Communication Hub routing
  │       └─ Offline: message queued, staff member informed of pending delivery state
  │
  ├─ [Message-to-work conversion — where role permits]
  │       │
  │       ▼
  │   Conversion action surfaced inline on message → Staff member initiates conversion
  │       └─ Converted item (e.g. task, request) created in relevant module; confirmation displayed
  │
  └─ [Acknowledging a message or announcement]
          │
          ▼
      Acknowledgement recorded via Communication Hub; confirmation toast displayed

Flow 8 — Assigned learning lesson access

Inferred from Knowledge, Training & Learning UX §4.2 and §4.3. Learning content is rendered inside Staff App Mode; the staff member does not navigate to a separate Learning module surface. Lesson completion is recorded against the staff member's identity in the Knowledge, Training & Learning module.

Staff member opens Learning section (within Staff App Mode)
  │
  ▼
Views assigned learning pathways and outstanding lessons
  │
  ▼
Selects a lesson → Lesson content rendered in-surface
  │
  ▼
Completes lesson (steps enforced; mandatory items cannot be bypassed)
  │
  ▼
Completion confirmed → Progress recorded in Knowledge, Training & Learning module
                       Confirmation toast displayed

Flow 9 — Session coordination with Surgery & Decon Day View tablets

Inferred from Surgery & Decon Day View UX and technical spec §4.1. Where a nurse or clinical staff member has an active authenticated session on a Surgery & Decon Day View tablet, that session is distinct from their Staff App Mode mobile session — each surface maintains independent session state. Governance attribution is consistent: editable controls on the day-view tablet are visible only when a nurse has an active session on that device, mirroring Staff App Mode's principle that audit-significant actions are always attributable to an authenticated, identified staff member.

The quiet-hours contract is applied consistently: a nurse's availability state (as governed by Rota Manager) applies across both the tablet day-view session and their Staff App Mode mobile session. Task and notification delivery to both surfaces respects the same shift boundaries. (needs confirmation from engineering on whether session revocation on one surface affects the other)

5.2 State Machines (Mirror of Technical Spec §3)

StaffSession states

Inferred from technical spec §3.2 and Access Manager §4.3. Session lifecycle transitions are governed by Access Manager; Staff App Mode renders the resulting states.

The Locked state must visually obscure all practice data — no content should be readable through the lock screen. Inferred from technical spec §4.1 security requirements.

A Terminated session resulting from server-side revocation by Access Manager must present a clear, non-alarming, non-dismissible message explaining the session has ended, without disclosing the reason. A Terminated session resulting from rota-end automatic logout (as governed by the Security and Privacy session management policy) uses the same non-dismissible treatment. Inferred from technical spec §3.2, Security and Privacy UX §4.2, and access revocation rules in §9. (needs UX writer input — exact message copy for each termination cause)

Smart Dashboards as the post-login landing surface

Smart Dashboards is the default home view for all authenticated staff roles immediately after login on the mobile surface. Inferred from Smart Dashboards §4.3 and technical spec §13.2 rule 13. The dashboard renders role-scoped cards and alert signals sourced from Smart Dashboards; the staff member lands here on every successful authentication, including re-authentication after a Locked session.

Quiet-hours constraints interact with dashboard display as follows: urgent signals (e.g. high-priority task alerts, urgent announcements) are surfaced on the dashboard regardless of shift state, consistent with the Notification.Urgency = Urgent delivery rule. Normal-urgency signals are suppressed off-shift and appear on the dashboard only when the staff member's shift is active. On shift return, the suppression queue banner is surfaced as an in-app banner above the dashboard card grid before the staff member reviews their queued notifications. Inferred from technical spec §6 and Smart Dashboards §4.3.

Quiet-hours and task delivery alignment

Task Manager defines tasks as calendar-backed items tied to shift and availability windows. When Task Manager delivers tasks or callbacks to a staff member via Staff App Mode, the delivery timing must respect Staff App Mode's quiet-hours contract with Rota Manager. Specifically:

• Normal-urgency task notifications MUST NOT be delivered to a staff member's device outside their rostered shift hours, consistent with the quiet-hours suppression rule. Inferred from technical spec §6 and Task Manager's availability-aware delivery model.
• Urgent task notifications bypass quiet-hours suppression and are delivered immediately, regardless of shift state. This is consistent with the Notification.Urgency = Urgent rule across all notification types.
• Tasks that arrive during off-shift hours are queued and surfaced in the in-app notification inbox at the start of the staff member's next shift, alongside other suppressed notifications. The task queue itself reflects all outstanding tasks at the point the staff member opens it — the quiet-hours contract governs notification delivery only, not task visibility once the staff member is active in-app. Inferred from technical spec §6 and §14.

StaffRequest states

Inferred from technical spec §3.4.

The transition from Submitted to Under Review and from Under Review to Resolved are irreversible from the submitter's perspective. The UI must make it clear that cancellation is the only available reversal before the Resolved state is reached. Inferred from technical spec §3.4.

Anonymous requests must display no submitter identity in any state visible to a reviewing manager. The UI must structurally suppress this field — not simply hide it conditionally. Inferred from technical spec §3.4 and §13.2 rule 11.

5.3 Empty / Loading / Error / Offline States

Task queue

• Empty: Positive confirmation that no tasks are outstanding or overdue. Inferred from the prominence requirement for overdue items in technical spec §5.2 — the inverse must also be communicated. (needs UX writer input — e.g. message copy and illustration)
• Loading: Skeleton list items whilst task data is fetched from Task Manager.
• Error: Inline error indicating that task data could not be loaded, with a retry action. Inferred from integration dependency on Task Manager in technical spec §10. (needs UX writer input — error message copy)
• Offline: Cached task data surfaced where available, clearly labelled as potentially stale. New task actions (claim, acknowledge) queued for submission on reconnect; the user is informed of this. Inferred from technical spec §14 reliability requirement. (needs UX writer input — staleness label copy)

Message feed / chats / channels

• Empty: (needs UX writer input — e.g. onboarding prompt copy for empty chat state)
• Loading: Skeleton message rows.
• Error: Inline error with retry; no silent failure. Inferred from audit requirement that message send/receive is logged — a failed send must be surfaced, not silently dropped. Inferred from technical spec §8.
• Offline: Previously received messages readable from cache. Send queue held and retried on reconnection; the user is shown that a message is queued, not yet delivered. Inferred from technical spec §14.

Rota view

• Empty: Clear statement that no shifts are scheduled for the visible period. Inferred from read-only rota surface described in technical spec §5.3. (needs UX writer input)
• Loading: Skeleton calendar or list rows.
• Error: Inline error; no edit controls are ever shown, so no risk of a staff member attempting to modify a broken state. Inferred from read-only constraint in technical spec §5.3.
• Offline: Last-fetched rota data shown with a last-updated timestamp; clearly labelled as cached. Inferred from technical spec §14.

Document acknowledgement prompts

• Empty (no pending acknowledgements): Dashboard section absent or collapsed; no false urgency. Inferred from the prominence requirement only applying when acknowledgements are outstanding — technical spec §5.5.
• Loading: Skeleton prompt card.
• Error: Prompt card shows a failed-to-load state with retry; acknowledgement cannot be recorded until document is successfully rendered. Inferred from technical spec §5.5 requirement that staff read the document before acknowledging.
• Offline: Acknowledgement action disabled offline; staff member informed they must be connected to record a confirmation. The document content itself, if cached, may still be readable. Inferred from the requirement that acknowledgements are recorded back to Document Hub — technical spec §5.5.

Request submission flow

• Empty (no prior requests): (needs UX writer input — e.g. prompt copy encouraging first submission)
• Loading: Skeleton request history list.
• Error in submission: Form submission failure surfaced inline with a specific error (e.g. connectivity, validation) and a clear retry or save-draft path. Inferred from multi-step form flow and audit requirements in technical spec §5.4 and §8.
• Offline: Form completion may proceed offline; submission is queued and the staff member is clearly informed the request will be sent when connectivity is restored. Inferred from technical spec §14 reliability requirement.

Learning lessons

• Empty (no assigned lessons): Positive confirmation that no lessons are outstanding. (needs UX writer input — e.g. message copy)
• Loading: Skeleton lesson list.
• Error: Inline error with retry; lesson completion cannot be recorded if the lesson content fails to render. (needs UX writer input — error message copy)
• Offline: Lesson content unavailable offline unless explicitly cached; staff member informed that lesson access requires connectivity. (needs confirmation from Knowledge, Training & Learning module on offline caching policy)

6. Component Inventory

New components introduced or extended by this module:

• Hidden staff mode entry trigger — the activation gesture surface that transitions the app from patient mode to staff authentication. Not visible as a labelled UI element. Inferred from technical spec §4.1. (needs UX writer input — exact gesture definition is an open question; see §13)
• StaffSession lock screen — full-screen overlay presented on session inactivity; accepts PIN or biometric re-authentication. Non-dismissible when the session has been auto-terminated (by Access Manager revocation or rota-end automatic logout). Inferred from technical spec §3.2, §4.2, and Security and Privacy UX §4.2.
• Structured request submission form — multi-step form with type selector (Leave | Sickness | Expense | Swap | Errand | Idea | Anonymous), field sets per type, receipt attachment for expenses, and review-before-submit screen. Anonymous type suppresses submitter identity field. Inferred from technical spec §5.4 and §3.3.*
• Request status tracker — read-only view of a submitted StaffRequest showing current state (Submitted | Under Review | Resolved | Cancelled) with state badge and timestamps. Inferred from technical spec §3.4.*
• Document acknowledgement prompt card — prominent surfaced card on the dashboard and within the documents section; presents the document for reading (read-only) followed by a confirmation action; dismissed only on explicit acknowledgement. Resets automatically on document update. Inferred from technical spec §5.5.*
• Quiet-hours suppression notice — in-app indicator surfaced when the staff member returns to shift, showing notifications that were suppressed during off-shift hours. Inferred from technical spec §6.*
• AI suggestion card (Aiden) — visually distinct card presenting role-aware guidance, at-risk work alerts, or next-action suggestions; labelled as AI-generated; includes accept and dismiss controls; dismiss is final within the session. Inferred from technical spec §7 and §10.*
• Checklist executor — interactive checklist within a task detail view; supports note entry, comment entry, and photo/file attachment per checklist item; evidence is stored against the task record in Task Manager. Inferred from technical spec §5.2.*
• Assisted form completion flow — structured guided form presentation optimised for staff-guided patient completion at the point of care; enforces mandatory fields; includes signature capture step; attributes submission to the assisting staff member. Inferred from technical spec §5.6.*
• Learning lesson viewer — in-surface lesson content renderer for assigned learning pathways; enforces mandatory step progression; records completion against the staff member's identity in Knowledge, Training & Learning. Glove-friendly tap targets ≥48 px apply. Inferred from Knowledge, Training & Learning UX §4.2 and §4.3.*

Reused from the design system:

• Secure message thread (rendered via Communication Hub primitives). Inferred from technical spec §5.1.
• Announcement card (rendered via Communication Hub). Inferred from technical spec §5.1.
• Task queue list item. Inferred from technical spec §5.2.
• File/photo attachment picker. Inferred from technical spec §5.2 and §5.6.
• Role and site badge (displayed in session header). Inferred from technical spec §9.
• Dashboard card grid (sourced from Smart Dashboards). Inferred from technical spec §10.
• Toast notification component. Inferred from notification delivery requirements in technical spec §3.5.
• Skeleton loader. Inferred from loading state requirements.

7. Visual Design Notes

• Typography: (needs UX writer input — heading scale, body scale, and monospace usage to be defined by the design system)
• Colour: Semantic colour usage must distinguish: session-locked state (neutral/obscuring overlay), AI suggestion cards (visually distinct from human-authored content — e.g. a consistent AI badge or border treatment), request status badges (four states: Submitted, Under Review, Resolved, Cancelled), urgent vs normal notifications, and pending acknowledgement prompts (elevated prominence). Exact colour values are design-system decisions. Inferred from governance and state-machine requirements in technical spec §3, §6, and §7. (needs UX writer input — specific semantic colour tokens)
• Iconography: Icon set to be defined; sizing per design system; never icon-only without a visible or screen-reader label. Request type icons (if used) must be distinguishable and labelled; anonymous request type must carry no iconography that could imply identity. Inferred from technical spec §3.3.
• Motion: Motion is used only where it aids comprehension of state change; nothing is animated for decoration. All motion respects prefers-reduced-motion. The session lock transition (Active → Locked) should use a clear, non-jarring cover animation to indicate the screen is secured. Inferred from technical spec §3.2. (needs UX writer input — specific transition style)

8. Accessibility & Inclusivity

The module MUST meet WCAG 2.2 AA. Specifically:

• Text contrast ≥4.5:1 (normal) / ≥3:1 (large)
• All interactive controls reachable via keyboard
• Focus states visible
• Form fields have programmatic labels
• ARIA used only where native semantics are insufficient
• Touch targets ≥44×44 px on mobile/tablet
• Motion can be reduced via prefers-reduced-motion
• Screen reader tested on NVDA / VoiceOver / TalkBack

The document acknowledgement flow must be fully operable via screen reader; the distinction between reading the document and activating the acknowledgement control must be clear in the accessibility tree. Inferred from technical spec §5.5.

The anonymous feedback request type must not expose any input fields that could inadvertently collect identifying information (e.g. auto-filled name fields). The form must be audited for inadvertent identity leakage via autofill or assistive technology. Inferred from technical spec §3.4 and §14 privacy requirement.

The AI suggestion card's accept and dismiss controls must be reachable via keyboard and screen reader, and must be distinguishable from standard action buttons. Inferred from the governance visibility principle and technical spec §7.

Checklist items with photo/file attachment must provide accessible alternatives for staff who cannot use camera capture (e.g. file upload from device storage). Inferred from technical spec §5.2.

The non-dismissible session-ended screen (presented on forced logout or rota-end automatic logout) must be fully accessible — it must not trap keyboard focus in a way that prevents the staff member from reaching the re-authentication control. Inferred from Security and Privacy UX §4.2.

9. Internationalisation

• Locale-aware date/time/number formatting
• All user-facing strings externalised
• Layouts tolerant of 30% string-length growth (German, French)
• RTL support: required — the module must not hard-code LTR layout assumptions

Rota times and shift times surfaced in the app must use the locale-aware time format configured for the practice (24-hour vs 12-hour), consistent with how Rota Manager surfaces the same data. Inferred from technical spec §5.3.

Request type labels and document acknowledgement copy must be fully externalisable; no hard-coded strings in request type selectors or acknowledgement prompts. Inferred from technical spec §5.4 and §5.5.

10. Cross-Module UX Touchpoints

Where this module's UX intersects with related modules:

• Communication Hub — the staff member sends and receives messages, reads announcements, and gives or receives acknowledgements within Staff App Mode; the rendering surface is owned here, but routing and delivery are owned by Communication Hub. The staff member never leaves Staff App Mode to interact with Communication Hub directly — it is rendered in-surface. Message-to-work conversion actions (where role-permitted) are also surfaced inline within the message thread without navigating away. Inferred from technical spec §5.1, §10, and Communication Hub UX §1.
• Task Manager — task queues and checklists are rendered inside Staff App Mode; task acknowledgements and checklist evidence are emitted back to Task Manager. The staff member acts on tasks without being redirected to a separate Task Manager surface. Task delivery timing respects Staff App Mode's quiet-hours contract with Rota Manager — see §5.2 for the quiet-hours and task delivery alignment contract. Inferred from technical spec §5.2 and §10.
• Rota Manager — shift and day-list data is rendered read-only inside Staff App Mode; the staff member has no transition path to Rota Manager from this surface. Quiet hours enforcement is invisible to the staff member — it operates silently in the background. Where a notification was suppressed, the staff member learns about it via the suppression queue on shift return, not by interacting with Rota Manager directly. Inferred from technical spec §5.3, §6, and §10.
• Appointment Manager — day awareness signals are consumed and contribute to the dashboard and day-list views; the staff member does not navigate to Appointment Manager from this surface. Inferred from technical spec §10.
• Digital Forms — the assisted form completion flow is rendered inside Staff App Mode; on submission, form ownership passes to Digital Forms. The staff member does not navigate away from Staff App Mode to complete or submit a form. Inferred from technical spec §5.6 and §10.
• Document Hub — documents are surfaced and acknowledgement prompts are presented inside Staff App Mode; acknowledgement confirmations are emitted back to Document Hub. The staff member does not navigate to Document Hub directly from this surface. Inferred from technical spec §5.5 and §10.
• Smart Dashboards — the default post-login landing surface for all authenticated staff roles; dashboard cards and alert signals are sourced from Smart Dashboards and rendered inside Staff App Mode. The staff member lands here on every login. Quiet-hours constraints on dashboard signal display are described in §5.2. Inferred from technical spec §10, §13.2 rule 13, and Smart Dashboards §4.3.
• Access Manager — RBAC, role assignments, session timeout thresholds, and session revocation are governed here; Staff App Mode consumes these silently. When a session is force-terminated by Access Manager (e.g. account suspended), the staff member sees a non-dismissible signed-out state in Staff App Mode. The staff member does not interact with Access Manager directly from the app. Inferred from technical spec §9, §10, and Access Manager §4.3.
• AI Assistant (Aiden) — AI suggestions are surfaced as clearly labelled cards within Staff App Mode; the staff member accepts or dismisses them without leaving the current view. The AI badge on these cards is the primary cross-module visual signal. Inferred from technical spec §7 and §10.
• Knowledge, Training & Learning — assigned learning pathways and lessons are surfaced inside Staff App Mode; lesson completion is recorded back to the Knowledge, Training & Learning module. The staff member does not navigate to a separate learning surface. Inferred from Knowledge, Training & Learning UX §4.2 and §4.3.
• Surgery & Decon Day View — where clinical staff hold concurrent authenticated sessions on both a Staff App Mode mobile device and a Surgery & Decon Day View tablet, each session is independent. Governance attribution and audit trail entries are consistent across both surfaces. The availability/quiet-hours state derived from Rota Manager applies equally to both. Inferred from Surgery & Decon Day View UX and technical spec §4.1.

UX consistency rules:

• Data sourced from an external module (Task Manager, Rota Manager, Document Hub, etc.) must be visually attributable to its source where this aids staff comprehension — e.g. a subtle source label or icon on cards — but must not clutter the primary action. Inferred from the surface-layer nature of the module described in technical spec §1.
• AI suggestion cards must use a consistent visual treatment (badge, border, or label) that is identical across all surfaces where Aiden appears in the platform, to establish recognition. Inferred from technical spec §7 and the governance-always-visible principle.
• Read-only data (rota, document content) must use a visually consistent read-only treatment throughout the app — the same treatment used in other read-only surfaces across the platform. Inferred from technical spec §5.3 and §5.5.

11. Governance & Auditability

Every action a staff member takes within this surface is captured in an immutable audit trail. The UI should reinforce this implicitly — confirmation steps before irreversible actions, attribution displayed on submissions, and no silent failures. Inferred from technical spec §8.

• AI suggestions (from Aiden) are visually distinct from system notifications and from staff-authored content; they carry a persistent AI label and are never styled to appear as practice decisions or instructions. Inferred from technical spec §7.
• Audit-significant actions — submitting a request, recording a document acknowledgement, completing a checklist, submitting an assisted form, completing a learning lesson — each show a review-and-confirm step before finalisation. Inferred from technical spec §8.
• The current staff member's role and active site are visible in the session header at all times, giving them continuous awareness of the context under which they are acting. Inferred from technical spec §9.
• Read-only surfaces (rota, document content) are visually distinct from editable or actionable surfaces — no edit controls appear on read-only content, and the visual treatment (e.g. no input affordances, locked iconography) makes this unambiguous. Inferred from technical spec §5.3 and §5.5.
• Where a staff member assists a patient with form completion, the form view displays a clear attribution indicator showing that this submission will be recorded against the staff member's identity. This is presented before the final submission step. Inferred from technical spec §5.6.
• Audit log export — authorised practice administrators can access and export audit logs; this capability is surfaced via the Admin Control Plane, not within the staff mobile app. Inferred from technical spec §8 and §13.3.

12. Notification & Communication Patterns

Notification delivery in this module is governed by rota-aware quiet hours. All push notifications are delivered via Communication Hub, not directly. Inferred from technical spec §6 and §2.2.

• In-app banner — used to surface the quiet-hours suppression queue when a staff member returns to shift; presents a count of notifications suppressed during off-shift hours, with an action to review them. Also used to surface urgent connectivity-loss warnings (offline state). Inferred from technical spec §6 and §14.
• Toast — used for transient confirmations: successful request submission, successful document acknowledgement, successful task action, successful message send, successful lesson completion. Toasts are brief and do not require dismissal. Inferred from the audit confirmation requirement in technical spec §8 — the staff member should have immediate positive feedback that an auditable action was recorded.
• Push notification (via Communication Hub) — used for incoming messages, urgent announcements, and task alerts. Urgency level (Normal | Urgent) maps directly to the Notification.Urgency field in the data model. Normal-urgency push notifications are suppressed off-shift by rota-aware quiet hours; Urgent notifications are delivered regardless of shift state. Inferred from technical spec §3.5 and §6.
• In-app notification inbox — suppressed Normal-urgency notifications are not lost; they are queued and surfaced in-app when the staff member's next shift begins. The inbox distinguishes between delivered and suppressed-then-queued items. Inferred from technical spec §6.
• Document acknowledgement prompt (dashboard card) — pending acknowledgements are surfaced as a prominent card on the Smart Dashboards landing surface. This is a persistent prompt, not a toast, and remains until the acknowledgement is confirmed. Inferred from technical spec §5.5.
• Email/SMS (via Communication Hub) — where practice configuration routes certain notifications to email or SMS, this is handled entirely by Communication Hub; Staff App Mode does not implement direct email or SMS delivery. Inferred from technical spec §2.2 and §10.

13. Open Questions

The following questions must be resolved before this spec is promoted from draft to published. Items marked with * are carried forward from the technical spec's own open questions (technical spec §15).

1. What is the precise definition of the hidden activation gesture for staff mode entry — swipe pattern, tap sequence, or other mechanism — and is it configurable per practice or fixed platform-wide? This directly determines the design of the entry trigger component. (Technical spec §15, question 6)*
2. What are the specific session inactivity timeout values for auto-lock? Are these configurable at the practice level (Admin Control Plane) or fixed? This affects the pre-lock warning design and copy. (Technical spec §15, question 1)*
3. For multi-site staff, is site context driven automatically by the active shift (from Rota Manager), or does the staff member manually select a site within the app? This determines whether a site-selector control is needed. (Technical spec §15, question 5)*
4. What is the platform-level data retention policy for audit logs and StaffRequest records? This affects how (or whether) the UI surfaces historical requests beyond a certain age. (Technical spec §15, question 3)*
5. Are document acknowledgement requirements configured entirely within Document Hub, or does Staff App Mode expose any local configuration toggle for acknowledgement behaviour? (Technical spec §15, question 4)*
6. What is the pre-lock warning pattern — does the app warn a staff member before auto-locking (e.g. "You will be locked out in 60 seconds"), and if so, what is the timing and dismissal behaviour? (needs UX writer input and engineering confirmation)
7. What is the visual treatment that distinguishes the AI suggestion card from a standard system notification or dashboard card? The specific badge, border, or label pattern needs to be defined consistently with the AI Assistant (Aiden) design system presence across the platform.
8. What happens to an in-progress structured request form if the app moves to the Locked or Terminated state mid-flow — is draft content preserved, discarded, or submitted? The recovery path needs defining.
9. For the assisted form completion flow on tablet, is there a separate "handback" step — a moment where the tablet transitions from staff-navigated to patient-facing for signature capture — and if so, how is this surfaced?
10. What is the specific latency target for login and dashboard load? This determines the loading state design and acceptable skeleton duration. (Technical spec §15, question 2)
11. Does a session revocation by Access Manager on a staff member's mobile device also terminate any concurrent authenticated session that staff member holds on a Surgery & Decon Day View tablet, or are the two sessions managed independently? This determines whether the staff member must re-authenticate on both surfaces separately.
12. What is the offline caching policy for learning lesson content within Staff App Mode? Does the Knowledge, Training & Learning module permit lesson content to be cached for offline viewing, and if so, can completion be recorded offline and synced on reconnection?