HR & People Manager – UX Specification

Related Technical Authority: HR & People Manager – Technical Specification

1. Purpose

This UX specification governs the user experience of HR & People Manager, Primoro's authoritative workforce operations module for dental practices. It defines how practice managers, HR administrators, and individual staff members interact with the employee lifecycle, leave and attendance workflows, policy-driven HR processes, compliance tracking, and payroll-readiness surfaces. The primary roles served are practice managers and HR admins managing day-to-day workforce operations, with limited self-service access for individual staff members viewing their own records.

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.
• No bypassing governance — the UI MUST NOT present a path to approve a leave request, complete a workflow step, or lock a payroll period that circumvents a mandatory acknowledgement, escalation, or human-confirmation gate. Controls that would create such a bypass MUST NOT be rendered, not merely disabled. Inferred from technical spec §3.3, §3.5, and §7.
• Audit transparency — every state-changing action surfaces who did it and when. Read-only audit trails are always accessible from the artefact they concern. Inferred from technical spec §8.
• AI as advisor, never as actor — Aiden suggestions are visually and structurally distinct from manager decisions. The UI makes it impossible to mistake an AI suggestion for an approved action. Inferred from technical spec §7.

3. Design Philosophy

HR & People Manager is a governance-first module. Its primary obligation is to ensure that every consequential HR action — approving leave, progressing a disciplinary, locking a payroll period — happens through a structured, auditable sequence rather than informally or ad hoc. The design should embody this by making the governed path feel natural and fast, and making the ungoverned path structurally unavailable. Inferred from technical spec §1 and §4.3.

Empty states should be purposeful and action-oriented. A staff list with no records should guide the user immediately to onboarding a new member of staff. An analytics dashboard with no leave data should explain what data will appear once leave requests are raised. Empty states are never just blank screens. Inferred from the module's role as the single source of truth for workforce data — technical spec §1.

Error states must be actionable. Because several flows depend on real-time data from Rota Manager (conflict detection, coverage simulation), the UI must degrade gracefully when that integration is unavailable — surfacing a clear, honest warning to the approver rather than silently proceeding or silently blocking. Inferred from technical spec §14, reliability requirements.

AI suggestions (from Aiden) appear in a clearly distinguished advisory panel or inline callout. They are never pre-filled into form fields, never auto-applied, and always carry a visible dismissal option. Every suggestion is logged regardless of whether the user acts on it. Inferred from technical spec §7 and §8.

Multi-step flows (leave approval with risk acknowledgement, HR workflow progression, payroll period lock) use a linear wizard or step-by-step confirmation pattern where each step is explicit and reversible where the technical rules permit. Irreversible transitions — such as locking a payroll period or cancelling a workflow instance — require a dedicated confirmation step that names the consequence. Inferred from technical spec §3.3, §3.5, and §3.6.

Undo/redo is not available for state transitions on canonical artefacts. Because audit integrity is non-negotiable, the design philosophy acknowledges this constraint honestly: once a transition is made, the governed correction path (new artefact or amendment record) is surfaced immediately. Inferred from technical spec §3.3 and §3.5 rules.

Read-only vs editable surfaces are visually distinct at all times. Locked payroll periods, completed workflow instances, and closed leave requests are rendered in a clearly read-only state. The UI must never allow a user to believe they are editing a locked artefact. Inferred from technical spec §3.6 and §13.2 rule 5.

4. Primary Surfaces

4.1 Web Portal

Who uses it: Practice managers and HR administrators as their primary operational surface. Individual staff members access a limited view of their own record. Inferred from technical spec §5.1 and §9.

Key tasks performed here:

• Manage staff records — create, view, update, and offboard staff members through governed workflows. Inferred from technical spec §2.1 and §4.3.
• Review and action leave requests — view submitted requests with their risk classification, acknowledge High Risk classifications, and approve or reject requests. Inferred from technical spec §3.3 and §4.1.
• Progress HR workflow instances — view active disciplinary, grievance, onboarding, and probation workflows and complete designated human-confirmation steps. Inferred from technical spec §3.4 and §4.3.
• View workforce analytics and staffing coverage dashboards — assess coverage vs required shifts, absence concentration, overtime distribution, and workload imbalance signals. Inferred from technical spec §4.2.
• Define and publish mandatory training requirements for each role or staff group. Inferred from technical spec §4.4.
• Review compliance status signals received from Knowledge, Training & Learning within relevant HR workflows. Inferred from technical spec §4.4.
• Lock payroll periods and export payroll-ready CSV data. Inferred from technical spec §4.5 and §9.
• View operational efficiency metrics — approval speed, overdue task count, onboarding duration, workflow throughput. Inferred from technical spec §4.6.
• Access and export audit logs for CQC, Employment Tribunal, or GDPR subject access purposes. Inferred from technical spec §8 and §14.
• Configure practice-level settings — active workflow types, payroll period cadence, coverage risk threshold overrides. Inferred from technical spec §13.3.

Layout pattern: The primary layout is list-detail for staff records, leave requests, and workflow instances. The analytics and staffing coverage area uses a dashboard pattern. Payroll period management uses a list-detail pattern with a locked-state indicator. Configuration surfaces use a form pattern. Inferred from the breadth and nature of tasks described in technical spec §4 and §5.1.

4.2 Tablet App

Who uses it: Practice managers and senior staff in the practice environment, performing time-sensitive approval and workflow-step tasks without access to a desktop. Inferred from technical spec §5.2.

Key tasks performed here:

• Review and action leave requests — including viewing risk classification, reading Aiden's plain-language coverage risk explanation, acknowledging High Risk classifications, and approving or rejecting requests. Inferred from technical spec §3.3, §4.1, and §7.
• Complete pending HR workflow steps that require human confirmation. Inferred from technical spec §3.5 and §5.2.
• View overdue tasks surfaced from Task Manager. Inferred from technical spec §4.6 and §6.1.
• View key staffing coverage signals and absence alerts for the current period. Inferred from technical spec §4.2 and §5.2.

Touch ergonomics: All interactive controls must meet a minimum touch target of 44×44 px. The risk acknowledgement confirmation — a mandatory, irreversible step — must be designed to require a deliberate, unambiguous tap (not easily triggered by a scroll gesture or accidental contact). Inferred from technical spec §3.3 and WCAG 2.2 AA requirements.

Full administrative configuration (staff record creation, payroll export, training requirement definition, audit log export) is not expected on tablet. Inferred from technical spec §5.2.

4.3 Staff Mobile App

Who uses it: Individual staff members submitting structured requests — primarily leave requests (holiday, sickness) — via the Staff App Mode mobile surface. This surface is staff-facing, not manager-facing. Practice managers and HR admins do not use the Staff App Mode surface to action requests; approval and rejection remain on the web portal and tablet app. Inferred from Staff App Mode §4.3, which lists structured request submission (holiday, sickness, shift swap, expenses) as a core staff mobile task, and from technical spec §3.2, which defines leave requests as raiseable "by or on behalf of a staff member."

Key tasks performed here:

• Submit a leave request — staff member selects leave type (holiday, sickness, other absence), specifies the requested date range, and submits. The submission triggers conflict detection and coverage simulation on the HR & People Manager backend; the staff member receives a status indicator confirming the request has entered the Submitted state and is awaiting manager review. Inferred from technical spec §3.2, §3.3, and Staff App Mode §4.3.
• View own leave request status — staff member can see the current state of their submitted requests (Submitted, Risk Acknowledged, Approved, Rejected, Cancelled) and the outcome reason where applicable. This is a read-only view; the staff member cannot approve or reject their own requests. Inferred from technical spec §3.3 and §9.
• Receive notification of leave request outcome — when a request is approved or rejected, the staff member is notified via Communication Hub (push notification and/or email). The Staff App Mode surface reflects the updated state immediately when the app is next opened or foregrounded. Inferred from technical spec §6.2 and §3.3.

Design constraints for the mobile surface:

• All interactive controls MUST meet the 44×44 px touch target minimum. Inferred from WCAG 2.2 AA requirements.
• The submission form must be simple and focused: leave type, start date, end date, and an optional free-text note. Advanced risk data (classification, coverage simulation output) is not surfaced to the staff member at submission time; that detail is for the approving manager. Inferred from technical spec §3.3 and the principle of progressive disclosure.
• The leave type options available in the mobile submission form must reflect the same controlled vocabulary as the web portal and tablet app, to avoid misclassification. Inferred from technical spec §3.2.
• Submission confirmation must make clear that the request is pending manager review and has not been approved. The UI must not use language or visual treatment that implies immediate approval. Inferred from the "AI as advisor, never as actor" principle and the governed approval flow in technical spec §3.3.
• The staff member's view of their own request history is read-only. Editing or cancelling a submitted request from the mobile surface is a product decision that has not been resolved; see Open Questions. Inferred from technical spec §3.3 (cancellation requires reason + actor recording).

The full UX specification for the Staff App Mode surface — including navigation shell, shared components, and multi-module request types (shift swap, expenses, etc.) — is governed by the Staff App Mode UX specification. This section documents only the HR & People Manager-owned interactions (leave request submission and status viewing) that are exposed through that surface.

(Needs UX writer input — confirmation of whether sickness absence submission via mobile follows the same form as holiday requests, or requires a distinct flow with different fields. Also needs product decision on mobile cancellation capability — see Open Questions.)

5. Interaction Model

5.1 Primary Flows

Flow 1: Leave request — submission through to approval or rejection

Inferred from technical spec §3.3 (LeaveRequest state machine) and §4.1.

Staff member (or manager on behalf) initiates leave request
  → Fills in LeaveType, RequestedDateRange
  → Submits request
      → System runs conflict detection against Rota Manager RotaEntry records
      → System runs coverage gap simulation
      → RiskClassification assigned (Low / Medium / High / Critical)
  → [Low / Medium Risk]
      → Request moves to Submitted state
      → Manager reviews request + risk classification
      → Manager approves or rejects
          → Approved → state = Approved → leave approval event emitted to Rota Manager
          → Rejected → state = Rejected → notification triggered via Communication Hub
  → [High Risk]
      → Request moves to Submitted state with High Risk flag prominent
      → Manager must explicitly acknowledge the risk classification
          → Acknowledgement recorded → state = Risk Acknowledged
      → Manager may then approve or reject
          → Approved → state = Approved → leave approval event emitted to Rota Manager
          → Rejected → state = Rejected
  → [Critical Risk]
      → Request moves to Submitted state with Critical Risk flag prominent
      → Escalation task automatically created in Task Manager
      → Manager must complete escalation task AND explicitly acknowledge before approval path unlocks
      → Manager approves or rejects
          → Approved → state = Approved → leave approval event emitted to Rota Manager
          → Rejected → state = Rejected
  → [At any point before Approved/Rejected]
      → Cancelled → state = Cancelled (reason + actor recorded)
      → A Rejected or Cancelled request cannot be reopened; new request must be raised

Flow 2: HR workflow instance — initiation through to completion

Inferred from technical spec §3.4, §3.5, and §4.3.

Practice manager / HR admin initiates workflow (e.g. disciplinary, grievance, onboarding)
  → Selects WorkflowType; policy reference attached
  → Workflow instance created in Draft state
  → Manager activates → state = Active
  → System presents next required step
      → [Step requires human confirmation]
          → Manager completes step explicitly
          → Step recorded with actor + timestamp
      → [Step requires human confirmation — NOT auto-completable]
          → UI does not advance until explicit action taken
  → All steps completed → state = Completed
      → Completed instance is read-only; corrections require new instance or amendment record
  → [At any point]
      → Cancelled → reason + actor recorded (mandatory)

Flow 3: Payroll period — lock and export

Inferred from technical spec §3.6, §4.5, §9, and §13.2.

Practice manager / HR admin views open PayrollPeriod
  → Reviews period data (hours, overtime, leave adjustments, sickness flags, TOIL)
  → Initiates lock
      → MFA challenge presented (mandatory)
      → Confirmation step names the period and states the consequence (period will be read-only)
      → Manager confirms → state = Locked → audit event emitted
  → Manager initiates CSV export
      → MFA challenge presented (mandatory — export is access-logged)
      → Export generated (must complete within 10 seconds)
      → File downloaded; export event recorded in audit log
  → Locked period is read-only; corrections require new period or amendment record

Flow 4: Compliance training requirement definition and handoff

Inferred from technical spec §4.4 and §6.2.

HR admin defines mandatory training obligation
  → Selects role / staff group
  → Specifies training items, recurrence cadence, consequence of non-completion
  → Publishes → structured requirement emitted to Knowledge, Training & Learning
  → HR admin can view compliance status signals returned from Knowledge, Training & Learning
      → Upcoming deadlines and breaches surfaced within relevant HR workflows
      → On breach → escalation task automatically created in Task Manager

Flow 5: Compliance requirement definition — pathway assignment handoff to Knowledge, Training & Learning

Inferred from technical spec §4.4 and §6.2, and from Knowledge, Training & Learning UX §2, which states that compliance is owned by HR & People Manager rather than by the Knowledge module itself.

HR admin publishes a mandatory training requirement (as per Flow 4)
  → Structured requirement event emitted to Knowledge, Training & Learning
  → Knowledge, Training & Learning receives the requirement and creates a pathway assignment task
      → HR & People Manager surfaces a status indicator on the requirement record
         confirming the handoff has been received (e.g. "Pathway assignment pending in
         Knowledge, Training & Learning")
  → Knowledge, Training & Learning assigns and activates the learning pathway for the
    relevant staff group
      → HR & People Manager receives a completion/status signal back from
        Knowledge, Training & Learning
      → Signal surfaces on the staff record compliance tab and within relevant HR
        workflow steps (e.g. onboarding checklist, probation sign-off)
  → [Deadline approaching or breached]
      → Compliance status indicator on the staff record updates to "Deadline approaching"
        or "Breached"
      → On breach → escalation task automatically created in Task Manager
      → HR admin / practice manager may link through to Knowledge, Training & Learning
        to view pathway completion evidence; HR & People Manager does not replicate
        that detail — it surfaces the status signal only
  → HR & People Manager remains the authority for compliance sign-off;
    Knowledge, Training & Learning is the authority for pathway delivery and
    completion evidence

The handoff is intentionally unidirectional in terms of ownership: HR & People Manager defines the obligation and records the compliance outcome; Knowledge, Training & Learning executes the delivery. The UI must reflect this separation clearly — the HR admin publishes a requirement and receives a status signal; they do not configure learning content within HR & People Manager. If the HR admin needs to amend the learning pathway itself, a link or handoff to Knowledge, Training & Learning is provided. Inferred from Knowledge, Training & Learning UX §2 and technical spec §4.4.

(Needs joint resolution with Knowledge, Training & Learning module owner — specifically: what data is included in the status signal returned to HR & People Manager, and at what granularity is completion evidence accessible via the handoff link? See Open Questions.)

5.2 State Machines (Mirror of Technical Spec § 3)

LeaveRequest states

Inferred from technical spec §3.3.

A Rejected or Cancelled request must display a clear, persistent affordance to raise a new request in its place, since re-opening is not permitted. Inferred from technical spec §3.3.

The risk classification (Low / Medium / High / Critical) must be persistently visible on the request detail view throughout its lifecycle — not just at the point of approval. Inferred from technical spec §8, which requires the coverage impact data shown at classification time to be part of the audit record.

HRWorkflowInstance states

Inferred from technical spec §3.5.

Steps designated as requiring human confirmation must render a visually prominent "complete this step" control that is only enabled when the step's preconditions are met. The control must never appear pre-activated. Inferred from technical spec §3.5 and §13.2 rule 6.

PayrollPeriod states

Inferred from technical spec §3.6.

5.3 Empty / Loading / Error / Offline States

The following requirements apply to all screens in HR & People Manager. Inferred from technical spec §14 (reliability, performance) and general UX template requirements.

Staff record list — empty state Displays a purposeful prompt to onboard the first member of staff, with a direct action to initiate an onboarding workflow. Does not display a blank list. Inferred from the module's role as the authoritative source of staff data.

Leave request list — empty state Explains that no leave requests are currently recorded. If the user has permission to raise a request on behalf of staff, surfaces that action directly. Inferred from technical spec §4.1.

Workforce analytics dashboard — empty state Explains which data is needed before analytics will populate (leave records, attendance data, RotaEntry consumption from Rota Manager) and indicates what actions will produce that data. Does not show zero-value charts. Inferred from technical spec §4.2.

Loading states Conflict detection and coverage simulation (triggered on LeaveRequest submission) must display a loading indicator that clearly labels what is being calculated, since the 3-second SLA means the user may wait. Other list and dashboard views use skeleton screens. Inferred from technical spec §14 performance requirements.

Error states If conflict detection fails because Rota Manager is unavailable, the UI MUST surface a prominent warning to the leave approver stating that coverage data could not be retrieved and that the approval is proceeding without automated conflict detection. The approver must explicitly acknowledge this warning before proceeding. The warning is recorded in the audit log. Inferred from technical spec §14 reliability requirements.

If a payroll export fails, the UI must display a clear error with a retry action. The failed attempt is logged. The PayrollPeriod state is not altered by a failed export. Inferred from technical spec §14 and §13.2 rule 5.

(Needs UX writer input — exact wording for the Rota Manager unavailability warning shown to the leave approver, including what action labels to use for acknowledgement)

Offline states The web portal and tablet app are not designed for offline operation. If connectivity is lost, the UI should surface a clear offline indicator and disable all state-changing actions (approval, workflow step completion, payroll lock). Read-only views of previously loaded data may remain accessible where technically possible. Inferred from the module's dependency on real-time Rota Manager data for conflict detection and from the audit integrity requirements in technical spec §8.

6. Component Inventory

New components introduced or extended by this module:

• Risk classification badge — displays Low / Medium / High / Critical coverage risk on a LeaveRequest. Must be colour-coded using semantic colours (not brand colours), accessible at 4.5:1 contrast, and never icon-only. Inferred from technical spec §3.3 and §4.1.
• Risk acknowledgement panel — a prominent, non-dismissable panel that surfaces the coverage impact data for a High Risk or Critical Risk leave request and requires an explicit acknowledgement action before the approval path continues. Inferred from technical spec §3.3.
• AI advisory callout (Aiden) — a visually distinct panel or inline callout surfacing Aiden's suggestions (e.g. alternative leave dates, understaffing signals, absence pattern flags). Visually and structurally separate from manager decision controls. Carries an explicit dismiss action. Logged on display. Inferred from technical spec §7 and §8.
• Workflow step card — represents a single step within an HRWorkflowInstance, showing step name, policy reference, required actor, status (pending / complete), and the human-confirmation control where applicable. Inferred from technical spec §3.4 and §4.3.
• Payroll period summary panel — displays the locked or open period's summary data (total hours, approved overtime, leave adjustments, sickness flags, TOIL balances) and surfaces the lock and export actions with their MFA gate. Inferred from technical spec §3.6 and §4.5.
• Compliance status indicator — surfaces per-staff-member or per-role compliance status (compliant / deadline approaching / breached) within HR workflows, consuming signals from Knowledge, Training & Learning. Inferred from technical spec §4.4.
• Compliance requirement handoff status indicator — surfaces the current handoff state of a published training requirement (e.g. "Pathway assignment pending", "Pathway active", "Completion signals received") as returned from Knowledge, Training & Learning. Distinct from the per-staff compliance status indicator; this operates at the requirement level rather than the individual level. Inferred from technical spec §4.4 and Flow 5 above.
• Staffing coverage summary widget — displays coverage vs required shifts, unfilled rota slots, and absence concentration for a given period. Consumed on the workforce analytics dashboard. Inferred from technical spec §4.2.
• Audit trail drawer — an accessible, read-only side panel showing the immutable audit history of a canonical artefact (StaffRecord, LeaveRequest, HRWorkflowInstance, PayrollPeriod), with actor, timestamp, and event type per entry. Inferred from technical spec §8.

Reused from the design system:

• Data table / list view (staff records, leave requests, workflow instances, payroll periods)
• Filter bar (status, date range, role, risk classification)
• Confirmation modal (irreversible state transitions)
• Toast notification (non-critical confirmations — e.g. leave request saved as draft)
• In-app banner (high-attention alerts — e.g. Rota Manager unavailable during conflict detection)
• Skeleton screen (loading state for lists and dashboards)
• MFA challenge modal (payroll lock and export)
• Badge / status chip (artefact state display)

7. Visual Design Notes

• Typography: (needs UX writer input — heading scale, body scale, monospace usage for audit identifiers and UUIDs)
• Colour: Risk classification states (Low / Medium / High / Critical) MUST use semantic colours drawn from the design system's warning/danger scale, not brand colours. Success (approved, compliant), warning (risk acknowledged, deadline approaching), error (critical risk, compliance breach, Rota Manager unavailable), and info (submitted, pending) states must be visually distinguishable without relying on colour alone (icon or text label required alongside). Inferred from technical spec §3.3 and WCAG 2.2 AA requirements.
• Iconography: Audit trail, lock/unlock (payroll period state), risk level, AI advisor (Aiden), and compliance status must each have a dedicated icon from the platform icon set. Icons must never appear without a text label or accessible tooltip on interactive controls. Inferred from the module's governance-heavy surface areas.
• Motion: Transitions on state-change confirmations (e.g. a leave request moving to Approved) may use a brief, subtle transition to signal the change has taken effect. The risk acknowledgement panel and MFA challenge modal MUST NOT use animated entrances that delay the user's ability to act. All motion must respect prefers-reduced-motion. Inferred from technical spec §14 accessibility requirements.

8. Accessibility & Inclusivity

The module MUST meet WCAG 2.2 AA. Specifically:

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

The risk acknowledgement step for High Risk leave requests is a governance-critical interaction. It MUST be fully operable by keyboard, have a clearly labelled focus state, and be announced correctly by screen readers as a required confirmation action. Inferred from technical spec §3.3 — this is a mandatory, non-bypassable step.

The AI advisory callout (Aiden) must be distinguishable from manager decision controls not only visually but programmatically — screen readers must announce its AI-advisory nature. Inferred from technical spec §7 and §8 (AI suggestions are logged separately from human actions).

The workforce analytics dashboard must not rely solely on colour to convey staffing risk signals. Each signal must carry a text label or pattern alongside colour coding. Inferred from WCAG 1.4.1 and the governance-critical nature of coverage risk information — technical spec §4.2.

Guided workflow flows for non-HR users (practice managers progressing disciplinary or grievance workflows) must be designed for low training overhead, using plain-language step descriptions and contextual help rather than assumed HR knowledge. Inferred from technical spec §14 accessibility and §4.3.

The Staff App Mode mobile surface for leave request submission (§4.3) must meet the same WCAG 2.2 AA standard. Date pickers, leave type selectors, and submission confirmation screens must be fully operable by assistive technologies and meet touch target requirements. The submission confirmation in particular must be announced correctly by screen readers, since it confirms a pending-review (not approved) state and misreading it has material consequences for the staff member. Inferred from WCAG 2.2 AA requirements and technical spec §3.3.

9. Internationalisation

• Locale-aware date/time/number formatting
• All user-facing strings externalised
• Layouts tolerant of 30% string-length growth (German, French)
• RTL support: not required at this lifecycle stage, but layouts must not structurally preclude it

Date ranges on leave requests and payroll periods are particularly sensitive to locale formatting. The UI must render these using the practice's locale setting rather than a hard-coded format, since misreading a date range in a leave or payroll context has material consequences. Inferred from technical spec §3.2 and §3.6.

UK HR policy templates (disciplinary, grievance, etc.) are authored for UK employment law. If internationalisation is extended in future to non-UK jurisdictions, the policy template layer will require separate governance. This is noted as a future concern only; the current build is UK-specific. Inferred from technical spec §4.3.

10. Cross-Module UX Touchpoints

Where this module's UX intersects with related modules:

• Rota Manager — The leave request approval flow surfaces real-time RotaEntry data (unfilled shifts, coverage gaps) inline within the leave request detail view. The user does not navigate to Rota Manager to see this data; it is consumed and displayed within HR & People Manager's approval surface. After a leave request is approved, a notification or status indicator may inform the manager that Rota Manager has been notified and will require a RotaEntry override to be applied there. The user is not automatically taken to Rota Manager. Inferred from technical spec §6.1, §6.2, and §4.1.
• Knowledge, Training & Learning — Compliance status signals appear as embedded indicators within HR workflow steps (e.g. onboarding completion checklist, probation sign-off, disciplinary context) and on the staff record compliance tab. The user does not navigate away from HR & People Manager to view these signals; they are surfaced in context. If the user needs to view training completion evidence, a link or handoff to Knowledge, Training & Learning is provided. When an HR admin publishes a mandatory training requirement, HR & People Manager surfaces a handoff status indicator confirming that Knowledge, Training & Learning has received the requirement and is progressing pathway assignment (see Flow 5 and the compliance requirement handoff status indicator in §6). HR & People Manager remains the authority for compliance sign-off; it does not replicate pathway delivery detail. Inferred from technical spec §4.4 and §6.1, and Knowledge, Training & Learning UX §2.
• Staff App Mode — The Staff App Mode mobile surface exposes leave request submission and status viewing to individual staff members (see §4.3). From the HR & People Manager perspective, requests submitted via Staff App Mode enter the same LeaveRequest state machine and are actioned through the same web portal and tablet approval flows as requests raised by a manager on behalf of a staff member. No separate approval queue or routing exists for mobile-submitted requests. The full navigation shell and multi-module context for the Staff App Mode surface is governed by the Staff App Mode UX specification. Inferred from technical spec §3.2, §3.3, and Staff App Mode §4.3.
• Task Manager — Overdue tasks (workflow steps awaiting human action, Critical Risk escalation tasks, compliance breach escalation tasks) appear as a summary count and list within HR & People Manager's dashboard. Clicking through to a task may open a Task Manager surface or a deep-linked view within HR & People Manager; the exact handoff pattern needs definition. Inferred from technical spec §4.3, §4.4, §4.6, and §6.2.
• Financial Insights — No UX handoff from HR & People Manager to Financial Insights is surfaced within this module. HR & People Manager emits operational source data (attendance, overtime, leave) as a data feed; this is invisible to the end user within HR & People Manager. If Financial Insights surfaces derived analytics to the manager, that is Financial Insights' surface to own. Inferred from technical spec §6.2 and §11.
• Communication Hub — HR & People Manager triggers notification events (leave approval/rejection, escalation, compliance breach) via Communication Hub. The user experience of receiving those notifications (email, push, in-app) is governed by Communication Hub. Within HR & People Manager, the manager sees the state change reflected immediately on the artefact; they do not need to check Communication Hub to know what happened. Inferred from technical spec §6.2.
• Access Manager — The currently authenticated user's role and active permissions are visible in the header or persistent navigation. Controls that are inaccessible to the current role are not rendered (not merely greyed out), consistent with the "no dead toggles" principle. Role-based visibility is enforced by Access Manager and reflected in the UI. Inferred from technical spec §9 and §6.1.
• Audit & Compliance — The audit trail drawer on each artefact surfaces data drawn from the immutable audit log owned by Audit & Compliance. Export of audit logs for CQC, Employment Tribunal, or GDPR purposes is available from the HR & People Manager web portal, with the export action itself access-logged. Inferred from technical spec §8 and §6.2.
• Appointment Manager — No UX touchpoint in the current build. Forward compatibility is noted; if demand signals from Appointment Manager are consumed in a future integration, staffing coverage analytics may be enriched with appointment demand context. No UI surface for this is defined at this lifecycle stage. Inferred from technical spec §6.2 and §13.5.

UX consistency rules:

• Risk classification badges use the same semantic colour and label conventions across all surfaces (web portal, tablet app, and Staff App Mode mobile surface). Inferred from technical spec §3.3.
• Aiden's AI advisory callout uses the same visual treatment wherever it appears in this module. It is never styled to resemble a system alert or a manager decision control. Inferred from technical spec §7.
• All confirmation modals for irreversible state transitions (payroll period lock, workflow cancellation, leave rejection) follow the same structural pattern: name the artefact, state the consequence, present a labelled confirm action and a labelled cancel action. Inferred from technical spec §3.3, §3.5, §3.6.

(Needs UX writer input — confirmation of the exact handoff pattern between HR & People Manager task summary and Task Manager, particularly whether task completion happens within HR & People Manager or navigates to Task Manager)

11. Governance & Auditability

AI suggestions from Aiden are visually distinct from manager decisions at all times. Suggested actions (e.g. alternative leave dates, flagged absence patterns) are displayed in the AI advisory callout component, which carries a persistent AI/Aiden identifier. A suggested value is never pre-populated into a form field or decision control; the manager must actively choose to act on it. The callout provides a visible dismiss option. Inferred from technical spec §7 and §8.

The following actions trigger a confirmation step before they take effect: leave request approval, leave request rejection, leave request cancellation, High Risk acknowledgement, HR workflow step completion (where designated as requiring human confirmation), HR workflow cancellation, payroll period lock, payroll data export. Each confirmation step names the action and its consequence in plain language. Inferred from technical spec §3.3, §3.5, §3.6, and §9.

Payroll period lock and payroll data export require MFA in addition to the confirmation step. The MFA challenge is presented as a modal that explains why authentication is required. Inferred from technical spec §9.

The current user's role and active permissions are visible in the persistent header or navigation. This is not a decorative element — it informs the user which actions they can and cannot take without needing to attempt an action and receive a denial. Inferred from technical spec §9.

Read-only states are visually distinct from editable states at all times. Locked payroll periods, completed workflow instances, and closed leave requests render without editable controls. A locked state indicator (icon + label) is persistent on the artefact header. Inferred from technical spec §3.5, §3.6, and §13.2 rule 5.

The audit trail drawer is accessible from every canonical artefact (StaffRecord, LeaveRequest, HRWorkflowInstance, PayrollPeriod) via a persistent, clearly labelled action. The trail is always read-only and is never filtered or paginated in a way that could hide entries. Inferred from technical spec §8.

Time-saved estimates, where surfaced in the operational efficiency area, carry a visible "indicative only" label. They must not be presented in a way that implies precision or commitment. Inferred from technical spec §4.6 and §13.2 rule 11.

12. Notification & Communication Patterns

All notifications triggered by HR & People Manager are delivered via Communication Hub. HR & People Manager emits the trigger event; Communication Hub owns delivery. The following patterns apply. Inferred from technical spec §6.2.

• In-app banner — used for high-attention, action-required states that affect the current session: Rota Manager integration unavailable during conflict detection (with explicit acknowledgement required before proceeding); compliance breach detected for a staff member currently being actioned in an HR workflow. Inferred from technical spec §4.1 and §14 reliability requirements.
• Toast — used for non-critical confirmations: leave request saved as draft, workflow step recorded, payroll export completed successfully, mandatory training requirement published to Knowledge, Training & Learning. Toasts are transient and do not require user dismissal. Inferred from the range of confirmable actions in the module.
• Push notification (via Communication Hub) — used for time-sensitive events requiring manager attention away from the portal: leave request submitted and awaiting review, Critical Risk leave request escalation created, compliance deadline approaching or breached, overdue workflow step. For staff members using Staff App Mode, push notifications for leave request outcome (approved or rejected) are also delivered via Communication Hub. Inferred from technical spec §6.2 and the escalation requirements in §3.3 and §4.4, and from Staff App Mode §4.3.
• Email (via Communication Hub) — used for formal HR communications triggered by state transitions: leave request approved or rejected (to the staff member), workflow step assigned to a named actor, payroll period locked (confirmation to the manager who locked it), compliance breach escalation (to the practice manager). Inferred from technical spec §6.2.

(Needs UX writer input — exact notification copy for each trigger event listed above, including subject lines for email notifications and body text for push notifications)

13. Open Questions

The following questions must be resolved before this UX spec can be promoted from draft to published. Several align directly with the open questions in the technical specification.

1. Task Manager handoff pattern — When a manager clicks through to an overdue task or escalation task surfaced within HR & People Manager, does completion happen inline within HR & People Manager, or does the user navigate to Task Manager? The interaction model and component inventory in this spec assume an inline or deep-linked experience, but this depends on Task Manager's integration surface. Needs joint resolution with Task Manager module owner. Inferred from technical spec §6.1 and §4.3.

2. Coverage risk threshold display — The UI must surface the risk classification (Low / Medium / High / Critical) to the approver, but the thresholds that produce that classification are unresolved in the technical spec (open question 3). Until thresholds are defined, it is unclear whether the UI should surface the underlying numeric data (e.g. "3 of 5 required shifts unfilled") alongside the classification label, or only the classification. This affects the design of the risk acknowledgement panel. Needs resolution from product and Rota Manager integration design.

3. Rota Manager integration unavailability — confirmation wording — The UI must surface a warning and require acknowledgement when conflict detection cannot run because Rota Manager is unavailable. The exact wording of this warning and the label of the acknowledgement action need UX writer input and legal/compliance review, since proceeding without conflict detection is a governance-significant action. Inferred from technical spec §14.

4. Staff self-service leave request initiation — The technical spec references leave requests raised "by or on behalf of a staff member" (§3.2) and grants individual staff members limited read access to their own record (§9). Staff App Mode §4.3 identifies structured request submission (holiday, sickness) as a core staff mobile task, and §4.3 of this spec documents the mobile submission surface accordingly. However, it has not been confirmed whether staff members can cancel or edit a submitted request from the mobile surface; this requires a product decision, as cancellation requires reason and actor recording (technical spec §3.3).

5. Aiden suggestion entry points — The technical spec defines what Aiden MAY surface (§7) but does not specify where in the UI these suggestions appear. For example: does Aiden's alternative leave date suggestion appear on the leave request detail view, on the approver's review screen, or both? Does the understaffing highlight appear on the analytics dashboard only, or also on the leave approval flow? These entry point decisions need UX design and product sign-off.

6. Rota Manager RotaEntry API contract — (Carried from technical spec open question 1.) Until the API shape and sync mechanism is confirmed, the loading state design for conflict detection and the exact content of the Rota Manager unavailability warning cannot be finalised.

7. Coverage risk thresholds — (Carried from technical spec open question 3.) Affects the level of numeric detail to surface in the risk acknowledgement panel and the analytics dashboard.

8. Payroll period cadence configuration — (Carried from technical spec open question 4.) Affects how payroll period selection and creation are presented in the UI.

9. GDPR erasure flow — The technical spec defines hard deletion of StaffRecord data for GDPR erasure as a governed, audited operation accessible only to elevated roles (§14). The UI flow for this operation — including the confirmation pattern, the audit event surfacing, and the post-erasure state of related artefacts — has not been designed. This is a compliance-critical flow that requires dedicated UX design before the module is built. Inferred from technical spec §14 and §9.

10. Knowledge, Training & Learning handoff status signal granularity — Flow 5 (§5.1) and the compliance requirement handoff status indicator (§6) rely on status signals returned from Knowledge, Training & Learning confirming that a pathway has been assigned and is active. The data shape, latency, and granularity of these signals have not been confirmed. Specifically: does the signal include per-staff-member pathway status, or only an aggregate for the requirement? And at what point does Knowledge, Training & Learning consider a pathway "assigned" vs "active"? Needs joint resolution with Knowledge, Training & Learning module owner.