AI Meeting Notes – UX Specification

Related Technical Authority: AI Meeting Notes – Technical Specification v2.2

1. Purpose

This UX specification governs the experience of capturing, reviewing, and actioning internal staff meetings within Primoro's AI Meeting Notes module. It defines how recording, live transcription, AI-drafted note packs, action confirmation, sign-off, and retention decisions are presented to users across web and tablet surfaces. The primary roles it serves are meeting organisers (who own the recording and sign-off flow) and permitted staff participants (who may view, edit, or act upon shared meeting artefacts based on their RBAC role).

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
• Recording transparency at all times — because the technical spec mandates that recording must be visibly indicated during capture and participants must be informed that meeting assistance is active (§ 6.2), the interface must display a persistent, unambiguous recording indicator whenever capture is live. This indicator may never be hidden or minimised away.
• Review before consequence — because the technical spec prohibits any auto-finalisation of notes or autonomous task creation (§ 8.2, § 9.3), the UI must always interpose a human review step before any output becomes authoritative or any task is created. No "accept all" shortcut may bypass individual confirmation of actions.
• Confidence-aware presentation — because the technical spec defines confidence-aware speaker attribution with safe fallback (§ 10.3), the UI must communicate uncertainty explicitly rather than presenting a best guess as fact. Unconfirmed speaker labels must look different from confirmed ones.

3. Design Philosophy

AI Meeting Notes is a governed-capture tool, not a note-taking app. The mental model is closer to a structured process than a blank document: the meeting happens, the system assists, the human decides. This framing should be reflected throughout.

Empty states: Before any meeting is captured, the module surfaces the list of upcoming meetings that are eligible for AI Meeting Notes capture, with a clear prompt to start the first recording. An empty state is not a failure — it is an invitation to begin. (needs UX writer input — exact empty-state headline and call-to-action copy)

Error states: Because recording artefact creation must be idempotent and must not silently lose outcomes (§ 15), errors must be surfaced immediately with a clear explanation of what was not saved and what the user can do next. Silent degradation is never acceptable for data-loss risks; it is acceptable only for speaker attribution, where the technical spec explicitly permits unnamed-speaker fallback (§ 11.3).

AI suggestions: All AI-produced content — live note drafts, topic segments, decision candidates, action candidates, suggested owners, suggested due dates — must be visually distinct from user-authored content. AI output is always labelled as a suggestion until a human edits or confirms it. Accepting a suggestion is a deliberate act, not a default.

Multi-step flows: The post-meeting sign-off is a structured, sequential flow (finalise note pack → confirm actions → set retention) derived from the technical spec's sign-off step (§ 12.2). Each step must be clearly numbered and the user must be able to see their progress. Skipping steps is not permitted; the organiser must complete all three stages before the meeting record is considered signed off.

Undo/redo: Edits to the NotePack (summary, topics, decisions) should support undo within the editing session. Action confirmations and retention decisions, once submitted, are auditable and reversible only through the appropriate governance route, not a simple undo gesture. This boundary must be communicated at the point of submission.

Read-only vs editable surfaces: RBAC determines whether a user can edit a meeting record (§ 4, § 3.1). Surfaces rendered in read-only mode must be visually distinct from editable surfaces — not merely lacking controls, but actively signalling their read-only state so that users do not assume their input has been lost.

4. Primary Surfaces

4.1 Web Portal

Who uses it: meeting organisers (typically managers, HR staff, governance leads, or project owners) and permitted staff participants with appropriate RBAC roles, as implied by the internal-meetings-only scope (§ 2) and RBAC requirements (§ 4).

Key tasks performed here:

• Viewing and managing the list of MeetingNoteRecords (past and in-progress meetings).
• Initiating or scheduling a meeting for AI Meeting Notes capture.
• Reviewing and editing the AI-drafted NotePack (summary, topics, decisions) after the meeting ends.
• Completing the post-meeting sign-off flow: finalising the note pack, confirming or rejecting ActionCandidates, and setting recording retention.
• Replaying the recording (organiser and permitted users only, per § 6.3).
• Managing voice profile enrolment and speaker attribution confirmation (RBAC-restricted, per § 10.4).
• Viewing the audit log for a meeting record (governance/admin roles).
• Configuring sharing of recording access and derived artefacts to permitted users (per § 6.3).

Layout pattern: List-detail for the meeting record index (left panel: chronological list of MeetingNoteRecords with status badges; right panel: selected record detail, note pack, and action review). The sign-off flow opens as a stepped wizard overlay or dedicated page rather than inline editing, to reinforce its governed, sequential nature.

4.2 Tablet App

Who uses it: meeting organisers or nominated facilitators running a meeting in a room, who need to monitor live transcription and live note drafting while the meeting is in progress. This surface is inferred from the in-room capture context described in § 6.4 and § 11.

Key tasks performed here:

• Starting and stopping the meeting recording from the room device.
• Monitoring the live recording indicator (persistent, prominent) to confirm capture is active.
• Watching live transcription and AI-drafted note blocks as the meeting progresses (read-only or light annotation only — full editing is post-meeting).
• Confirming speaker identity when the system surfaces an unresolved speaker attribution during the meeting (confidence-aware prompt, per § 10.2–10.3).
• Initiating the end-of-meeting sign-off flow when the meeting concludes.

Touch ergonomics: Recording start/stop controls and speaker attribution confirmation prompts must meet a minimum 48 × 48 px touch target. Because the tablet may be used on a desk during a live meeting, controls should be reachable without picking up the device. The recording indicator must be visible at any screen orientation. (needs UX writer input — confirm whether landscape-first or portrait-first layout is preferred for in-room tablet use)

4.3 Mobile App (Staff)

The technical specification does not explicitly describe a mobile app surface for this module. The module's scope is internal meetings captured via room hardware or supported platforms (§ 6.4), which implies a primarily web and tablet context. A mobile surface may be appropriate for post-meeting review (reading the note pack, reviewing action candidates) but this is not confirmed by the technical spec. This section should be revisited once the platform's mobile strategy for Post-MVP modules is defined. (needs UX writer input — confirm whether a mobile review surface is in scope for this module)

5. Interaction Model

5.1 Primary Flows

Flow 1 — Start a meeting recording

Inferred from § 6.1 (recording-first behaviour), § 6.2 (participant awareness), and § 4 (RBAC).

Organiser opens AI Meeting Notes
  → Selects or creates a meeting entry
    → Confirms meeting type / sensitivity / title
      → System displays participant-awareness notice
        → Organiser taps/clicks "Start recording"
          → Recording indicator appears (persistent, prominent)
          → Live transcription begins
          → AI begins drafting live note blocks (assistive, non-authoritative)
          → Meeting in progress ──────────────────────────────┐
                                                               │
          ← Organiser taps/clicks "Stop recording"  ◄─────────┘
            → Recording stops; indicator clears
            → System begins post-meeting NotePack generation
            → Organiser is prompted to begin sign-off flow

Flow 2 — Post-meeting sign-off (governed, sequential)

Inferred from § 12.2 (sign-off step), § 8.2 (review-first), § 9.1 (action review flow).

Step 1 — Review & finalise NotePack
  Organiser reviews AI-drafted summary, topics, decisions
  → Edits/redacts as needed (full audit trail retained)
  → Confirms NotePack status transition (Draft → In-Review or Final)

Step 2 — Confirm actions
  System presents ActionCandidates list
  Each candidate shows: text, suggested owner (nullable), suggested due date (nullable), AI badge
  → Organiser selects Confirm / Reject / Edit for each candidate
  → Only Confirmed candidates proceed
  → Confirmed candidates create Tasks in Task Manager with back-link to MeetingNoteRecord
  → Rejected candidates are logged in audit trail

Step 3 — Set recording retention
  System shows current default expiry (30 days from meeting end)
  → Organiser may accept default or change expiry
  → If expiry is changed: system offers optional "Create retention review Task" in Task Manager
  → Organiser confirms retention decision
  → Decision is logged as attributable audit event

Sign-off complete → MeetingNoteRecord.SignOffState = Completed

Cross-module alignment — Task Manager: Task Manager mandates that AI-surfaced suggestions must be visually differentiated from user-authored or system-confirmed content, and that the confirmation action must be the primary call-to-action — never self-confirming or pre-selected. Flow 2's action-candidate review (Step 2) MUST comply with these principles: each ActionCandidate must carry a visible AI content badge until explicitly acted upon, the Confirm control must be the most prominent available action per candidate row, and no batch-confirmation affordance may be offered that bypasses individual review. These constraints are consistent with the "Review before consequence" principle in § 2 and the ActionCandidate visual treatment defined in § 5.2, and apply equally whether the flow is rendered on the web portal or initiated from the tablet surface.

Flow 3 — Speaker attribution confirmation

Inferred from § 10.2 (voice profile mapping requires human confirmation) and § 10.3 (confidence-aware fallback).

System detects unresolved speaker in transcript
  → Displays transcript segment labelled "Speaker 1" (fallback label)
  → Surfaces low-confidence attribution prompt: "Is this [Staff Name]?"
    → User confirms → label updated; voice profile mapping logged
    → User rejects → remains "Speaker 1"; no mapping recorded
    → User dismisses → no change; prompt does not reappear for same segment

Flow 4 — Share recording / artefacts

Inferred from § 6.3 (optional sharing, permission-controlled and auditable).

Organiser opens MeetingNoteRecord (post-meeting)
  → Selects "Share" option
    → System presents RBAC-filtered list of permitted users
    → Organiser selects recipients and which artefacts to share
      (recording access / transcript / note pack — separately controllable)
    → Organiser confirms share action
    → Share event logged in audit trail
    → Recipients are notified (via Communication Hub — see § 12)

5.2 State Machines (Mirror of Technical Spec § 5.1)

The MeetingNoteRecord.Status field drives the primary state machine visible in the UI, as defined in the technical spec's canonical data model (§ 5.1 and § 16.1).

The SignOffState (NotStarted | InProgress | Completed) is a secondary state machine that tracks progress through the three-step sign-off flow. The UI should expose this as a progress indicator within the sign-off flow, not as a top-level status badge, to avoid overloading the primary Status badge.

ActionCandidate.ConfirmationState (Proposed | Confirmed | Rejected | Converted) drives the visual treatment of each action item in the review list: Proposed = AI-badged, unactioned; Confirmed = user-actioned, queued for task creation; Rejected = struck-through or visually dismissed; Converted = linked to a Task with a back-link reference. Per § 16.1.

5.3 Empty / Loading / Error / Offline States

Meeting record list (index view):

• Empty state: No meetings have been captured yet under this module. Surface a prompt to start the first meeting recording or schedule a meeting. (needs UX writer input — exact empty-state headline and body copy)
• Loading state: Skeleton list rows while the meeting record index loads. Do not show a spinner for the full page — use progressive skeleton loading so the layout is established immediately.
• Error state: If the record list fails to load, show an inline error with a retry action. The error must not be a full-page error if other parts of the portal remain functional. (needs UX writer input — exact error message copy)
• Offline state: The technical spec does not define an offline mode for this module. Previously loaded meeting records may be shown in a read-only cached state with a clear "you're offline" indicator. Recording and sign-off actions must be disabled with an explanation. (needs UX writer input — offline state messaging)

Live meeting view (in-meeting, tablet):

• Empty state: Not applicable — the live view is entered intentionally after recording starts.
• Loading state: Because the technical spec requires that live transcription must not block meeting UX (§ 15), any transcription initialisation delay must be represented by a brief, non-intrusive loading indicator within the transcript panel only. The recording indicator and meeting timer must appear immediately.
• Error state: If live transcription fails, the recording must continue uninterrupted. The transcript panel should show a clear, calm warning that transcription is temporarily unavailable, with an assurance that the recording is still active. This reflects safe degradation (§ 11.3). (needs UX writer input — exact in-meeting error messaging)
• Offline state: If connectivity is lost during a meeting, the recording indicator must change to reflect a degraded capture state. The user must be informed clearly what is still being captured locally (if anything) and what will be unavailable. Per the technical spec's requirement that recording artefact creation must not silently lose outcomes (§ 15).

NotePack review (post-meeting):

• Empty state: If NotePack generation is still in progress when the organiser opens the review screen, show a clear in-progress state (not an empty state) with an estimated availability indicator or a "Notify me when ready" option. (needs UX writer input — copy for NotePack generation in-progress state)
• Loading state: Skeleton content blocks for summary, topics, decisions, and action candidates while the NotePack loads.
• Error state: If NotePack generation fails, the organiser must be informed with a clear explanation and a route to retry or escalate. The recording and transcript artefacts must remain accessible. (needs UX writer input — error messaging for NotePack generation failure)
• Offline state: If the organiser is offline when opening the review screen, a previously loaded NotePack draft may be shown in read-only mode with an offline indicator. Sign-off submission must be deferred until connectivity is restored, with queued state made visible.

6. Component Inventory

New components introduced by this module:

• Recording indicator — persistent, prominent visual indicator that capture is live; appears in the meeting view header and must be visible at all times during recording. Derived from § 6.2.
• Live transcript panel — scrolling, time-stamped transcript stream with speaker labels (confirmed vs unconfirmed, confidence-aware). Appears in the in-meeting view. Derived from § 7.1 and § 10.3.
• Live note drafts panel — assistive, AI-produced evolving blocks (summary, topic segments, decision candidates) displayed during the meeting as non-authoritative content. Derived from § 7.2.
• NotePack review editor — structured, section-by-section editor for summary, topics, decisions, and action candidates. Supports inline editing with AI-suggestion vs user-authored visual distinction and full undo within session. Derived from § 8.1–8.2.
• ActionCandidate review list — ordered list of AI-proposed actions, each with Confirm / Reject / Edit controls, AI badge, suggested owner, and suggested due date. Drives task creation on confirmation. Derived from § 9.1 and § 16.1.
• Sign-off wizard — three-step sequential flow (finalise note pack → confirm actions → set retention) with step progress indicator and explicit completion confirmation. Derived from § 12.2.
• Retention picker — control for setting or accepting recording expiry date, with optional "Create retention review Task" toggle. Derived from § 12.2–12.3.
• Speaker attribution prompt — inline, dismissible prompt within the transcript that surfaces an unresolved speaker mapping for human confirmation. Confidence-aware; shows fallback label until confirmed. Derived from § 10.2–10.3.
• AI content badge — a small, consistent visual marker applied to any AI-produced content (draft note blocks, action candidates, suggested owners, suggested due dates) to distinguish AI suggestion from user-confirmed content. Derived from § 7.2, § 8.2, § 9.3.
• MeetingNoteRecord status badge — displays current Status (Draft | In-Review | Final | Archived) and Sensitivity (Standard | Restricted | Private) on every record card and detail view. Derived from § 5.1.

Reused from the design system:

• Toast notification (action confirmation feedback)
• Modal confirmation dialog (irreversible-action confirmation, e.g. finalising a record)
• Skeleton loader (list and content loading states)
• Role/permission badge (current user's active role, visible in header per governance principle)
• Audit log viewer (for governance/admin roles reviewing the MeetingNoteRecord audit trail — shared pattern with other modules that emit audit events)

7. Visual Design Notes

• Typography: (needs UX writer input — heading and body scale; the technical spec does not prescribe typography)
• Colour: Semantic colour is required for the MeetingNoteRecord status badges (Draft, In-Review, Final, Archived) and ActionCandidate states (Proposed, Confirmed, Rejected, Converted). Warning-tone colour is required for the recording indicator to signal active capture. Error-tone colour is required for degraded capture states (e.g. transcription unavailable). The AI content badge requires a distinct, non-error colour to signal "AI-produced, not yet confirmed" without causing alarm. (needs UX writer input — specific semantic colour tokens)
• Iconography: A recording/microphone icon is required for the recording indicator. An AI/sparkle icon is appropriate for the AI content badge. Speaker/person icons are required for the speaker attribution prompt. All icons must be accompanied by a visible text label — icon-only usage is not permitted per the "no dead toggles" principle and accessibility requirements.
• Motion: The live transcript panel may use subtle scroll animation as new lines appear, provided this respects prefers-reduced-motion. The recording indicator must not pulse or animate in a way that could be distracting during a meeting; a static indicator with a clear active colour is preferred. No motion should be used for sign-off confirmation steps — these are governance actions and must feel deliberate, not fluid.

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 live transcript panel must be accessible to screen readers. Because transcription updates continuously during a meeting, live region (aria-live) behaviour must be carefully controlled — verbosity of live updates must be configurable or throttled to avoid overwhelming screen reader users during an active meeting.
• The recording indicator must be announced by screen readers when recording starts and stops, as participants must be informed that meeting assistance is active (§ 6.2). A programmatic state change announcement is required at capture start and stop events.
• Speaker attribution prompts that require human confirmation must be keyboard-reachable and operable without a pointer device, as they are a governance control (§ 10.2).
• The sign-off wizard steps must be navigable via keyboard with clear focus management between steps, as each step contains governance controls that must be individually reachable.

9. Internationalisation

• Locale-aware date/time/number formatting
• All user-facing strings externalised
• Layouts tolerant of 30% string-length growth (German, French)
• RTL support: requirements not confirmed by the technical spec. (needs UX writer input — confirm RTL requirement for this module)
• Recording expiry dates (default 30 days, configurable at sign-off per § 12.1–12.2) must be formatted using the user's locale date format throughout — in the retention picker, audit log, and any Task created for retention review.
• Meeting timestamps and transcript timestamps must use the user's locale and timezone. The technical spec references StartDateTime and EndDateTime (§ 5.1) and time-stamped transcripts (§ 7.1) — these must be rendered in local time, not UTC, on all surfaces.

10. Cross-Module UX Touchpoints

Where this module's UX intersects with related modules:

• Task Manager — the primary handoff point is the ActionCandidate confirmation step in the sign-off flow. When an organiser confirms an action, a Task is created in Task Manager and a back-link to the MeetingNoteRecord is shown within that Task. The UX must make this linkage visible in both directions: within AI Meeting Notes, confirmed actions show a "Task created" state with a navigable link; within Task Manager, tasks originating from a meeting must surface their source meeting as context. The optional retention review Task (§ 12.3) follows the same pattern. Derived from § 9.2 and § 12.3.
• Communication Hub — if the organiser chooses to post a meeting summary or actions to Communication Hub (§ 13), the transition from AI Meeting Notes to Communication Hub must be explicit and deliberate — not automatic. The UX must present this as an optional sharing action after sign-off, not a default behaviour. Communication Hub retains ownership of the thread once the content is posted; the user should understand they are handing content off, not syncing it. Notification delivery for meeting-share events is routed through Communication Hub (not sent directly from this module).
• Security & Privacy — voice profile management (enrolment, reset, deletion requests per § 10.4) may surface in a shared privacy/profile settings area governed by the Security & Privacy module. The UX for requesting voice profile removal must be accessible from within AI Meeting Notes (e.g. from a user's profile or settings panel within the module) but the fulfilment of that request is owned by Security & Privacy.

UX consistency rules:

• AI content badges must use the same visual treatment across all surfaces within this module — the same badge must appear on draft note blocks, action candidates, suggested owners, and suggested due dates, so users build a single mental model of "this is an AI suggestion".
• The governance confirmation pattern (explicit confirmation modal for irreversible actions) must be consistent with the platform-wide pattern used in Task Manager for task completion and similar irreversible transitions.
• Status badges for MeetingNoteRecord must use the same semantic colour palette as Task Manager status badges, so that staff moving between modules recognise the system's status language.

11. Governance & Auditability

The following governance requirements are derived from the technical spec's audit requirements (§ 14) and privacy/RBAC requirements (§ 4).

• AI suggestions are visually distinct from user actions. All AI-produced content (live note drafts, summary, action candidates, suggested owners, suggested due dates) carries an AI content badge until a human edits or confirms it. Once a human has acted on a suggestion, the AI badge is replaced by a confirmation indicator (e.g. "Edited by [user]" or "Confirmed by [user]"). This distinction is preserved in the audit log view.
• Recording indicator is a governance control, not a cosmetic element. It must be persistently visible whenever recording is active and must change state clearly when recording stops. This is a non-negotiable transparency requirement per § 6.2. The indicator must not be dismissable by any user during an active recording.
• Audit-significant actions show a confirmation step. The following actions must interpose an explicit confirmation modal before execution: finalising a meeting record (Draft/In-Review → Final), confirming an action candidate (creating a Task), changing recording retention from the default, and deleting or sharing a recording artefact. Each confirmation modal must state the consequence of the action clearly. (needs UX writer input — exact copy for each confirmation modal)
• The current user's role and active permissions are visible in the header on all surfaces within this module, consistent with the platform-wide governance visibility principle. Read-only access (e.g. a participant with view-only RBAC) must be signalled in the header and on any edit controls that are disabled as a result.
• Read-only states are visually distinct from editable states. A meeting record that is Final or that the current user cannot edit must not merely lack controls — it must carry a visible "read-only" indicator so users do not interpret the absence of controls as a loading failure.
• Sensitivity classification is always visible. The Sensitivity field (Standard | Restricted | Private) from the MeetingNoteRecord must be displayed on every record card, detail view, and share flow, so that users handling the record are always aware of its classification before taking an action.
• Voice profile operations are surfaced as governance actions. Creating, editing, or deleting a voice profile must be presented as a deliberate, auditable action with a confirmation step, not an inline toggle. The RBAC restriction on these operations (§ 10.4) must be enforced at the UI level — controls must not appear for users without the required role.
• The audit log is accessible to authorised roles from within the MeetingNoteRecord detail view. The audit log viewer must show who performed each action, what the action was, and when it occurred — including recording start/stop, playback access, note edits, sign-off completion, action confirmations, task creation links, retention changes, and voice profile mapping events, as required by § 14.
• Recording artefacts are subject to Security & Privacy evidence retention policies. Audio recordings and their derived transcripts are sensitive artefacts under the Security & Privacy module's evidence model. Their creation, access (including playback), and deletion are auditable lifecycle events that must be logged in a manner consistent with the platform's evidence retention configuration — not solely the 30-day default defined in this module. Where Security & Privacy establishes a minimum retention floor or a maximum ceiling for evidence artefacts, those constraints take precedence over organiser-configured expiry values. The retention picker (§ 6, § 5.1 Flow 2 Step 3) must enforce any such bounds silently in the background and surface only the permitted range to the organiser, consistent with Security & Privacy's principle that security controls operate transparently and surface to users only when audit or configuration action is needed. Any conflict between an organiser's chosen retention value and Security & Privacy policy must be surfaced as a clear, non-alarming inline explanation at the point the conflict is detected — not as a post-submission error.

12. Notification & Communication Patterns

The following notification patterns are inferred from the technical spec's audit events (§ 14), Communication Hub integration (§ 13), and the sign-off/Task creation flows (§ 12.2–12.3 and § 9.2). All notifications are delivered via Communication Hub — this module does not send notifications directly.

• In-app banner — used for session-level governance alerts that require user awareness but not immediate action. Appropriate for: NotePack generation in-progress (when the organiser opens the review screen before generation is complete); recording quality degradation warning (if capture quality is insufficient per § 11.3); connectivity loss during a live meeting.
• Toast — used for transient, positive confirmation of completed actions. Appropriate for: successful recording start/stop; successful Task creation from a confirmed action candidate; successful sign-off completion; successful recording share.
• Push notification (via Communication Hub — NOT directly) — appropriate for: notifying participants that a meeting record has been shared with them; notifying the organiser that NotePack generation is complete and sign-off is ready; notifying the owner of a retention review Task that the review date is approaching. These are delivered via Communication Hub per § 13.
• Email/SMS (via Communication Hub — NOT directly) — appropriate for: meeting record share notifications to users who are not currently active in the app; retention expiry reminders for meetings with extended retention. Delivery channel and frequency are governed by Communication Hub and the user's notification preferences, not by this module.

13. Open Questions

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

• Mobile surface scope — is a mobile app review surface (read note pack, review action candidates) in scope for this module? The technical spec does not address mobile explicitly. A decision is needed before the component inventory and flow diagrams can be considered complete.
• In-meeting live note display on tablet — should the tablet's in-meeting view show the live note drafts panel alongside the live transcript, or only the transcript? Showing both may be distracting in a live meeting; showing only the transcript keeps the surface calmer. This is a UX stance decision not resolved by the technical spec.
• Sign-off delegation — the technical spec refers to "organiser (or authorised roles)" completing sign-off (§ 9.1, § 12.2). The UX must define what happens when the organiser is unavailable: can sign-off be delegated? Who is prompted? This affects the sign-off wizard's entry conditions and empty states.
• Partial sign-off recovery — if an organiser begins sign-off and abandons it mid-flow (e.g. closes the browser), what state is the MeetingNoteRecord left in? The UX must define how the system resurfaces an incomplete sign-off and what the re-entry point looks like.
• Voice profile enrolment surface — where in the product does a staff member enrol their voice profile? Is this in AI Meeting Notes settings, in a shared staff profile area, or in Security & Privacy? The touchpoint with Security & Privacy (§ 10.4) needs a clear UX home.
• Communication Hub optional share UX — the technical spec permits (but does not require) posting a meeting summary to Communication Hub post-sign-off (§ 13). The trigger point, default state (opt-in vs opt-out), and exact scope of what is shared (summary only, or summary + action list?) must be defined by a UX writer in collaboration with the Communication Hub module owner.
• Retention picker range and constraints — the default is 30 days (§ 12.1), but the permitted range (minimum, maximum, granularity) for the retention picker is not specified in the technical spec. This must be confirmed with the product owner before the retention picker component can be fully specified. Additionally, any minimum retention floor imposed by Security & Privacy evidence retention policy must be incorporated into the permitted range before the picker is built (see § 11).
• (needs UX writer input — any additional open questions arising from design exploration of the in-meeting tablet surface and sign-off wizard)