Rota Manager – UX Specification

Related Technical Authority: Rota Manager – Technical Specification

1. Purpose

This UX specification governs the user experience of the Rota Manager module across the web portal and staff-facing surfaces of the Primoro platform. It defines how managers create and maintain recurring availability patterns, how generated rota entries are read and overridden, and how absence exceptions are surfaced — so that every downstream consumer, from Appointment Manager to Surgery & Decon Day View, receives reliable, explicitly-defined availability data. The primary roles it serves are practice managers and group-practice administrators responsible for scheduling, with a secondary read-only audience of clinical and operational staff who need visibility of their own and their team's working patterns.

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.

Pattern-first, exceptions second — the UI foregrounds recurring schedule patterns as the primary artefact; date-specific entries and overrides are always subordinate and clearly labelled as derived or exceptional. Inferred from the technical spec's Section 1 and Section 3.1, which establish Schedule Patterns as the authoritative availability artefact.

Availability is explicit, never inferred — no rota entry exists unless a pattern or manual override created it. Empty states communicate absence of availability, not an error. Inferred from the technical spec's core behaviour rule 1: "No pattern → no availability."

Role-based, not treatment-based — the UI never surfaces treatment types, appointment reasons, or clinical procedures within any rota or pattern editing surface. Inferred from the technical spec's Section 2.2 and Section 11, which explicitly exclude treatment-type logic from this module.

Separation of authority is legible — the boundary between what Rota Manager owns (when and in which role a person works) and what Appointment Manager decides (whether a slot is bookable) is made visible to users who might otherwise conflate the two. Inferred from the technical spec's Sections 2.1–2.2 and Section 11.

AI is advisory, never decisive — any AI-generated suggestion is visually distinct from system-generated data and user-authored data. Users must take an explicit action to accept an AI suggestion before it affects any pattern or rota state. Inferred from the technical spec's Section 7.

3. Design Philosophy

The mental model Rota Manager embodies is that of a governed timetable, not a diary. A diary records what happened; this timetable expresses what will be available. The design should reinforce this distinction at every point: patterns are the source of truth, generated entries are derived artefacts, and overrides are exceptions that require explicit intent. Inferred from the technical spec's Section 1 ("The rota is not a diary") and Section 3.1–3.3.

Empty states. When a staff member has no active Schedule Pattern, the interface must communicate that this person has no bookable availability — not that there is a loading error or system fault. The empty state for a staff member's rota view should explain the consequence (downstream consumers will see no availability) and offer the primary action to create a pattern. Inferred from core behaviour rule 1 and Section 4.1.

Error states. Validation errors on pattern creation (e.g. end time before start time, overlapping break segments) should be inline and field-specific. They should not block the user from reviewing the rest of the form. Errors arising from integration failures (e.g. HR-approved absence feed unavailable) should be surfaced as non-blocking banners with context, not full-page errors. Inferred from the technical spec's data model in Section 13.1 and the integration contracts in Section 6.

AI suggestions. AI suggestions (e.g. highlighting coverage gaps, explaining pattern consequences) appear in a visually distinct advisory panel or inline annotation. They are never pre-committed to a pattern or rota entry. The user must take an explicit approval action before any AI suggestion affects saved state. Accepted and rejected suggestions are both logged in the audit trail. Inferred from the technical spec's Section 7 and Section 8.

Multi-step flows. Pattern creation is the module's most consequential multi-step flow. It follows a wizard structure — staff member selection, role and site assignment, recurrence type, day-by-day availability grid, break configuration, start date — with a review-and-confirm step before saving. This ensures users understand what they are committing before future rota entries are generated. Inferred from the Schedule Pattern required fields in Section 3.1.

Undo/redo. Because pattern changes affect only future entries and never mutate historical records, the primary safety mechanism is a pre-save review step rather than post-save undo. Once a pattern is saved, the change is recorded in the immutable audit log. A deactivate action on a pattern is reversible (reactivation is permitted); a manual override on an individual rota entry is distinct from the underlying pattern and can be corrected by a subsequent override. Inferred from the technical spec's core behaviour rule 2 and Section 4.1.

Read-only vs editable surfaces. Generated rota entries are visually read-only by default. The UI must make the distinction between a generated entry (derived from a pattern, cannot be directly edited) and an overridden entry (manually modified) immediately legible via a badge or entry-type indicator. The Shift Manager pattern-editing surfaces are editable only for users whose role permits it. Inferred from the technical spec's Section 3.3 and Section 4.1.

4. Primary Surfaces

4.1 Web Portal

Who uses it: Practice managers and group-practice administrators. This is the primary authoring surface for all schedule patterns, rota configuration, and absence overrides. Inferred from the technical spec's Section 5.1, which states that the Shift Manager interface is available via the web portal.

Key tasks performed here:

• Create, edit, activate, and deactivate Schedule Patterns for individual staff members. Inferred from the technical spec's Section 4.1.
• Configure multi-site availability — assigning a staff member explicit patterns scoped to each site they work at. Inferred from the technical spec's Section 4.3.
• Review generated rota entries by date range, staff member, role, and location. Inferred from the technical spec's Section 13.4.
• Apply manual overrides to individual rota entries without altering the underlying pattern. Inferred from the technical spec's Section 3.3.
• Review and action incoming absence overrides (manual or HR-approved feed) and see the resulting impact on availability. Inferred from the technical spec's Section 4.4.
• View the coverage summary by role and location — the equivalent of the HR coverage query — to identify gaps. Inferred from the technical spec's Section 6.3, HR & People Manager contract, and Section 13.4.
• Review the audit log for any pattern or rota change. Inferred from the technical spec's Section 8.
• View advisory AI suggestions about coverage gaps or pattern consequences, and explicitly accept or dismiss them. Inferred from the technical spec's Section 7.

Layout pattern: The Schedule List View (one card per staff member) uses a list-detail layout, with the detail pane opening as a pattern editor. The generated rota view uses a split-pane layout — filter/navigation on the left, calendar or list of rota entries on the right. The pattern editor itself follows a wizard layout for creation and a form layout for editing. Inferred from the surfaces described in the partial UX spec Sections 4.1 and 4.2, and the data model in Section 13.1.

Schedule List View

One expandable card per staff member. Each card shows: the recurrence type (weekly or fortnightly), a per-day availability summary (Monday–Sunday), the active/inactive state, and the site(s) the pattern covers. Quick actions on the card — create pattern, edit, activate/deactivate — are surfaced without requiring a full detail view. Inferred from the partial UX spec Section 4.1 and the technical spec Section 3.1.

Schedule Editor — Weekly/Fortnightly Pattern Grid

A grid layout with one row per day of the week (or two weeks for fortnightly patterns). Each row contains: an on/off toggle for the day, a start time field, an end time field, and a break summary indicator (e.g. "2 breaks"). Days marked off are visually muted. Break editing is inline per day — each break has a start time, end time, and optional label. Fortnightly patterns display two labelled week grids (Week A / Week B) within the same editor. Inferred from the partial UX spec Sections 4.2 and 4.3, and the technical spec Sections 3.1 and 4.1.

Generated Rota View

A read-only view of date-specific rota entries, filterable by staff member, role, location, and date range. Each entry shows: staff member, role, location, shift start/end, shift type (Working / Break / WorkPackage), and entry type (Generated / Override). Override entries carry a visual badge distinguishing them from generated entries. Inferred from the technical spec's Section 3.2, Section 3.3, and Section 13.4.

4.2 Tablet App

Who uses it: Surgery and decon staff (nurses, surgeons, and decon technicians) working at the point of care. This is a read-only consumption surface. The tablet receives a filtered feed of active rota entries for a given location and date, sourced from the Surgery & Decon Day View integration contract. Inferred from the technical spec's Sections 5.2 and 6.3.

Key tasks performed here:

• View today's active rota for the current location — who is working, in which role, and in which surgery or room. Inferred from the technical spec's Section 6.3, Surgery & Decon Day View contract.
• See shift type for each staff member (Working / Break / WorkPackage) to understand real-time staffing context. Inferred from the technical spec's Section 6.3.

Touch ergonomics: Tap targets must be ≥48 px on the tablet surface to support glove-friendly interaction in clinical environments. The day view is optimised for portrait orientation and single-hand scrolling. No authoring controls (pattern creation, override entry) appear on the tablet surface. Inferred from the technical spec's Section 5.2, which specifies this surface as read-only, and the clinical context of surgery/decon use.

Authenticated nurse session and rota-context filtering. The tablet day view renders rota data filtered to the authenticated user's current location context, as determined by the Surgery & Decon Day View integration contract. When a nurse logs in, the surface must display only the rota entries relevant to their assigned location for that session — it must not present a global or cross-site rota feed. If the authenticated session cannot be resolved to a specific location, the surface must display a prompt to confirm location rather than defaulting to an unfiltered feed. If the rota feed is unavailable for the authenticated session, the offline and error state treatments described in Section 5.3 apply; the user must see a staleness warning before any cached data is acted upon. Inferred from Surgery & Decon Day View §4.2, which explicitly references Rota Manager as the source of rota context for filtering, and the action-first and governance principles in Section 2.

4.3 Mobile App (Staff)

Who uses it: Individual staff members viewing their own shift times and upcoming rota. The primary use cases are checking when a shift starts and ends (relevant because Rota Manager supplies shift times to Staff App Mode for quiet hours enforcement) and viewing personal scheduled sessions for the current and upcoming days. Inferred from the technical spec's Section 5.4, Section 6.2, the Staff App Mode quiet-hours contract in Section 6.3, and Staff App Mode §4.3, which lists "Viewing personal rota and upcoming shifts; viewing day lists (clinicians and nurses)" as key tasks.

Key tasks performed here:

• View upcoming shift times (start and end) for the current and next working day. Inferred from the Staff App Mode quiet hours contract in Section 6.3.
• View the full personal rota for upcoming scheduled sessions, including day, site, role, and shift type. Inferred from Staff App Mode §4.3. (See Open Question 7 for outstanding scoping decision on whether the full recurring pattern is exposed here or only date-specific entries.)
• View advisory attendance signal status (arrived / no arrival detected / likely late) where surfaced to the staff member. Inferred from the technical spec's Section 4.5.

(Detailed patient mobile app interaction for this module: not applicable — the technical spec explicitly excludes patient communication from Rota Manager's scope. See Section 2.2.)

5. Interaction Model

5.1 Primary Flows

Flow 1 — Create a new Schedule Pattern

Inferred from the Schedule Pattern required fields (Section 3.1), the Shift Manager specification (Section 4.1), and the pattern editor description in the partial UX spec (Sections 4.2–5.2).

Start: Manager opens Schedule List View
  │
  ▼
Step 1 — Select staff member
  │  (search or select from staff list)
  ▼
Step 2 — Assign role and site
  │  (role dropdown, site selector)
  │  [validation: role and site required]
  ▼
Step 3 — Set recurrence type and start date
  │  (weekly / fortnightly; date picker for StartDate)
  ▼
Step 4 — Configure day-by-day availability
  │  (grid: per-day on/off, start time, end time)
  │  [inline validation: end time must be after start time]
  ▼
Step 5 — Configure breaks per active day
  │  (per-day inline break editor; multiple breaks supported)
  │  [inline validation: breaks must be within shift window]
  ▼
Step 6 — Review and confirm
  │  (summary of pattern: staff, role, site, recurrence,
  │   days, breaks, start date; pre-save preview)
  │  [confirmation button]
  ▼
Pattern saved → audit event `pattern.created` emitted
  │
  ▼
Future rota entries generated from pattern start date
  │
End: Return to Schedule List View; new pattern card visible

Flow 2 — Edit an existing Schedule Pattern

Inferred from the technical spec's Sections 4.1 and 3.3, which require that pattern changes affect future entries only and never mutate historical records.

Start: Manager selects a pattern card in Schedule List View
  │
  ▼
Pattern editor opens (form layout; fields pre-populated)
  │
  ▼
Manager edits one or more fields
  │
  ▼
Review and confirm
  │  [warning: "Changes will apply to future rota entries only.
  │   Existing historical entries will not be affected."]
  │  [confirmation button]
  ▼
Pattern saved → audit event `pattern.updated` emitted
  │
  ▼
Future rota entries regenerated from effective date
  │
End: Return to Schedule List View

Flow 3 — Apply a manual override to a generated rota entry

Inferred from the technical spec's Sections 3.2, 3.3, and core behaviour rule 4.

Start: Manager opens Generated Rota View;
       selects a specific date-specific rota entry
  │
  ▼
Override panel opens (entry details pre-populated)
  │  [label: "This entry was generated from a pattern.
  │   Changes here affect this date only and will not
  │   alter the underlying pattern."]
  ▼
Manager edits entry fields (start/end time, shift type, etc.)
  │
  ▼
Confirm override
  │
  ▼
Rota entry updated with EntryType: Override
→ audit event `rota_entry.overridden` emitted
  │
End: Override badge visible on entry in Generated Rota View

Flow 4 — Process an absence override

Inferred from the technical spec's Sections 4.4, 3.4, and 6.1.

Start: Absence received (manual override or HR-approved feed)
  │
  ▼
Absence displayed in absence review surface
  │  [Source label: "Manual" or "HR-approved feed"]
  │  [date range and affected staff member shown]
  ▼
Manager reviews / confirms (manual path)
  OR
System confirms automatically (HR-approved feed path)
  │
  ▼
AbsenceChangeEvent emitted (EventType: AbsenceConfirmed)
→ audit event `absence_change_event.emitted` recorded
  │
  ▼
Affected rota entries flagged as absent; availability removed
  │  [base pattern preserved; affected entries shown as
  │   overridden by absence with source label]
  ▼
Downstream consumers notified via event
  │  [informational note displayed to manager: "Appointment
  │   Manager will process any appointments affected by this
  │   absence. Rescheduling actions, if triggered, are managed
  │   within Appointment Manager and are observable there."]
  │
End: Absence visible in Generated Rota View with
     absence badge; base pattern unchanged

Absence handoff to Appointment Manager. When an AbsenceChangeEvent is emitted and Appointment Manager's Reschedule Job processes absence-triggered appointment moves, Rota Manager's UI must make the handoff legible without attempting to replicate Appointment Manager's logic. The informational note shown at the end of the absence confirmation flow (see Flow 4 above) is the primary mechanism. This note must appear consistently on every absence confirmation step, whether the absence originated as a manual override or arrived via the HR-approved feed. The Rota Manager UI does not surface the status of individual rescheduling operations — these are observable within Appointment Manager — but does confirm via the audit log that the AbsenceChangeEvent was emitted. Managers who need to monitor rescheduling outcomes must navigate to Appointment Manager. Inferred from the Appointment Manager UX spec §3, which describes practitioner absence–driven rescheduling workflows and the requirement that automation is always observable, and from the Rota Manager technical spec Sections 4.4 and 6.3.

Flow 5 — Deactivate a Schedule Pattern

Inferred from the technical spec's Section 4.1 and audit event pattern.deactivated.

Start: Manager selects an active pattern card
  │
  ▼
Deactivate action triggered
  │
  ▼
Confirmation modal
  │  [warning: "Deactivating this pattern will remove future
  │   availability for this staff member at this site.
  │   Historical rota entries are not affected."]
  │  [confirm / cancel]
  ▼
Pattern marked Active: false
→ audit event `pattern.deactivated` emitted
  │
End: Pattern card shows inactive state in Schedule List View;
     no further rota entries generated

Flow 6 — Staff member views personal rota on mobile

Inferred from Staff App Mode §4.3 and the Rota Manager technical spec Sections 5.4 and 6.3.

Start: Staff member opens mobile app; navigates to rota view
  │
  ▼
Personal rota displayed — current and upcoming scheduled
sessions (date, site, role, shift start/end, shift type)
  │  [read-only; no authoring controls visible]
  │
  ▼
Staff member taps a shift entry for detail
  │  [shift detail: start time, end time, site, role,
  │   shift type, attendance signal if available]
  │  [note: "Notifications outside your shift hours are
  │   suppressed by Staff App Mode."]
  │
  ▼
Staff member optionally views shift context within
Smart Dashboards rota highlight card
  │  (see Section 10 — Smart Dashboards touchpoint)
  │
End: Staff member informed of shift times and
     notification quiet hours without accessing
     Rota Manager's authoring surfaces

Flow 7 — Task Manager shift-aware task display on tablet and staff mobile

Inferred from the Task Manager technical spec and the Rota Manager technical spec Sections 3.2 and 6.2.

Start: Staff member or clinical user views tablet day view
       or staff mobile rota surface
  │
  ▼
Rota entries with ShiftType: WorkPackage are visible,
labelled "Managed by Task Manager — not editable here"
  │
  ▼
Staff availability state (on-shift / off-shift / absent /
quiet hours) is surfaced alongside shift entries so that
Task Manager's assignment and notification logic is
contextualised for the user
  │  [off-shift or absent staff: entries muted;
  │   label: "Staff unavailable — task assignment and
  │   notifications governed by Task Manager rules"]
  │
End: Staff availability state clearly communicated;
     no Task Manager authoring controls appear on
     Rota Manager surfaces

5.2 State Machines (Mirror of Technical Specification § 3)

The following state treatments are inferred from the technical spec's Section 3.3 (Rota Entry State Machine) and Section 3.4 (AbsenceChangeEvent). Inferred from those sections.

Rota Entry states

Read-only entries (Generated) must be visually distinct from editable or overridable state. A user should not be able to accidentally begin editing a generated entry without a deliberate override action. Inferred from the technical spec's Section 3.3: "Rota entries are read-only by default; only manual overrides alter a specific entry."

Schedule Pattern states

Pattern activation and deactivation are irreversible in terms of the historical audit record, though patterns can be reactivated. Both transitions must emit audit events (pattern.activated / pattern.deactivated) and must not be performed silently. Inferred from Section 8.

AbsenceChangeEvent states

The source of the absence (ManualOverride vs HRApprovedFeed) must be labelled on the affected entries so managers can distinguish between changes they authored and changes received from HR. Inferred from the technical spec's Section 3.4 and the Source field on AbsenceChangeEvent.

5.3 Empty / Loading / Error / Offline States

All treatments below are inferred from the technical spec's data model, integration contracts, and core behaviour rules. Sources cited per item.

Schedule List View

• Empty state: No staff member has an active pattern. Show a call-to-action to create the first pattern. Explain in plain language that no patterns means no availability for downstream consumers. Inferred from core behaviour rule 1.
• Loading state: Skeleton cards whilst the pattern list loads. Inferred from the list-of-cards layout and standard platform convention.
• Error state: If the pattern list cannot be fetched, show a non-blocking error with a retry action. Do not show a blank screen. Inferred from reliability requirements in Section 14.
• Offline state: The Schedule List View should display the last-cached pattern data with a clear "last updated" timestamp and a read-only indicator. Pattern creation and editing must be disabled offline. Inferred from the system-of-record nature of this surface and the immutable audit requirement in Section 8.

Generated Rota View

• Empty state: No rota entries exist for the selected filters (staff, role, location, date range). Distinguish between "no pattern defined for this period" (actionable — link to create a pattern) and "no entries yet generated" (informational). Inferred from core behaviour rules 1 and 2.
• Loading state: Skeleton rows within the filtered view. Inferred from the list/calendar layout.
• Error state: If the rota feed cannot be fetched, show an inline error banner with a retry action. Inferred from integration contract reliability.
• Offline state: Display last-cached rota entries as read-only. Override actions must be disabled. Inferred from the immutability and audit requirements in Section 8.

Pattern Editor (Wizard / Form)

• Empty state: A new pattern starts with all days off and no breaks. The user must explicitly enable each day. This prevents accidental availability being created. Inferred from the principle "availability is explicit, never inferred."
• Loading state: When editing an existing pattern, field values load progressively. The save action is disabled until loading is complete. Inferred from form UX best practice and the data model in Section 13.1.
• Error state: Inline field-level validation errors appear on save attempt (e.g. end time before start time; break outside shift window). A summary of errors appears at the top of the form. Inferred from the data model constraints in Section 13.1.
• Offline state: Pattern editing is disabled offline. A banner explains that changes cannot be saved until connectivity is restored. Inferred from the audit requirement that all changes must be logged with a timestamp.

Tablet Day View (Surgery & Decon)

• Empty state: No rota entries for this location and date. Show a message that no staff are rostered for this location today. Do not suggest a workaround. Inferred from Section 6.3 and the read-only feed contract.
• Loading state: Skeleton rows for staff assignment context whilst the feed loads. Inferred from the day-of rota feed contract in Section 6.3.
• Error state: If the rota feed is unavailable, display the last known rota data with a prominent "data may be out of date" warning and a timestamp. Clinical staff must not operate without an indication that the data they are seeing may be stale. Inferred from the clinical-context use of this surface.
• Offline state: Same as error state. Read-only cached data with staleness warning. Inferred from Section 5.2.
• Unauthenticated / unresolved session state: If the authenticated nurse session cannot be resolved to a specific location, the surface must display a location confirmation prompt rather than an unfiltered or empty feed. This prevents clinical staff from unknowingly viewing rota data for the wrong location. Inferred from Surgery & Decon Day View §4.2 and the authenticated nurse session model described in Section 4.2 of this spec.

HR & People Manager availability query error handling. When HR & People Manager queries Rota Manager's availability data during a leave approval workflow (e.g. to detect scheduling conflicts or simulate coverage impact), Rota Manager's API must respond gracefully. From a UX perspective, if real-time rota data is temporarily unavailable during an HR leave approval session, the manager-facing absence review surface in Rota Manager should surface a non-blocking banner indicating that coverage simulation data may be incomplete and should be reconfirmed once connectivity is restored. The manager must not be blocked from progressing an absence action, but must be clearly informed of the data limitation. Inferred from HR & People Manager technical spec §14 and the HR & People Manager UX's reference to graceful degradation when Rota Manager data is unavailable.

6. Component Inventory

New components introduced or extended by this module:

• Schedule Pattern Card — expandable card showing a staff member's pattern summary (recurrence type, per-day availability, active state, site). Appears in the Schedule List View. Inferred from Section 4.1 of the partial UX spec and the Schedule Pattern data model in Section 3.1 of the technical spec.
• Weekly/Fortnightly Availability Grid — a day-of-week grid with per-row on/off toggle, time fields, and break summary. Core component of the pattern editor. Inferred from Sections 4.2–4.3 of the partial UX spec.
• Inline Break Editor — appears within each active day row of the availability grid. Supports multiple breaks per day with start time, end time, and optional label. Inferred from the technical spec's Section 3.1 (Breaks[]) and partial UX spec Section 4.2.
• Rota Entry Row — a single date-specific rota entry displayed in the generated rota view. Shows staff member, role, location, start/end, shift type, and entry-type badge (Generated / Override). Inferred from the Rota Entry data model in Section 3.2.
• Entry Type Badge — a small visual indicator distinguishing Generated entries from Override entries. Appears on every rota entry row. Inferred from the technical spec's Section 3.3.
• Absence Indicator — a visual overlay on rota entries affected by a confirmed absence. Labels the absence source (Manual / HR-approved). Inferred from Sections 3.4 and 4.4.
• Coverage Summary View — a role-and-location-scoped view showing which staff have active patterns for a given window. Consumed internally (manager planning) and mirrors the HR coverage query contract. Inferred from Section 13.4 and the HR & People Manager integration contract in Section 6.3.
• AI Advisory Panel — a visually distinct panel or annotation surface for AI suggestions (coverage gap highlights, pattern consequence explanations). Contains explicit accept/dismiss controls. Never pre-committed. Inferred from the technical spec's Section 7.
• Audit Log Viewer — a read-only, paginated view of all audit events for a given pattern or rota entry. Accessible via progressive disclosure from a pattern card or rota entry. Inferred from Section 8 and the audit events listed there.
• Attendance Signal Indicator — an advisory badge (Arrived / No arrival detected / Likely late) shown on staff entries in the tablet day view and staff mobile view. Visually distinct from rota state indicators. Inferred from Section 4.5.
• Staff Availability State Indicator — a contextual label on tablet day view and staff mobile rota entries communicating on-shift / off-shift / absent / quiet-hours status. Used by Task Manager's shift-aware assignment logic to contextualise task and notification rules; surfaced read-only to staff and clinical users. Inferred from the Task Manager technical spec and Rota Manager technical spec Sections 3.2 and 6.2.

Reused from the design system:

• Date picker
• Time field
• Dropdown / select
• Toggle / checkbox
• Toast notification
• Modal / confirmation dialog
• Inline form validation message
• Skeleton loader
• Paginated list
• Filter/search bar
• Banner (informational / warning / error)

7. Visual Design Notes

• Typography: (needs UX writer input — heading scale, body scale, and monospace usage for time fields should be defined by the design system; confirm with design lead.)
• Colour: Semantic colour usage must communicate: active pattern (positive/available), inactive/deactivated pattern (neutral/muted), generated rota entry (neutral), override rota entry (distinct from generated — consider a secondary accent or outlined treatment), absence indicator (warning or cautionary), break/non-working time (muted/unavailable — must never resemble a bookable slot). Inferred from the state machine in Section 3.3, absence handling in Section 4.4, and break rules in Section 4.2.
• Iconography: (needs UX writer input — icon set to be confirmed by design system. All icons must have a visible text label or ARIA label; icon-only controls are not permitted.)
• Differentiation of entry types — generated rota entries and override rota entries must be visually distinguishable at a glance without relying on colour alone (e.g. use both badge text and a border or background pattern). Inferred from the technical spec's Section 3.3 and accessibility obligations.
• Motion: (needs UX writer input — animation timing values to be confirmed by design system. In all cases, transitions must respect prefers-reduced-motion.)

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.

Time fields — start and end time inputs in the availability grid and break editor must have programmatic labels that include the day of week and context (e.g. "Monday shift start time", "Monday lunch break end time"). Adjacent time fields on the same row must not share a single label. Inferred from the grid layout structure in the partial UX spec Section 4.2 and the break data model in Section 3.1.

State changes announced to screen readers — when a rota entry transitions from Generated to Override, or when an absence indicator is applied, the change must be announced via an ARIA live region so that screen reader users are not silently left on stale content. Inferred from the state machine in Section 3.3 and absence handling in Section 4.4.

Colour-blind safe differentiation — entry type (Generated / Override) and absence indicators must not rely on colour as the sole differentiator. Texture, label, or shape cues must supplement colour. Inferred from WCAG 2.2 AA non-colour contrast requirements and the visual distinction requirements in Section 3.3.

Clinical tablet context — the tablet day view must support glove-friendly tap targets ≥48 px and must not require precision gestures. Inferred from the clinical environment described in the technical spec's Section 5.2.

9. Internationalisation

Locale-aware date/time/number formatting.

All user-facing strings externalised.

Layouts tolerant of 30% string-length growth (German, French).

Time display — shift start and end times, break times, and the fortnightly Week A / Week B labels must all use locale-aware time formatting (12-hour or 24-hour as appropriate to locale). The availability grid must not assume 24-hour clock. Inferred from the time fields on Schedule Pattern and Rota Entry in Sections 3.1–3.2.

Date formatting — the StartDate field on patterns and the date range filters on the generated rota view must use locale-appropriate date formatting. Inferred from the date fields on Schedule Pattern in Section 3.1.

RTL support: Required assessment. The grid-based availability editor may require RTL layout mirroring. (needs UX writer input — confirm RTL requirement with product owner given multi-site group practice scope.)

Day-of-week order — the availability grid must respect locale-appropriate week start day (Monday-first vs Sunday-first). Inferred from the DayOfWeek enum in the data model in Section 13.1 and multi-site/multi-locale group practice scope.

10. Cross-Module UX Touchpoints

All touchpoints below are inferred from the integration contracts in Sections 6.1–6.3 and 10 of the technical spec.

• Appointment Manager — the manager working in Rota Manager's generated rota view has no direct navigation into Appointment Manager from here, but must understand that the availability they are viewing is what Appointment Manager uses to determine bookable windows. When an absence override is confirmed and an AbsenceChangeEvent is emitted, the UI surfaces an informational note that Appointment Manager will process affected appointments, including any absence-driven rescheduling actions triggered by the Reschedule Job. Rota Manager does not replicate or preview rescheduling logic — the note confirms the event has been emitted and directs managers to Appointment Manager for rescheduling observability. Inferred from Sections 4.4 and 6.3 and the Appointment Manager UX spec §3.

• HR & People Manager — absences sourced from the HR-approved feed arrive in Rota Manager's absence surface labelled with their source ("HR-approved"). The manager's view shows the outcome but cannot override the HR approval decision from within Rota Manager. When a manager initiates a manual absence override, a note should advise that this will be visible to HR & People Manager via the availability query interface. Where HR & People Manager queries real-time rota data for conflict detection or coverage simulation during leave approval workflows, Rota Manager must respond with current availability state; if that data is temporarily unavailable, a non-blocking banner in the absence review surface communicates the limitation (see Section 5.3). Inferred from Sections 6.1, 6.3, and 4.4 and the HR & People Manager technical spec §14.

• Task Manager — no direct user-facing navigation between Rota Manager and Task Manager. The WorkPackage shift type visible on rota entries is the UX surface of the Task Manager overlay contract. Entries with ShiftType: WorkPackage should carry a label explaining that this slot is managed by Task Manager, not editable directly here. On both the tablet day view and the staff mobile rota surface, the Staff Availability State Indicator (on-shift / off-shift / absent / quiet hours) provides the contextual signal that Task Manager uses to govern task assignment and notification rules; this indicator is surfaced read-only and labelled clearly so that staff understand why certain tasks or notifications may be deferred. Inferred from Sections 3.2, 6.2, and 6.3 and the Task Manager technical spec.

• Communication Hub — staff notifications routed via Communication Hub (e.g. notifications about pattern changes or absence confirmations) are not authored or configured within Rota Manager's UI. Rota Manager triggers the event; Communication Hub handles delivery. The Rota Manager UI surfaces audit evidence of the event emission but not the notification content. Inferred from Sections 6.2 and 2.2.

• Staff App Mode — shift start and end times displayed in the staff mobile view are the same times that Staff App Mode uses to enforce quiet hours. The mobile view should carry a note that notifications outside these times will be suppressed. No separate quiet hours control exists within Rota Manager's UI — this is owned by Staff App Mode. Inferred from the Staff App Mode quiet hours contract in Section 6.3.

• Smart Dashboards — Rota Manager supplies the rota data that Smart Dashboards surfaces as the "Rota highlights" fixed card on the staff mobile app (the user's scheduled sessions and any coverage gaps flagged by the AI Advisory Panel). A "rota highlight" comprises: the staff member's next scheduled session (date, site, role, shift start/end), any absence indicator affecting an upcoming entry, and any coverage gap advisory surfaced by Rota Manager's AI panel. When a staff member taps a rota highlight card in Smart Dashboards, they are navigated to the personal rota view within Rota Manager's staff mobile surface (Flow 6) for full detail. Rota Manager does not author the Smart Dashboards card layout; it provides the data feed that Smart Dashboards renders. Inferred from Smart Dashboards §4.3 and §5.2, which declare rota highlights as the third fixed signal on the mobile app.

• Surgery & Decon Day View — the tablet day view is a read-only consumption surface for Rota Manager data. There is no reverse navigation from the tablet into Rota Manager's pattern editing surfaces. Clinical staff using the tablet cannot edit rota entries. The tablet surface renders rota data filtered to the authenticated nurse's current location session, as described in Section 4.2. Inferred from Sections 5.2 and 6.3.

• Access Manager — the current user's role and permissions (which determine whether pattern editing controls are visible) are supplied by Access Manager. The Rota Manager UI must not expose disabled editing controls to users who lack permission; controls simply do not appear. This applies across all surfaces: pattern creation and editing controls on the web portal, override actions on the generated rota view, and absence confirmation actions — all are conditionally rendered based on Access Manager's RBAC decisions at the time of the session. Users who lack permission to author patterns or overrides see only the read-only rota views appropriate to their role. Inferred from Sections 9 and 13.3, the "no dead toggles" principle, and Access Manager §4.4.

• Inventory & Compliance Manager — Rota Manager does not directly assign or manage compliance tasks, which remain the responsibility of Inventory & Compliance Manager. However, staff availability and absence state from Rota Manager are relevant context for when compliance tasks can be completed. When a staff member is absent or off-shift, Rota Manager's availability data signals that task assignment or completion windows may need adjustment. This context is surfaced read-only via the Staff Availability State Indicator on relevant surfaces; it is not actionable within Rota Manager. Whether task assignment within Inventory & Compliance Manager actively enforces rota constraints (rather than treating assignment as purely role-based) is a cross-module product decision outside Rota Manager's scope. Inferred from Inventory & Compliance Manager UX §4.1 and §4.2 and Rota Manager technical spec Sections 3.2 and 4.4.

• Security and Privacy (session management) — Rota Manager's rota patterns emit shift end signals that the Security and Privacy module uses to trigger rota-end auto-logout for staff sessions on the web portal and tablet surfaces. Rota Manager does not own or configure session timeout rules; these are configured by administrators via the Security and Privacy module's web portal configuration surface. Rota Manager's responsibility is to ensure that shift end times are accurately reflected in the availability data that Security and Privacy consumes to evaluate auto-logout conditions. If a rota entry is overridden (e.g. shift end time changed), the updated end time must propagate to the availability feed in a timely manner so that session timeout rules remain aligned with the actual shift. Inferred from Security and Privacy UX §4.1, which specifies rota-end auto-logout as an administrator-configured session timeout rule.

UX consistency rules:

• Action buttons for pattern creation and override confirmation always appear in the primary action position consistent with the Primoro platform convention. (needs UX writer input — confirm platform-standard button placement for web vs tablet.)
• Entry-type badges (Generated / Override / Absence) use consistent visual language across the web portal and tablet day view.
• The "base pattern unaffected" message must appear consistently on every override and absence confirmation step, using the same wording. (needs UX writer input — exact copy for this message.)

11. Governance & Auditability

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

AI suggestions are visually distinct — AI advisory content (coverage gap highlights, pattern consequence explanations) is rendered in a visually distinct surface (e.g. a clearly labelled advisory panel or inline annotation). AI suggestions carry a visible indicator identifying them as AI-generated. Users must take an explicit accept action before any AI suggestion is applied to a pattern or rota entry. Rejected suggestions are also logged. Inferred from Sections 7 and 8 ("All AI suggestions, including which were accepted or rejected by humans").

Audit-significant actions require confirmation — the following actions must present a confirmation step before execution: pattern creation, pattern editing, pattern activation/deactivation, manual rota entry override, manual absence override. The confirmation step shows the user what will change and what will not change (specifically: historical entries are never affected). Inferred from Sections 3.3, 4.1, and 8.

Audit log accessible via progressive disclosure — every pattern card and every rota entry in the generated rota view must expose a link to view its immutable audit log. The log shows actor, timestamp, event type, and (for pattern updates) a before/after snapshot. Inferred from Sections 8 and 13.1 (AuditLog JSONB field).

The current user's role is visible — the active user's role (as determined by Access Manager) is shown in the header of the web portal, so managers and read-only staff understand their permission context. Inferred from Section 9.

Read-only states are visually distinct — generated rota entries, read-only feeds (tablet day view), and data surfaced from downstream integrations are all clearly marked as read-only. Edit controls do not appear on read-only surfaces. Inferred from Sections 3.3, 5.2, and 6.3.

Absence source is always labelled — entries affected by an absence show whether the absence was initiated as a manual override or from the HR-approved feed. This allows managers to distinguish their own actions from HR-system actions without consulting the full audit log. Inferred from the Source field on AbsenceChangeEvent in Section 3.4.

Attendance signals are labelled as advisory — attendance signal indicators (arrived / no arrival detected / likely late) carry a visible "advisory only" label. They must not be styled or positioned in a way that implies they constitute a formal record of attendance or have payroll implications. Inferred from Sections 4.5 and 13.2 rule 9.

12. Notification & Communication Patterns

All notification patterns below are inferred from the audit events in Section 8, the Communication Hub integration contract in Section 6.2, and the Staff App Mode contract in Section 6.3.

• In-app banner — used for: (a) staleness warning on the tablet day view when the rota feed is unavailable or data is cached; (b) informational notice that an HR-approved absence has arrived and been applied to the rota; (c) notice that a pattern change has generated new future rota entries; (d) non-blocking notice that coverage simulation data from Rota Manager may be incomplete during HR leave approval workflows, where real-time rota data is temporarily unavailable. Banners are persistent until dismissed or the underlying condition resolves. Inferred from the integration contracts in Section 6 and the reliability requirements in Section 14.
• Toast — used for: (a) confirming that a pattern has been successfully created, updated, activated, or deactivated; (b) confirming that a manual rota entry override has been saved; (c) confirming that a manual absence override has been submitted. Toasts are transient (auto-dismiss) and are used only for successful completions, not errors. Inferred from the audit events in Section 8 and platform conventions.
• Push notification (via Communication Hub — NOT directly) — staff may receive push notifications about changes to their own shift patterns (e.g. a pattern deactivation, an absence confirmation affecting their rota). These notifications are routed exclusively through Communication Hub. Rota Manager emits the triggering event; it does not author or dispatch the notification payload. Inferred from Sections 6.2 and 2.2.
• Email/SMS (via Communication Hub — NOT directly) — where a practice's Communication Hub configuration routes absence confirmations or pattern changes to staff by email or SMS, these are dispatched by Communication Hub. Rota Manager has no email or SMS sending capability. Inferred from Sections 6.2 and 2.2.
• Quiet hours (via Staff App Mode) — Rota Manager does not directly suppress or schedule notifications. It makes shift start/end times available to Staff App Mode, which applies quiet hours logic. The staff mobile view should surface a note explaining that notifications outside shift hours are suppressed by Staff App Mode, so that staff understand why they do or do not receive notifications at a given time. Inferred from the Staff App Mode contract in Section 6.3.

13. Open Questions

Questions 1–3 below are carried forward from the technical spec's Section 15. Questions 4–7 are UX-specific open questions identified during this synthesis pass.

1. Access control roles — which named roles may create, edit, activate, and deactivate Schedule Patterns? Is MFA required for pattern deactivation or bulk override actions? This determines which editing controls are visible to which users and what additional confirmation steps (e.g. MFA prompt) appear in the override and deactivation flows. Carried from the technical spec's Section 15, open question 1.
2. Pattern version history UI — if historical pattern versions are retained as discrete records (rather than relying solely on the append-only AuditLog), the audit log viewer component needs to support a version-diff display. If the AuditLog field alone is sufficient, the viewer only needs to render the log entries. This design depends on the outcome of the technical spec's open question 2.
3. Attendance signal ingestion and display — the specific signals available (arrived / no arrival detected / likely late) and the mobile or system sources that generate them need definition before the Attendance Signal Indicator component can be finalised. Carried from the technical spec's Section 15, open question 3.
4. Confirmation copy — (needs UX writer input — exact microcopy for the "base pattern unaffected" message shown on override and absence confirmation steps, and for the deactivation modal warning.)
5. RTL layout requirement — does the group-practice customer base include locales requiring right-to-left layout? The weekly availability grid and the fortnightly Week A/Week B layout are the components most at risk of requiring mirroring. Needs product owner confirmation before RTL scope is fixed.
6. Coverage gap visualisation — the coverage summary view and AI advisory panel are described in principle, but the threshold at which a coverage gap is flagged (e.g. minimum staffing ratios per role per location) is not defined in the technical spec. This is a product decision needed before the advisory panel can be fully designed. Not in scope for Rota Manager alone; likely requires input from Appointment Manager and HR & People Manager.
7. Staff-facing pattern visibility — the technical spec confirms a Staff App Mode read feed for shift times, but it is not clear whether individual staff members can view their full recurring pattern (not just today's shift times) within the staff mobile surface. This scoping question affects the mobile app component inventory and flow design.