Campaign Manager – UX Specification

Related Technical Authority: Campaign Manager – Technical Specification

1. Purpose

This UX specification governs the staff-facing experience for Primoro's Campaign Manager module — the single governed surface through which practice staff design, compose, segment, launch, and analyse multi-step marketing campaigns and journeys. It serves practice owners, marketing managers, and any staff role granted campaign authoring or approval permissions, ensuring that every interaction from first draft to live campaign remains human-controlled, consent-safe, and auditable. The specification translates the technical contracts defined in the Campaign Manager Technical Specification into screen-level layouts, interaction patterns, state representations, and cross-module handoffs.

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.
• Human activation is the gate — no campaign may reach contacts without an explicit human approval action. This principle is derived from the technical spec §7 and §17.2, which prohibit any AI or automated path to an Active campaign, enrolment, or message send.
• App-first by default — the in-app channel is the primary delivery route and must be visually emphasised above fallback channels in every step-composition surface, reflecting the technical spec §10.3's statement that the Primoro patient mobile app is the preferred delivery channel.
• Suppression is always visible — consent exits, booking-triggered exits, and system-paused states must be distinguishable from manually paused states at a glance, because silent continuation is prohibited under all circumstances (technical spec §3.2 and §4.2).
• Visual composition over configuration — building a campaign should feel like assembling connected building blocks rather than completing a form, reflecting the Builder Engine's drag-and-drop, declarative nature (technical spec §3.5).

3. Design Philosophy

The Campaign Manager embodies the mental model of a governed marketing canvas: a structured workspace where practice staff assemble, review, and release marketing activity, supported by an AI assistant that proposes but never acts unilaterally. This framing is derived directly from the technical spec's insistence that all AI output is advisory, all campaigns begin in Draft state, and all activation is a deliberate human step (§7).

Empty states. A practice with no campaigns yet should see an encouraging empty state that makes the three creation paths — blank campaign, template-based, and AI-suggested — immediately accessible, rather than an empty table. This reflects the technical spec §10.1's listing of these three entry points as the primary builder surfaces.

Error states. Validation errors surfaced before activation (consent coverage, suppression rule gaps, fatigue limit breaches, unsafe builder flows) must be inline and located at the specific step or condition that is failing, not surfaced as a single modal block. This is inferred from the technical spec §3.5's requirement that invalid or unsafe flows be rejected at the builder level, and §17.2's rule that no Campaign may transition to Active without passing all checks.

AI suggestions. Aiden's suggestions are visually distinct from user-authored content at all times: clearly badged, never pre-selected, always accompanied by an explanation of why the suggestion is being made. AI-generated drafts remain in Draft state and carry a persistent label until a human explicitly reviews and activates them. This is derived from §7 and §8 of the technical spec.

Multi-step flows. The campaign creation journey uses a progressive wizard model — audience first, then builder composition, then validation, then activation — so that a user cannot reach the activation gate without first having addressed the upstream decisions. This is inferred from the logical ordering of the technical spec's core objects: audience → steps → activation (§3.1, §3.3, §9).

Undo / redo. The builder canvas should support undo/redo within a session. Editing an active campaign creates a new version rather than mutating the live one; in-flight contacts continue on prior logic unless explicitly migrated. This is derived from the versioning and safety implications of the technical spec's immutable audit requirements (§8) and the partial existing UX spec §11.

Read-only vs editable surfaces. Active campaigns are read-only in their current published form; edits create a new version. Draft and Paused campaigns are editable. Completed and Cancelled campaigns are permanently read-only. This mirrors the Campaign State Machine (technical spec §3.2), which prohibits a return to Draft once Active, and prohibits deletion of Active or Completed campaigns.

4. Primary Surfaces

4.1 Web Portal

Who uses it: practice owners, marketing managers, and any staff member assigned a campaign authoring or approval role via Access Manager. This is inferred from the technical spec §9's RBAC model, which defines create, read, update, activate, pause, cancel, and delete permission levels.

Key tasks performed here:

• Browse, filter, and monitor campaigns across all states (Draft, Scheduled, Active, Paused, Completed, Cancelled) via the campaign dashboard — derived from the technical spec §10.1's listing of the campaign status dashboard as a primary web portal surface.
• Create, compose, and edit campaigns and journeys using the drag-and-drop Builder Engine — derived from technical spec §10.1 and §3.5.
• Define and preview audience segments, including dynamic, pipeline-driven, and AI-suggested segments — derived from technical spec §6 and §10.1.
• Review AI (Aiden) suggestions for campaign ideas, templates, audiences, and optimisation recommendations, and accept or dismiss each suggestion with explicit confirmation — derived from technical spec §7.
• Activate, pause, cancel, and manage campaign state transitions via governed actions with confirmation steps — derived from the Campaign State Machine §3.2 and the activation approval model §9.
• Review campaign analytics and attribution data, including delivery funnel, channel breakdown, appointments booked, and opportunities influenced — derived from technical spec §10.1 and §17.4.
• Inspect and export audit trail entries for campaigns under review — derived from technical spec §8 and the auditability requirements.

Layout pattern: the Campaign Manager home uses a dashboard / list-detail pattern. The campaign list is the primary view; selecting a campaign opens a split-pane detail showing the builder canvas (read-only or editable depending on state) alongside the live performance panel. The builder itself is a full-width canvas view. This is inferred from the technical spec §10.1's described surfaces and the existing partial UX spec §3.2.

4.2 Tablet App

The technical specification explicitly notes in §10.2 that the tablet app surface for Campaign Manager has not been defined and needs definition before build. No tablet-specific tasks, layouts, or ergonomic patterns can therefore be specified here without fabricating content not supported by the technical spec.

(needs UX writer input — the technical spec §10.2 explicitly defers this surface. Define: which staff roles need Campaign Manager access on a tablet, which tasks are in scope for tablet, and what the appropriate layout pattern is. This is recorded as Open Question 4 in the technical spec §15.)

Touch ergonomics: (to be defined once scope is established — minimum 48 px touch targets apply when tablet surface is defined, per platform standards.)

4.3 Mobile App (Patient or Staff)

Patients do not interact with Campaign Manager directly. The patient mobile app is the delivery channel for campaign messages executed by Communication Hub; Campaign Manager declares channel intent, and Communication Hub manages app-channel delivery. There is no Campaign Manager UI surface within the patient mobile app. This is stated explicitly in technical spec §10.3.

Staff do not have a Campaign Manager authoring or management surface on the mobile app. All campaign management is performed via the web portal. This is inferred from the technical spec §10's surfaces listing, which names only the web portal as the active staff-facing surface.

5. Interaction Model

5.1 Primary Flows

Flow 1: Create a campaign from blank

Start: User selects "Create Campaign" from the dashboard
  │
  ▼
Step 1 – Name & type
  Choose: one-off / scheduled / dynamic
  │
  ▼
Step 2 – Audience
  Select or build a segment
  Preview estimated audience size + eligibility warnings
  (Consent, fatigue, emergency-stack exclusion applied)
  Family-profile deduplication applied at preview stage
  (see §5.4 — duplicate guardian/dependant contacts removed)
  Rewards programme opt-out status applied at preview stage
  (rewards-related campaigns only — opted-out patients excluded)
  │
  ▼
Step 3 – Build (Builder Canvas)
  Add, order, and connect Step Blocks
  (Message / Delay / Condition / Exit)
  Configure each block: channel intent, content reference, timing
  │
  ├── Aiden suggestion panel available throughout (non-blocking)
  │
  ▼
Step 4 – Validate
  System runs pre-activation checks:
  - Consent coverage
  - Suppression rule completeness
  - Fatigue limit compliance
  - Structural validity (no unsafe builder flows)
  - Family-profile deduplication consistency
  - Rewards opt-out exclusion (for rewards-related campaigns)
  Inline errors at the offending block; must be resolved to proceed
  │
  ▼
Step 5 – Schedule or activate
  Set send time (for scheduled campaigns) or activate immediately
  Explicit confirmation step required
  User must hold Approve permission; if same user as creator,
  practice must be configured as single-operator (Open Question 1)
  │
  ▼
End: Campaign moves to Scheduled or Active state
     Audit event written

Flow 2: Create a campaign from a template

Start: User selects "Create from Template"
  │
  ▼
Browse pre-defined Campaign Templates
  (Aiden may surface recommended templates here)
  │
  ▼
Select template → Pre-populated Builder Canvas opens
  User reviews, edits, and customises steps
  │
  ▼
Continues from Flow 1 – Step 2 (Audience selection)

Flow 3: Review and act on an AI-suggested campaign

Start: Aiden suggestion panel surfaces a campaign idea
  (Panel is non-blocking; user may dismiss without consequence)
  │
  ▼
User selects "Review suggestion"
  AI-generated draft opens in Builder Canvas
  Persistent "AI draft" badge visible throughout
  │
  ▼
User reviews every step — may edit, delete, or add blocks
  │
  ▼
Continues from Flow 1 – Step 4 (Validation)
  AI suggestion provenance recorded in audit trail
  (whether accepted or rejected)

Flow 4: Campaign is system-paused by suppression event

Trigger: Suppression event received
  (Booking confirmed / Consent revoked / Opportunity closed)
  │
  ▼
Campaign transitions immediately to Paused state
  Enrolment halts before any subsequent step executes
  Reason code logged in audit trail
  │
  ▼
Campaign list shows system-paused state
  (visually distinct from manual pause — see §5.2)
  In-app banner notifies relevant staff user
  │
  ▼
Staff user reviews the affected campaign
  Options: resume (if suppression is resolved) / cancel
  Resumption requires explicit confirmation

Flow 5: Edit an active campaign

Start: User opens an Active campaign (read-only canvas)
  │
  ▼
User selects "Edit"
  System explains: a new version will be created;
  in-flight contacts continue on current version
  until migration is explicitly chosen
  │
  ▼
New draft version opens for editing
  Continues from Flow 1 – Step 3 (Build)
  Prior version remains active until new version is activated

Flow 6: Act on a Loyalty Insights cohort-campaign suggestion

Trigger: Loyalty Insights surfaces an action handoff — a cohort of
  patients flagged for outreach based on loyalty scoring or
  cohort definition (e.g. at-risk, high-value, lapsed)
  │
  ▼
Notification appears in Aiden suggestion panel (or in-app banner
  if urgency is flagged) indicating a loyalty-cohort campaign
  opportunity, with the originating cohort label and patient count
  │
  ▼
User selects "Review loyalty suggestion"
  A pre-scoped audience segment is proposed, derived from the
  Loyalty Insights cohort definition; the segment is labelled
  "Loyalty Insights – [Cohort Name]" and carries an AI/source badge
  │
  ▼
Collision check displayed:
  The audience preview panel shows whether any contacts in this
  cohort are already enrolled in an Active or Scheduled campaign
  of a similar type; overlapping contacts are flagged and the user
  may exclude them before proceeding
  │
  ▼
User accepts or modifies the proposed segment and continues
  from Flow 1 – Step 2 (Audience), then proceeds through
  the standard creation or template flow
  │
  ▼
Loyalty Insights handoff provenance recorded in audit trail
  (accepted, modified, or dismissed — as with AI suggestion outcomes)

5.2 State Machines (Mirror of Technical Spec §3.2)

The following maps each Campaign state to its UX treatment, derived from the authoritative Campaign State Machine in technical spec §3.2.

A Campaign MUST NOT show a "Return to Draft" control once it has been Active; that control must not appear for Active, Paused, Completed, or Cancelled states. This is derived from the technical spec §3.2 rule that a Campaign MUST NOT return to Draft once it has reached Active state.

Cancelled and Completed campaigns have no destructive action available. The "Delete" control appears only on Draft campaigns, and only for users with the authoring permission. This is derived from technical spec §9.

5.3 Empty / Loading / Error / Offline States

Campaign dashboard — empty state

When a practice has no campaigns yet, the dashboard shows an encouraging zero-state panel with the three creation paths (blank campaign, template-based, AI-suggested) as primary actions, rather than an empty table. A brief contextual explanation of what Campaign Manager does may accompany this panel. (needs UX writer input — exact zero-state heading and supporting copy.)

Campaign dashboard — loading state

The campaign list uses a skeleton loader pattern (rows with placeholder shapes) while campaign data is fetched. This avoids layout shift and is appropriate for a list-detail surface.

Campaign dashboard — error state

If campaign data cannot be loaded, an inline error message is displayed within the list area with a "Try again" retry action. The rest of the navigation remains accessible so users are not blocked from other parts of the application. (needs UX writer input — exact error message copy.)

Builder canvas — empty state

A new blank builder canvas shows a guided start node ("Audience entry") and a prompt to add the first step block, with the available block types visible in a side tray.

Builder canvas — loading state

When loading an existing campaign into the builder, a skeleton representation of the canvas nodes loads progressively, with block content filling in as data resolves.

Builder canvas — validation error state

Pre-activation validation errors are surfaced inline, directly on the offending block or connection, with a concise explanation of what is wrong and what action resolves it. A summary count of outstanding errors appears in the activation action area. The user cannot proceed to activation while errors remain. This is derived from technical spec §3.5 and §17.2.

Builder canvas — offline state

If connectivity is lost during a builder session, the canvas enters a read-only degraded mode. Unsaved changes are preserved in local session state and a banner informs the user that saves are queued pending reconnection. Activation is disabled while offline. This is inferred from the technical spec §14's reliability requirement that steps be queued rather than dropped, and from the general platform expectation of graceful degradation.

Campaign analytics — empty state

A campaign that has not yet had any enrolments or step executions shows an analytics panel with an explanatory message and the delivery funnel in a zero-data state rather than hidden.

5.4 Audience Deduplication: Family Profiles

When a campaign's audience segment includes contacts linked through Family Profiles — for example, a guardian and one or more dependants registered under the same family account — Campaign Manager MUST apply deduplication logic to avoid sending the same campaign message to both the guardian and a linked dependant.

The segment preview panel (see §6 — Segment preview panel) surfaces a family-profile deduplication summary: the estimated audience size shown reflects post-deduplication counts, and a secondary label indicates how many contacts were removed or consolidated due to family-profile membership. The user cannot disable this deduplication for governed campaign types; it is applied automatically as a suppression rule.

Family-profile membership is also available as an audience attribute in the segment builder, allowing users to deliberately target the responsible guardian contact for family-oriented campaigns (e.g. a campaign about a child's upcoming treatment). In this mode, only the guardian-role contact receives the campaign message; dependant contacts within the same family profile are excluded by the same deduplication rule.

Where a contact appears in multiple family relationships (e.g. a guardian for more than one dependant), the deduplication rule ensures the contact is enrolled once only, regardless of how many family-profile links match the segment criteria. The audit trail records the pre- and post-deduplication enrolment counts for each campaign execution. (needs UX writer input — exact label wording for the deduplication summary in the segment preview panel.)

6. Component Inventory

New components introduced or extended by this module:

• Builder canvas — the drag-and-drop campaign and journey composition surface; hosts step blocks, connectors, branching paths, start node, and exit nodes. Derived from technical spec §3.5 and §10.1.
• Step block — a draggable, connectable canvas node representing a single Campaign Step (message, delay, condition, or exit). Displays channel icon, short description, and validation state. Derived from technical spec §3.3 and §3.5.
• Aiden suggestion panel — a non-blocking side panel that surfaces AI-generated campaign ideas, template recommendations, audience suggestions, and optimisation hints. Each suggestion includes an explanation and explicit accept/dismiss controls. AI badge is persistent. Also surfaces Loyalty Insights cohort-campaign handoff suggestions (see §5.1 Flow 6), which are badged with their source module and cohort label alongside the AI/advisory badge. Derived from technical spec §7 and §10.1.
• Campaign state badge — an inline status indicator that distinguishes Draft, Scheduled, Active, Paused (manual), Paused (system), Completed, and Cancelled states, including the suppression reason on system-paused campaigns. Derived from technical spec §3.2.
• Segment preview panel — shows estimated audience size, eligibility warnings (consent coverage, fatigue, emergency-stack exclusion), family-profile deduplication summary (pre- and post-dedup counts), rewards programme opt-out exclusion count (for rewards-related campaigns), and the dynamic evaluation basis for a selected segment. Derived from technical spec §6 and §6.1.
• Activation confirmation modal — a confirmation step required before any Campaign transitions to Active state; surfaces the approving user's role and a summary of what is being activated. Derived from technical spec §9 and §17.2.
• AI draft label — a persistent label applied to any campaign or step created by Aiden, visible throughout the builder until the campaign is activated by a human. Derived from technical spec §7 and §8 (AI suggestion provenance logging).
• Delivery funnel view — a per-campaign analytics component showing the sent → opened → clicked → converted progression, with channel breakdown tabs. Derived from technical spec §10.4 and §17.4.
• Attribution panel — shows appointments booked, opportunities influenced, and revenue attributed to a campaign, labelled as indicative. Derived from technical spec §17.4 and the outbound contract to Performance Dashboards (§11.2).
• Audit trail viewer — a read-only chronological log of all campaign lifecycle events (creation, edits, state transitions, AI suggestion outcomes, suppression events) for a given campaign. Derived from technical spec §8.

Reused from the design system:

• Toast notification — for transient confirmations (campaign saved, campaign paused). Derived from platform notification patterns.
• In-app banner — for persistent operational alerts (campaign system-paused, suppression event received). Derived from platform notification patterns.
• Filter bar — for the campaign dashboard filters (state, type, date range, AI-generated vs manual). Derived from technical spec §17.4.
• Skeleton loader — for list and canvas loading states.
• Inline form validation indicators — for builder block configuration fields.
• Role/permission indicator in header — surfaces the current user's active role and relevant permissions. Derived from platform governance pattern and technical spec §9.

7. Visual Design Notes

• Typography: (needs UX writer input — heading scale, body scale, monospace usage to be defined by design system; no specific values specified here.)
• Colour: semantic colour usage must distinguish campaign states clearly — positive/active semantic colour for Active state, warning semantic colour for Paused (manual and system), neutral/muted for Draft and Completed, and a visually distinct treatment for system-paused vs manually-paused. Error semantic colour for validation failures. AI-generated content should use a consistent, distinct informational treatment (not error, not warning). Specific hex values are not specified here — these are design system decisions.
• Iconography: channel types (in-app, email, WhatsApp, SMS) must have distinct icons within step blocks; icons must never appear without a label, as step blocks in the builder must remain legible without colour alone. Derived from the step block's requirement to show channel icon and short description (technical spec §3.3 and existing partial UX spec §5.2).
• Motion: transitions between builder states (adding/removing a block, connecting steps, validation pass/fail) may use subtle motion. Suppression-triggered state changes (campaign moves to system-paused) should use a perceptible but calm transition — not an alarming animation. Motion must respect prefers-reduced-motion. No animation should obscure or delay governance-critical information.

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 builder canvas — a drag-and-drop surface — must provide a fully keyboard-accessible alternative interaction path for adding, ordering, and connecting step blocks. Users who cannot use pointer input must be able to build a complete campaign. This is inferred from WCAG 2.2 AA requirement 2.1.1 (Keyboard) applied to the Builder Engine's drag-and-drop surface described in technical spec §3.5.
• Campaign state badges and AI-draft labels must not rely on colour alone to convey meaning; a text label or icon+label combination is required. This is inferred from WCAG 1.4.1 (Use of Colour) applied to the state machine visual treatments.
• The Aiden suggestion panel must be reachable and fully operable via keyboard, and its "accept" and "dismiss" controls must be clearly labelled for screen readers. Derived from the requirement in technical spec §7 that all AI suggestions are advisory and must be explicitly accepted or rejected by a human.

9. Internationalisation

• Locale-aware date/time/number formatting — campaign scheduled dates, performance metrics, audience size estimates, and audit timestamps must all respect the user's locale.
• All user-facing strings externalised — including campaign state labels, builder block descriptions, validation messages, and AI suggestion explanations.
• Layouts tolerant of 30% string-length growth (German, French) — the builder canvas block labels, segment preview panel, and campaign state badges must accommodate longer translated strings without truncation or overflow.
• RTL support: required — the builder canvas horizontal orientation and step-block connector lines must support RTL layout for Arabic or Hebrew locales, given the platform's multi-practice, international scope implied by the multi-tenant architecture in technical spec §14.

10. Cross-Module UX Touchpoints

Where this module's UX intersects with related modules:

• Communication Hub — the user declares channel intent and content references within the Campaign Builder; the actual delivery experience is owned by Communication Hub. When a campaign step executes, the user's view shifts from "step configured" to "delivery reported" via incoming engagement signals (delivery, open, click, reply). The handoff is invisible to the user at execution time but visible in the analytics panel. Derived from technical spec §3.3, §11.1, and §11.2.
• Treatment Pipeline Manager — segmentation events from Treatment Pipeline Manager (cold lead, nurture-eligible, opportunity lost/deferred/won with future potential) appear as pre-built segment entry signals in the audience builder. The user selects these as entry triggers but cannot see or edit the underlying pipeline state. A clear label explains the signal source. Derived from technical spec §5.1 and the event contract table.
• Appointment Manager — booking-confirmed events arrive as suppression signals; the user sees the campaign move to system-paused with a reason label referencing the booking event. No booking action is available within Campaign Manager. Derived from technical spec §4.2 and §11.1.
• Loyalty & Rewards — milestone and anniversary events appear as available campaign trigger options in the audience and entry-condition builder. Derived from technical spec §4.1 and §11.1.
• Loyalty Insights — Loyalty Insights surfaces cohort-based outreach opportunities as action handoffs to Campaign Manager (see §5.1 Flow 6). When a loyalty cohort is flagged for campaign outreach, a suggestion appears in the Aiden suggestion panel badged with its source ("Loyalty Insights – [Cohort Name]") alongside the patient count and the cohort's signal weighting basis. Campaign Manager displays a collision check in the audience preview panel, highlighting any contacts from the proposed cohort who are already enrolled in an Active or Scheduled campaign of a similar type; the user must explicitly choose to include or exclude overlapping contacts before proceeding. Loyalty Insights handoff provenance is recorded in the audit trail whether the suggestion is accepted, modified, or dismissed. Derived from Loyalty Insights §4.1 and technical spec §3.3.
• Smart Treatment Proposals — proposal creation, acceptance, and stalling events are available as segment signals and entry triggers when the Smart Treatment Proposals module is enabled. The builder should indicate which blocks or triggers are conditional on optional modules being active. Derived from technical spec §4.1 and §11.1.
• AI Concierge — concierge outcome signals (concierge.contact.reached, concierge.contact.accepted, concierge.contact.declined, concierge.contact.no_answer) are available as conditional branch triggers within the Journey builder when the AI Concierge module is enabled. A concierge.contact.declined signal must visually map to a suppression-exit branch, distinguishable from other exits. Derived from technical spec §4.1 and the AI Concierge signal table.
• Performance Dashboards — Campaign Manager's analytics panel surfaces campaign-level engagement data; users wishing to see practice-wide revenue attribution or cross-campaign comparisons are directed to Performance Dashboards via a contextual link. Campaign Manager does not own that visualisation. Derived from technical spec §10.4 and §11.2.
• Access Manager — the current user's role and active campaign permissions are visible in the header throughout Campaign Manager. Permission-gated actions (Activate, Approve, Delete) are hidden from users without the relevant permission rather than shown as disabled. Derived from technical spec §9.
• Rewards Manager — when a campaign is rewards-related (i.e. it references a rewards milestone, reward redemption, or loyalty programme communication), Campaign Manager MUST check and honour each targeted patient's rewards programme opt-out status before enrolment. Patients who have opted out of the rewards programme are excluded from rewards-related campaign audiences; this exclusion is surfaced in the segment preview panel as an opt-out count alongside the post-deduplication audience size. The opt-out exclusion is applied automatically and cannot be overridden by staff. This reflects the Rewards Manager UX principle that opt-out is a first-class action and must always be respected without requiring staff intervention. The segment builder labels this exclusion clearly so that users understand why the effective audience is smaller than the raw segment size. (needs UX writer input — exact label wording for opt-out exclusion count in segment preview panel.)
• Family Profiles — see §5.4 for the full deduplication and suppression rules governing campaigns that target contacts linked through Family Profiles. In the audience builder, family-profile membership is an available audience attribute, enabling users to target guardian contacts for family-oriented campaigns. Contacts who would receive duplicate messages due to family-profile relationships are suppressed automatically; the segment preview panel shows pre- and post-deduplication counts. Derived from the Family Profiles multi-party relationship model.
• Audit & Compliance — the audit trail viewer within a campaign detail page surfaces the immutable log written to Audit & Compliance for that campaign's lifecycle. Users with audit read access can export this log. Derived from technical spec §8 and §11.2.

UX consistency rules:

• Action buttons that trigger irreversible state transitions (Activate, Cancel) always require a confirmation modal before executing, regardless of surface. Derived from the general governance requirement in technical spec §3.2 and §17.2.
• AI-generated content — whether a full campaign draft, a template recommendation, or an audience suggestion — is always visually distinct from user-authored content via a persistent AI badge. This applies on the builder canvas, in the template browser, and in the segment builder. Derived from technical spec §7 and §8.
• Suppression-triggered state changes are always distinguished from manual state changes in every list and detail view, with an explicit reason label. Derived from technical spec §3.2 and §4.2.

11. Governance & Auditability

AI suggestions (Aiden) are visually distinct from user-authored campaign content throughout the builder: AI-generated blocks carry a persistent AI badge, and the Aiden suggestion panel is visually separated from the user's canvas. This is derived from the technical spec §7 requirement that all AI output is advisory, explainable, and auditable, and §8's requirement to log AI suggestion provenance.

Audit-significant actions — campaign activation, campaign cancellation, suppression event receipt, and resumption after system pause — each show a confirmation step that summarises what is about to happen and who is acting. The confirmation modal includes the acting user's role. Derived from technical spec §8 and §9.

The current user's role and active campaign permissions are visible in the header at all times within Campaign Manager. Permission-gated controls (Activate, Approve, Delete) are not rendered for users without the relevant permission. Derived from technical spec §9 and §17.3.

Read-only campaign states (Active version, Completed, Cancelled) are visually distinct from editable states (Draft, Paused). The builder canvas in read-only mode displays a persistent read-only indicator. Derived from the state machine rules in technical spec §3.2.

The audit trail viewer on each campaign detail page shows a chronological immutable record of all lifecycle events: creation, edits, state transitions, AI suggestion outcomes (accepted or rejected), Loyalty Insights handoff outcomes (accepted, modified, or dismissed), enrolment counts (including pre- and post-deduplication counts where family-profile deduplication was applied), suppression events with reason codes, rewards opt-out exclusions, and consent enforcement outcomes. The log is exportable. Derived from technical spec §8.

Attribution data in the analytics panel is labelled as indicative, not deterministic, to prevent misinterpretation of correlation as causation. Derived from the existing partial UX spec §10.2 and the nature of marketing attribution as described in the technical spec §3.1.

12. Notification & Communication Patterns

The following notification patterns are used by Campaign Manager, derived from the audit and suppression event architecture in technical spec §8, §4.2, and §11:

• In-app banner — used for persistent operational alerts that require staff attention before next action: campaign system-paused due to suppression event (with reason), validation errors blocking activation, AI suggestion awaiting review on a campaign due to go live, and Loyalty Insights cohort-campaign handoff awaiting review. Banners remain visible until the user takes the relevant action. Derived from the requirement that suppression events halt enrolment and must be surfaced to staff (technical spec §4.2).
• Toast — used for transient confirmations of completed actions: campaign saved, campaign scheduled, campaign manually paused, campaign cancelled, AI suggestion dismissed, Loyalty Insights suggestion dismissed. Toasts auto-dismiss; they are not used for conditions requiring action. Derived from platform notification standards applied to the state transition events in technical spec §3.2.
• Push notification (via Communication Hub — not directly) — Campaign Manager does not send push notifications directly. Any staff-facing push alerts related to campaign activity (e.g. a campaign that requires urgent review) are delivered via Communication Hub. Campaign Manager declares the intent; Communication Hub owns delivery. Derived from technical spec §2.2, which states message delivery is owned by Communication Hub, and §11.2's outbound contract.
• Email / SMS (via Communication Hub — not directly) — Campaign Manager does not send email or SMS directly. All patient-facing and, where applicable, staff-facing messages are delivered by Communication Hub following Campaign Step execution requests from Campaign Manager. Derived from technical spec §3.3 and §11.2.

13. Open Questions

The following UX decisions must be resolved before this specification is promoted from draft to published:

1. Tablet app surface scope — the technical spec §10.2 and §15 (Open Question 4) explicitly defer the definition of the Campaign Manager tablet surface. Before the tablet section of this UX spec can be completed, the following must be answered: which staff roles need Campaign Manager access on a tablet, which tasks are in scope, and what layout pattern is appropriate for in-surgery or reception use?

2. Approval / activation model — the technical spec §15 (Open Question 1) notes that the constraint requiring the activating user to differ from the campaign creator is unresolved, as is the single-operator practice exemption. The activation confirmation modal and the permission model shown in the UI cannot be fully designed until this is resolved.

3. MFA surface for sensitive operations — technical spec §15 (Open Question 2) asks which campaign operations require MFA. If bulk activation or consent-rule overrides trigger an MFA step, a distinct interaction pattern (e.g. an MFA challenge modal inline to the confirmation flow) must be designed. This cannot be specified until the MFA scope is confirmed in Access Manager.

4. eligible_campaign_types[] enum values — the advisory hint from Treatment Pipeline Manager that appears as a signal in the audience builder cannot be labelled or displayed accurately until the permitted values of this field are defined (technical spec §15, Open Question 5). The segment preview panel's display of pipeline-driven eligibility signals depends on this.

5. Cold threshold visibility — the technical spec §15 (Open Question 6) asks where the cold lead threshold is configured and whether Campaign Manager has visibility into it. If Campaign Manager can surface this threshold to users building pipeline-triggered segments, the segment preview panel design must account for it. If not, a suitable explanatory note must be designed for when a pipeline.lead.cold trigger is selected.

6. Emergency stack identifier set — the technical spec §15 (Open Question 7) notes that the full set of source_channel values constituting an emergency stack is not enumerated. The builder must visually warn or block when a user attempts to add emergency-stack contacts to nurture, keep-informed, or drip campaign types. This warning cannot be fully designed until the identifier set is confirmed.

7. (needs UX writer input — all microcopy, button labels, empty-state headings, confirmation modal body text, AI suggestion explanation templates, validation error messages, and toast/banner copy strings throughout this specification require UX writer authoring before design handoff.)

8. Offline capability scope on web portal — the technical spec's reliability requirements (§14) imply graceful degradation but do not specify the exact scope of what a staff user can do on the web portal without connectivity (e.g. can they browse previously loaded campaign data? can they edit a draft?). This must be defined before the offline state designs in §5.3 can be finalised.

9. Loyalty Insights collision-check scope — when a Loyalty Insights cohort-campaign handoff triggers the audience collision check (§5.1 Flow 6), the definition of "similar type" for the purpose of identifying overlapping active campaigns requires agreement between Campaign Manager and Loyalty Insights. The collision check UI cannot be fully designed until the matching criteria are confirmed.

10. Family Profiles deduplication for household campaigns — §5.4 defines deduplication for cases where a guardian and dependant would both receive the same campaign. Where a practice deliberately wishes to send a household-level campaign (one message per household rather than per individual), the mechanism for designating a campaign as household-scoped — and the corresponding audience-builder control — must be defined in conjunction with the Family Profiles module before this interaction can be designed.