# AI loading-state UX for B2B video research Share Pages (Voxpopme Compass) Market Research Report - Global

**Generated on:** 2026-10-15 16:11:17.091577  
**Industry:** AI loading-state UX for B2B video research Share Pages (Voxpopme Compass)  
**Geography:** Global  
**Details:** # Deep Research Prompt: Redesigning the loading experience for AI-assisted Share Page creation

## How to use this prompt

Paste this whole document into each research model (ChatGPT Deep Research, Gemini Thinking, Perplexity, DeepSeek Expert, Claude, Grok). For Grok, prefix it with: "Be maximally contrarian. Challenge every assumption below. What do users secretly hate about AI loading states? What do product teams get wrong? What production failure modes does nobody talk about?"

---

## Context

### The product

Voxpopme is a B2B video research platform used by market researchers, insight teams and product teams at enterprise clients. Researchers upload or collect video responses, analyse them, and share findings. One output is a **Share Page**: a shareable web page that presents findings (clips, quotes, themes, charts, summaries) to stakeholders who may not use the platform.

**Compass** is Voxpopme's agentic AI research assistant. It lives inside the portal and can search a user's data, pull clips, write summaries, build showreels, and generate or format content. During Share Page creation, Compass does background work (gathering content, drafting, formatting) while the user waits.

### The current experience (what the recording shows)

Share Page creation is a multi-step, AI-driven flow. The current loading UI is a chat-style surface that stacks status messages as the work progresses. Specifically:

1. Compass first asks the user a question about the desired format (a choice the user makes before generation starts).
2. Once the user answers, Compass posts a second message and starts working. Progress and status messages then appear.
3. These messages stack and visually overlap with the earlier format question, so the user sees "Compass" as a speaker label twice, plus multiple step or status lines at once.
4. The step messages describe what the system is doing in system terms, so the user does not understand why each step matters or what they will get at the end.

### Stakeholder feedback

- Product lead: "Lots of overlapping messages, Compass written twice, and the value of the steps is lost. Wants something clean, clear, and that shows the value of the work being done in the background."
- Senior front end developer: Compass appears twice because there are two distinct messages, one asking for the format and a second where it is doing the work. This is a structural cause, not a styling bug.
- UX designer: "Yes, this is too busy."

### Acceptance criteria for the redesign

- Cleaner visual experience.
- Overlapping messages removed or reduced.
- "Compass" is not shown twice in a confusing way.
- The value of each step is made clear to the user.
- The loading state helps show the work being done in the background.
- The final experience is clear and easy to understand.

### Existing internal constraints and patterns (do not contradict these)

Voxpopme already has rules for Compass loading copy that any recommendation must fit:

- Compass speaks in first person ("I") for its own work and "we" for the platform.
- Loading messages name the benefit to the user, not the feature or the mechanism.
- Loading tips (optional helpful hints during waits) appear only after roughly 500 ms so fast loads never flash text. One tip per wait, one action per tip.
- Rotating text needs a pause control (WCAG 2.2.2 Pause, Stop, Hide). Status updates are announced politely via role="status" and never steal focus.
- No emojis, no em dashes, no exclamation marks, no "Did you know", no AI marketing words (seamless, unlock, elevate, harness, empower).
- Copy must use words spelled the same in US and UK English where possible.
- Strings are localised (English and German) and cannot be concatenated.
- Brand voice: confident, straight-talking, a hint of playful, honest about limits.
- If the wait fails or runs long, the UI hands over to an error or degraded-state pattern ("This is taking longer than usual. You don't need to refresh.").

### Technical setting

- Web application (React front end) inside the Voxpopme portal.
- Generation is a server-side agentic process with multiple discrete steps. Step count and duration vary by data size. Typical waits range from a few seconds to a couple of minutes. Steps can be reported to the client as they complete.
- The format question and the generation progress are currently two separate assistant messages in one chat-like surface.

### What we need from this research

Evidence-based guidance for redesigning this loading experience so that it (a) reads as one coherent process rather than a stack of messages, (b) communicates the value of what Compass is doing, (c) feels reassuring rather than noisy, and (d) is implementable by a small front end team within existing constraints. We are open to the answer being "this should not be a chat surface at all".

---

## Research sections

Answer every section. Where evidence is weak or contested, say so.

### 1. Perceived wait time and the psychology of loading

1. What does the research say about perceived versus actual wait time for operations in the 5 second to 2 minute range, and which interventions reliably reduce perceived duration?
2. At what durations should the UI switch between no indicator, a simple indicator, a determinate or step-based indicator, and a "do something else, we'll notify you" pattern?
3. What is the evidence on "labour illusion" (showing the work being done) increasing perceived value, and when does it backfire or feel theatrical?
4. How do users' expectations differ when they know an AI agent is working versus a conventional system process?
5. What causes users to abandon, refresh, or double-submit during waits, and what prevents it?

### 2. Progress disclosure patterns for multi-step AI generation

1. Compare steppers, checklists, timelines, single rotating status lines, streaming partial output, skeleton screens and progress bars for multi-step AI work. When does each fit?
2. How do leading AI products (for example ChatGPT, Claude, Perplexity, Gemini, Notion AI, Canva Magic Studio, Gamma, Figma AI, GitHub Copilot Workspace, Devin, Manus) show agent progress? Describe the specific patterns and what each is good at.
3. How should completed, in-progress and pending steps be visually distinguished without creating clutter?
4. Should step lists be fixed up front or appear as discovered? What are the trade-offs for honesty and reassurance?
5. How should a UI handle variable or unknown step counts and durations without lying to the user?

### 3. Communicating value, not mechanism

1. What copy frameworks turn system actions ("Calling search API", "Formatting output") into user-facing value ("Finding the clips that answer your question")?
2. Is there evidence that benefit-led step labels improve satisfaction, trust or perceived quality of the final output?
3. How much detail per step is right? Where does transparency become noise?
4. How should the UI summarise what was done once the work completes, so the value is retained rather than vanishing?
5. Give 8 to 12 example step labels for a Share Page build (gathering clips, selecting quotes, drafting summary, applying layout, checking for gaps) written as user value in a plain, confident, lightly playful voice, with no exclamation marks, emojis or em dashes, and using US/UK neutral spelling.

### 4. Conversational AI versus task UI: when chat is the wrong surface

1. When is a chat transcript the right container for an agent's progress, and when should progress be lifted into a dedicated panel, drawer, card or inline component?
2. How do products avoid the "two bubbles from the assistant" problem when the assistant first asks a question and then starts work? What patterns merge, collapse, or replace the earlier turn?
3. What are proven patterns for collapsing completed agent messages or steps into a compact summary line?
4. How should the format question (a user decision) be visually and structurally separated from generation status (system progress)?
5. What are the risks of moving progress out of the chat (loss of context, discoverability, inconsistency with other Compass flows) and how do products mitigate them?

### 5. Visual design and information hierarchy of loading states

1. What visual hierarchy rules reduce clutter in stacked status UIs (spacing, typographic scale, single accent, de-emphasis of completed items, avoidance of repeated avatars or labels)?
2. When a speaker label or avatar is needed, how often should it repeat? What do chat and messaging interfaces do about consecutive messages from the same sender?
3. How should animation be used (motion as reassurance versus motion as distraction)? Include guidance on prefers-reduced-motion.
4. What skeleton or placeholder patterns work for a document-like output such as a Share Page, so the user sees the shape of what is coming?
5. Which component libraries or design systems (Material, Carbon, Polaris, Atlassian, Fluent, Ant, Radix, shadcn) have published loading and progress patterns worth borrowing, and what do they recommend?

### 6. Accessibility and inclusive design

1. What are the WCAG 2.2 requirements that apply to loading states, live regions, rotating text, animation and status messages?
2. How should progress be announced to screen reader users during multi-step work without flooding them with announcements?
3. How should focus be managed when the work completes and the Share Page appears?
4. What patterns support users with cognitive or attention differences during long waits?
5. What are common accessibility failures in AI progress UIs seen in audits or user reports?

### 7. Trust, honesty and expectation setting

1. How should the UI set expectations about duration when it is genuinely uncertain? Compare "about a minute", ranges, no estimate, and relative statements.
2. What is the evidence on fake or decorative progress (slow bars that never finish, invented steps) damaging trust?
3. How should the UI communicate that the user can leave and come back, be notified, or cancel, without that option dominating the interface?
4. How should partial or degraded results be surfaced if a step fails but the page can still be built?
5. How do products communicate that AI output needs review without undermining the sense of value?

### 8. Interaction during the wait

1. Should the user be able to do anything useful while the page builds (edit title, pick a template, answer a follow-up question, read a tip)? What is the evidence on productive waiting versus distraction?
2. How should cancel, pause and "change my format choice" be handled mid-generation?
3. What is best practice for loading tips or hints during waits, including timing, rotation, dismissal and relevance to the current task?
4. How should the UI behave if the user navigates away and returns, or opens the flow in a second tab?
5. When the work completes, what transition from loading state to result produces the strongest sense of value and completion?

### 9. Technical implementation

1. What front end architecture (state machine, event stream, polling, websockets, server-sent events) best supports a step-based progress UI where step count and timing vary? Give a recommended state model with named states and transitions.
2. How should the client handle out-of-order, duplicated, missed or very fast step events so the UI stays readable?
3. What is a sensible minimum display time per step so steps do not flash past, and how should that be balanced against honesty?
4. How should the component be structured in React so the format question, progress and result are one coherent component rather than three independent chat messages?
5. How should localised strings be organised for a step-based progress UI with variable steps, given no string concatenation is allowed?

### 10. Measurement and evaluation

1. What metrics indicate a loading experience is working (abandonment during wait, refreshes, repeat submissions, time-to-first-meaningful-content, satisfaction, perceived speed)?
2. How should we run a usability test of a loading state when the real wait is 30 to 120 seconds? Include methods for testing perception and comprehension of step value.
3. What are good survey or interview questions to establish whether users understood what Compass did and why it mattered?
4. How would we A/B test two loading designs when the outcome is perception rather than conversion?
5. What qualitative signals in user feedback indicate "too busy" versus "too opaque"?

### 11. Competitive and adjacent landscape

1. How do market research and insight platforms (Qualtrics, Dovetail, UserTesting, Maze, Lyssna, Remesh, Discuss.io, Aha, Condens) show progress during AI analysis or report generation?
2. How do report and presentation generators (Gamma, Beautiful.ai, Canva, Tome, Notion AI, Google Docs or Slides AI) handle the wait while a multi-section document is assembled?
3. Which products are widely praised for their AI progress UX, and what specifically do users praise?
4. Which products are criticised for noisy, cluttered or confusing AI progress, and what went wrong?
5. What could Voxpopme do here that none of these products currently do, given it is working with video, quotes and research evidence rather than generic text?

### 12. Edge cases and failure modes

1. What happens when a step takes far longer than expected? Define thresholds and the UI response at each.
2. What happens when generation fails entirely, fails partially, or produces an empty page? How should each be shown without alarming the user?
3. How should the UI handle very fast completions (under 2 seconds) so it does not flash a full progress sequence?
4. What are the risks of showing the user step names that reveal internal tool names, data sources or model limitations?
5. What are the most common ways redesigns of loading states fail after launch (looks clean in Figma, breaks with real timing), and how do teams guard against this?

---

## Output instructions

- Produce a structured report following the 12 sections above, with a short executive summary at the top.
- Give concrete, implementable recommendations: specific states, thresholds in milliseconds or seconds, component structures, copy examples, and visual rules. Avoid ranges where a single recommended value is defensible.
- Cite sources for every claim about research findings, standards or how a named product behaves. Prefer primary sources (research papers, WCAG, design system documentation, product documentation, first-hand teardowns).
- Flag trade-offs explicitly. Where two credible approaches conflict, present both and recommend one with reasoning.
- Call out anything surprising, counter-intuitive, or that contradicts the assumptions in the Context section.
- Finish with: (a) a recommended state model for the component, (b) a one-page summary of design principles for this loading experience, (c) a prioritised list of what to prototype and test first, and (d) the open questions that research alone cannot resolve and that need user testing with Voxpopme customers.
- Write in plain English. No marketing language. No emojis. No em dashes.

---

# Make Compass Share Page Waits Clear and Credible

## Executive Summary

- **Fix The Structure First**: The brief describes two assistant messages competing with a growing status stack. Replace them with **one persistent task card inside Compass**, moving from format choice to progress to draft. Grouped messaging interfaces already avoid repeating the avatar on consecutive messages from one author. [52]
- **Show Outcomes, Not Busyness**: Operational transparency can increase perceived value, but the advantage can disappear or reverse when the result disappoints. Show genuine evidence gathering and useful completed work, not an invented performance of effort. [7]
- **Keep Progress Truthful**: Unknown agent duration does not support an honest percentage. Use three outcome groups, **Evidence, Draft, Page**, without treating them as equal portions of time. Material distinguishes determinate progress from work whose progress or duration is unknown. [3]
- **Do Not Assume Skeletons Feel Faster**: One skeleton-versus-spinner study found **no significant differences**. A small AI research-interface pilot preferred informative processing feedback, but its fixed delay and narrow sample limit generalisation. Start with a calm status card, not a two-minute shimmering document. [15][46]
- **Make Leaving Safe Before Suggesting It**: Gemini documents leaving a research chat and receiving a mobile notification; Manus describes asynchronous cloud work. Compass needs a durable job and return path before making the same promise. [45][43]
- **Make Quietness Accessible**: WCAG requires programmatically identifiable status messages without moving focus, and warns against excessive live-region chatter. Use one polite status region, sparse meaningful updates, and no automatic focus jump on completion. [9]
- **Keep The Implementation Small**: Use one React state owner, a server-authoritative job snapshot, and the existing transport. If no event infrastructure exists, start with **2,000 ms polling**, not a new WebSocket system. Asynchronous request-reply supports an accepted request followed through a status endpoint. [34][10]
- **Measure Understanding, Not Watching**: A longer gaze at the loader is not success. Measure comprehension, perceived duration, refreshes, duplicate submissions, safe return, and eventual draft use. Google's HEART and Goals-Signals-Metrics frameworks support connecting attitudinal and behavioural measures to a specific product goal. [33]

**Scope:** Global B2B research and adjacent AI document-generation products, with English and German implementation requirements. This is an interaction and competitive-landscape report, not a defensible standalone market-size estimate. Product documentation often establishes a workflow without documenting its exact loading animation; those distinctions are retained below.

**Recommendation status:** Specific timings, visual tokens, component structures, and test sample sizes below are **proposed Compass defaults**, not experimentally established universal thresholds. The supplied brief is the basis for the diagnosis of the existing Compass flow.

## 1. Perceived Wait Time: Reduce Uncertainty Without Manufacturing Effort

### What the evidence supports across five seconds to two minutes

Actual duration, perceived duration, and perceived value are different outcomes. A loading treatment can improve one without improving the others. Nielsen's familiar **0.1-second, 1-second, and 10-second** limits describe perceived immediacy, uninterrupted thought, and sustained attention; they are useful heuristics, not precise thresholds validated for agentic Share Page creation. [14]

| Evidence | Finding | Implication for Compass |
|---|---|---|
| Buell and Norton, operational transparency | Showing work increased perceived value; some participants preferred a transparent delayed service to an instantaneous opaque one. [7] | Make genuine work understandable, but do not deliberately slow completion. |
| Progress-bar experiments | Research tested visual treatments at **5 and 15 seconds**, including a study with **10 participants**. [59] | Short-wait perceptual effects do not establish a solution for a two-minute research task. |
| Skeleton-versus-spinner study | No significant differences across the reported comparisons. [15] | Treat skeletons as orientation, not a proven speed improvement. |
| AI research-interface pilot | **9 of 13** preferred an informative processing indicator; all ranked skeleton feedback last. [46] | Test meaningful activity descriptions, while respecting the small, homogeneous sample. [46] |
| AI image-generation interviews | **7 of 11** did not notice generation cues until prompted; participants associated longer waits with better output. [49] | Do not assume users inspect every progress message or want maximum detail. |

The strongest practical conclusion is not that a particular animation reliably shortens every wait. It is that Compass should acknowledge the request, make the current situation comprehensible, provide an exit or recovery path, and avoid unnecessary attention demands. Direct evidence covering enterprise video-research waits throughout the full **5-120 second** interval remains weak.

### Case study: The labor illusion has an outcome-quality limit

Buell and Norton's experiments explain the **labor illusion** through perceived effort and reciprocity: visible work can make a service feel more valuable. Simply listing intended work is not equivalent to making its execution visible. [7]

However, transparent waiting followed by an unfavourable result could produce lower value perceptions. The mechanism therefore argues against promising meticulous research work and delivering an empty or weak page. Compass should retain evidence of what actually succeeded and describe omissions precisely, rather than increasing the amount of loading theatre. [7]

### Proposed timing and reassurance

Acknowledge submission immediately; reveal additional loading UI after **500 ms**. For a wait extending past **10 seconds**, show useful outcome structure. At **30 seconds**, make a supported leave-and-return option more prominent. Section 12 specifies the complete timing policy.

AI introduces uncertainty about both time and answer quality. The conflicting AI studies above suggest expectations are task-dependent, not uniformly more patient or more demanding. Prevent refreshes and duplicate submissions with visible acknowledgement, a stable job identity, clear recovery, and server-side idempotency. A first-hand Deep Research complaint describes repeated refreshes and retries when a progress bar appeared stuck, illustrating the failure mode without establishing its prevalence. [42][36]

**Decision:** Optimise understandable progress and actual result quality before investing in perceptual tricks.

## 2. Progress Disclosure: Use Stable Outcomes With Optional Detail

### Choose a pattern that matches what the server knows

The following comparison is a design recommendation, informed by design-system distinctions between known and unknown progress and by research on informative feedback. [3][46]

| Pattern | Best fit | Main risk | Compass recommendation |
|---|---|---|---|
| Stepper | A small, known sequence with meaningful stages | Implies a fixed order and predictable remaining work | Use unnumbered outcome groups only where that sequence is real. |
| Checklist | Reporting completed outputs | A growing task list becomes another transcript | Put detailed completions under "View work". |
| Timeline | Auditable, complex agent activity | Timestamps and tool events dominate the task | Optional detail, not the default view. |
| Single status line | One understandable current activity | Rotating copy can feel repetitive or hide history | Default to one event-driven, benefit-led line. |
| Streaming partial output | Stable, usable draft sections | Early text may change or appear falsely final | Add later, only for persisted content labelled as a draft. |
| Skeleton | A predictable document layout | Suggests content is imminent; prolonged shimmer distracts | Optional static outline, not the main progress signal. |
| Progress bar | A genuine measurable denominator | Tool counts masquerade as time remaining | Use for measurable suboperations, not total agent completion. |

The default should show **Evidence, Draft, Page** as outcome groups, one active status, and a compact completed-work receipt. Completed items use a check plus text; active work uses the single accent and a textual state; pending work stays neutral. Do not communicate these distinctions by colour alone.

### What leading AI products actually document

| Product | Documented pattern | Useful lesson or limitation |
|---|---|---|
| ChatGPT Deep Research | Reviewable plan, progress following and interruption, then a cited report with sources and activity history. [21] | Separate planning, execution, and the final artifact. |
| ChatGPT agent | On-screen narration with interruption and browser takeover. [20] | Explain action while retaining user control. |
| Claude Research | Research-mode indicator and cited answers delivered in minutes. [44] | Mode visibility is documented; a specific live stepper is not. Disabling the mode is not evidence of cancelling a running job. |
| Perplexity Research | Iterative research followed by an exportable report or shareable Page. [19] | Strong result handoff; exact loading layout is not established here. |
| Gemini Deep Research | Editable research plan; mobile documentation permits leaving and describes completion notifications. [45] | Plan first, background work second; notification behaviour is platform-specific. |
| Notion Research Mode | Shows sources while gathering insights; documentation says complex work can take up to **10 minutes**. [18] | Source disclosure can make waiting useful. |
| Canva AI presentations | Outline review and section changes before generating the design. [27] | Resolve structural decisions before expensive generation. |
| Gamma | An official tutorial describes choosing input and then generating editable slides. [31] | Artifact creation is documented, not a verified current streaming animation. |
| Figma Make | Chat-driven generation with a code editor. [39] | A hybrid task surface is documented; exact progress visuals are not. |
| Devin | Dedicated Progress tab with work details, alongside chat and tools. [29] | Put detailed execution outside the conversational stream. |
| Manus | Developer listing describes a task list, cloud execution, and completion notification. [43] | Background completion can replace prolonged monitoring. |
| Copilot Workspace | Editable specification and plan before changes; preview ended **May 30, 2025**. [25] | Useful historical pattern, not an active-product benchmark. |

### Case study: Borrow Devin's separation, not its density

Devin combines a dedicated progress surface with developer-level execution detail. Its side chats can answer questions without interrupting the main task. That is a useful separation of conversation from execution. [29]

Compass should borrow the separation but not expose command logs. Use a small outcome card, with technical detail translated into research-relevant completions. Keep the three outcome groups stable, but let genuine substeps appear as discovered inside the optional details. If only completion events exist, show confirmed completions and a generic running line; **do not infer that the next step has started**.

**Decision:** Use stable outcome structure above a truthful, expandable execution history, not a fixed list of guessed agent steps.

## 3. Value-Led Copy: Explain What Changes for the Researcher

### A practical framework, not a proven wording formula

Use this editorial structure: **I + useful action + the evidence or outcome the user needs**. For example, replace "Calling search API" with "I'm finding the clips that answer your question." Replace "Formatting output" with "I'm putting the key findings first."

This is a proposed copy framework. Operational-transparency research supports making effort meaningful, while Microsoft's Guidelines for Human-AI Interaction call for understandable capabilities, correction, and explanations. Neither establishes that benefit-led English step labels, by themselves, causally improve satisfaction or trust in this particular setting. [7][1]

### Ten candidate labels for actual Share Page work

| Actual work, if implemented | User-facing label |
|---|---|
| Retrieve relevant video | I'm finding the clips that answer your question. |
| Select supporting quotes | I'm picking quotes that make each point clear. |
| Group related material | I'm grouping related views so the story is easy to follow. |
| Include contrasting evidence | I'm bringing different views into the picture. |
| Draft the summary | I'm drafting a summary you can share. |
| Attach source references | I'm linking each point to its source. |
| Prioritise findings | I'm putting the key findings first. |
| Place video in the layout | I'm giving each clip a clear place on the page. |
| Check evidence gaps | I'm checking which points still need support. |
| Finish the saved draft | I'm getting your draft ready to review. |

These are alternatives mapped to real operations, **not ten mandatory visible steps**. Do not claim source linking, contrasting-view checks, or gap detection unless the pipeline actually performs them. Selecting a quote must not imply silently rewriting the participant's words.

### Case study: Source-linked summaries make the benefit concrete

Condens describes AI returning relevant quotes and highlights, and session summaries linking back to relevant transcript moments. The value is not merely that analysis happened; a researcher can get from a summary to the underlying evidence. [26]

Compass can use the same mechanism during and after generation. A completed receipt such as "I've added {clipCount} clips to your draft" is useful when the count is real and the clips are inspectable. A vague "I've analysed everything" is harder to verify and may overstate coverage.

### Detail during work, evidence after work

Show one sentence by default. Put source names, completed counts, or limitations on a secondary line only when they add new information. Keep raw APIs, model names, retries, and internal tool identifiers out of the primary copy.

At completion, retain a compact receipt: selected format, actual clips and quotes included, source links, and any unresolved gaps. Use "I've built your draft. Review it before you share." rather than an unqualified promise of a finished research conclusion. The receipt should support inspection, not become a victory message that disappears.

**Trade-off:** More detail can demonstrate effort but compete with the result. Prefer a short visible receipt and an expandable work summary.

**Decision:** Translate real operations into useful outcomes, then preserve the evidence of those outcomes after loading ends.

## 4. Chat Versus Task UI: Keep the Context, Replace the Transcript Stack

### Where conversation helps, and where it gets in the way

Chat is appropriate when the next action depends on an open-ended exchange: refining the question, resolving ambiguity, or discussing results. A dedicated task component is preferable when the user has committed to an operation and mainly needs its status, controls, and output. This is a design inference, consistent with Microsoft's emphasis on visible agent status and controls for background activity. [35]

For this flow, **do not redesign Compass as a whole**. Insert one task card into its existing surface. That is smaller in scope than moving everything into a separate drawer, and directly addresses the structural cause described in the brief.

```text
Compass
Create Share Page

Format: {chosenFormat}

I'm building a Share Page from your research.
Evidence   Draft   Page

View work
Stop build
```

The example shows hierarchy, not final spacing or a claim that all three groups are currently running.

### Case study: Planning and execution need different treatment

ChatGPT Deep Research lets users review and modify a plan before execution, then follow progress and inspect a completed report. It does not require the planning decision to remain visually equal to every subsequent status update. [21]

Compass has a simpler version of the same boundary. The format question is a **decision**; generation is **system progress**. Once selected, transform the question controls into a compact "Format: {chosenFormat}" receipt within the same task. Preserve the decision in task history, but stop presenting it as an unanswered assistant question.

### Eliminate two competing assistant bubbles structurally

Use one stable task identity and one Compass header. Update the card's internal state rather than appending assistant messages for every milestone. If the chat architecture requires separate records for audit purposes, render related records as one task group with one visual header.

This is also consistent with messaging-component practice: MUI groups consecutive messages by author and shows the avatar only on the first message. That supports removing redundant identity cues, although it does not prove that grouping alone solves the entire loading experience. [52]

Collapse completed work into a line such as "Evidence selected" with a disclosure control. Keep the current activity visible, and move expanded details below it rather than pushing the format decision and primary controls out of view. Avoid a drawer for the first release unless portal navigation already provides a familiar persistent task location.

Moving progress out of the transcript can lose context or discoverability. Mitigate that with the selected format, task title, persistent job link, and a compact return marker in the chat. Use the same task component in other Compass flows only after checking that their interaction model fits.

**Decision:** Keep Compass as the conversational container, but make Share Page creation a single task, not a conversation with itself.

## 5. Visual Hierarchy: One Focal Point, No Continuous Spectacle

### Proposed visual rules for the first prototype

Use **24 px card padding**, **16 px between groups**, and **8 px within a group**. Start with a **16 px semibold** task title, **14 px medium** active status, and **14 px regular** secondary detail. These are prototype tokens to adapt to the portal's existing scale, not research-derived values.

Use one accent for current activity. Completed items should be quieter through placement and weight, not unreadably low opacity. Keep one Compass avatar or name per task group. Use normal document flow rather than positioning status text over earlier messages. Reserve enough space for wrapping, especially in German, but do not force every state into a fixed-height box.

### Design-system patterns worth borrowing

| System | Published guidance | Compass implication |
|---|---|---|
| Material | Show overall group progress rather than separate indicators for each activity. [3] | One task-level indicator, not several simultaneous spinners. |
| Carbon | Use inline loading for one processing component; skeletons belong on content containers, not action controls. [12] | Keep the portal usable around the task. |
| Atlassian | Supports indeterminate progress when percentage is unknown. [6] | Unknown progress must not acquire an invented numeric value. |
| Fluent 2 | Prefers determinate progress where possible, discourages long indeterminate waits and inaccurate time units. [57] | A bare endless bar is not enough for a long agent job. |
| Ant Design | Steps expose waiting, processing, finished, and error states. [58] | Borrow distinct semantic states, not necessarily a new dependency. |
| Radix | Progress supports assistive-technology context and indeterminate state. [61] | A primitive still needs correct labels and task logic. |
| Polaris | The referenced Loading component is deprecated in favour of App Bridge Loading. [11] | Do not copy an obsolete component implementation. |
| shadcn | Implementation recommendation: retain an existing installation if suitable. | Do not migrate libraries merely to obtain a loading bar; audit the rendered semantics. |

These systems disagree on timing and acceptable indeterminate use. Borrow their semantic distinctions, not a universal duration rule.

### Case study: Carbon's scope rule prevents an unnecessary portal lock

Carbon distinguishes an inline processing component from an entire page that is loading, and describes progressive loading from basic structure to more detail. [12]

Share Page generation fits a local task more naturally than a full-screen blocker. The implication is to keep navigation and unrelated research available, provided the job persists. A page-shaped placeholder can orient the researcher without preventing all other work.

### Motion and document placeholders

For a Share Page, an optional static outline can show a title area, summary block, evidence sections, and video positions. Do not show fake quotes, fabricated thumbnails, or a precise clip count before content is known. Clearly label the area as a preview; replace placeholders with actual persisted content when available.

Avoid typewriter effects, perpetual shimmer, animated ellipses, auto-scrolling logs, and several competing spinners. Respect `prefers-reduced-motion` by removing non-essential motion rather than merely slowing it. W3C identifies unnecessary motion as a source of distraction and vestibular symptoms and recommends supporting reduced-motion preferences. [5]

**Decision:** Establish confidence through stable layout and readable state changes, not through constant movement.

## 6. Accessibility: Announce Meaningful Change Without Taking Over

### Applicable WCAG 2.2 requirements

| Requirement | What it means here |
|---|---|
| **4.1.3 Status Messages, AA** | Expose waiting, progress, success, and relevant error status programmatically without requiring focus. [9] |
| **2.2.2 Pause, Stop, Hide, A** | Qualifying automatically moving content lasting over five seconds needs a control; auto-updating content has a separate requirement with **no five-second exception**. Essential-content exceptions are narrow. [4] |
| **2.3.3 Animation from Interactions, AAA** | Non-essential interaction-triggered motion can be disabled. Support reduced motion regardless of the minimum conformance target. [5] |
| **1.4.3 Contrast, AA** | Normal text generally needs **4.5:1**; large text **3:1**. [60] |
| **1.4.11 Non-text Contrast, AA** | Meaningful component and state cues generally need **3:1** against adjacent colours, subject to exceptions. [55] |
| **2.4.3 Focus Order, A** | Preserve a logical sequence when content changes. [56] |
| **2.5.8 Target Size, AA** | Pointer targets need **24 by 24 CSS px**, or must meet an applicable exception. [53] |
| **1.4.10 Reflow, AA** | Support narrow layouts without unnecessary two-dimensional scrolling, including at **320 CSS px** width for vertically scrolling content. [54] |

A loading spinner is not automatically exempt from pause requirements simply because it signals work. In particular, the preload exception does not justify motion beside otherwise usable portal content. The internal rule requiring a pause control for rotating text should remain unchanged. [4]

### Proposed announcement and focus policy

Mount one stable `role="status"` region before updates arrive. Announce meaningful phase changes, not every tool call, token, or clip found. Start testing with a **5,000 ms minimum interval between non-terminal announcements**; coalesce intervening changes. Announce completion or a blocking problem promptly. This interval is a proposed default, not a WCAG requirement.

W3C explicitly warns that live regions can become too chatty and calls for user testing. Keep the detailed work history outside the live region. If using a progress bar, give it an accessible name and omit `aria-valuenow` when progress is indeterminate. [9][2]

Mark only the relevant preview region busy. Do not place the announcement region inside a busy ancestor that suppresses its updates. Keep controls reachable, and avoid replacing the focused element with an unrelated DOM node. A persistent primary-action button can move from starting the build to opening the draft while retaining its identity.

### Case study: Historical chatbot audits reveal structural failures

A Harvard screen-reader review conducted on **August 25, 2023** found useful status announcements in Bard, confusing navigation to generated content in Claude, and reading/navigation problems in ChatGPT. These are historical findings, not current accessibility rankings. [37]

The lesson is broader than adding ARIA after the visual design: users need to know work started, locate the new result, and continue in a logical order. On automatic completion, keep focus where it is and announce readiness. When the user activates "Review draft", move focus to the draft heading or editor entry point. Provide static copy, a clear return location, and optional detail for users who find motion or changing text distracting.

**Decision:** Make progress perceivable without requiring users to watch it, hear every event, or recover lost focus.

## 7. Trust and Expectations: Make Only Promises the Job Can Keep

### Duration language should follow evidence, not tone preference

| Approach | Advantage | Risk | Recommended use |
|---|---|---|---|
| "About a minute" | Easy to understand | Sounds like a commitment when variability is high | Only when comparable-job telemetry supports it. |
| A time range | Expresses uncertainty | A narrow range can still mislead; a very wide range adds little | Use a calibrated prediction interval, if available. |
| No estimate | Avoids false precision | Can leave users unsure whether to stay | Default initially, paired with real status and a return path. |
| Relative wording | Simple and calm | "Nearly done" or "taking longer" may be false | Use "I'm still building your page" when running is verified; comparisons need a baseline. |

Do not present a median as a deadline. If estimates are added, segment by factors that actually predict duration, such as data volume or media processing, and monitor whether the displayed estimate is usually credible. Do not infer remaining time from completed tool calls.

Fluent advises avoiding inaccurate time units, while Material supports determinate progress when progress and wait time are known. These are compatible once measurement quality is the deciding factor. [57][3]

### Case study: A stuck bar creates recovery behaviour, not reassurance

An OpenAI community report describes a Deep Research bar with no visible progress, followed by repeated logout, refresh, and prompt retries. The report does not establish the technical root cause, but it shows how an ambiguous status can lead a user to intervene repeatedly. [42]

For Compass, a frozen-looking display should lead to a status check and a truthful connection or long-wait state, not a bar that creeps toward 99%. Distinguish "the job is still running" from "I cannot retrieve its status". This is a reliability contract, not just more reassuring copy.

### Fake progress, partial results, and review

Evidence for a broad, long-term causal claim that decorative progress damages trust is limited in the reviewed material. Nevertheless, fabricated steps and percentages create promises the system cannot substantiate. Labor-illusion findings also show that visible effort does not rescue an unfavourable outcome. [7]

Offer a quiet "Stop build" action and, where genuinely supported, a return link. Do not promise notifications before delivery and permission handling exist. In-app completion is a sensible first option; email or browser notifications should be an explicit user choice.

If a non-critical step fails, offer the saved draft with an exact omission: "I've built a draft without the showreel. Review the page or try that part again." Preserve successful work. If evidence is missing, identify the affected section rather than applying a generic warning to the whole document.

Frame review as useful control: inspect selected clips, quotes, and claims before sharing. Microsoft's guidelines support efficient correction and graceful degradation, rather than presenting AI output as unquestionable. [1]

**Decision:** Trust comes from accurate state, recoverable work, and inspectable evidence, not from sounding certain.

## 8. Interaction During the Wait: Offer Freedom, Not Busywork

### Useful activity should be optional and independent

Do not add tasks merely to occupy the researcher. An optional title edit can be useful if it saves independently and cannot be overwritten by generation. Changing the template or evidence scope is different: it may invalidate work already underway. For the first release, keep those decisions before submission and avoid adding compulsory follow-up questions during a build.

Maister's waiting-line framework suggests that an activity offered during a wait should have value in itself and relate to the service. This is conceptual guidance from service settings, not a controlled result for B2B AI software. [16]

### Case study: Productive waiting differs from distraction

Maister describes cases where changing the experience of waiting, rather than its duration, reduced complaints, including mirrors near elevators. The same account argues for activities that provide their own benefit rather than merely filling time. [16]

For Compass, watching a playful animation or reading generic tips does not advance the research. Reviewing the chosen format or seeing a saved evidence receipt may. However, requiring another decision can extend the task or introduce errors, so productive waiting must remain optional.

### Controls with unambiguous meanings

| Control | Meaning | Behaviour |
|---|---|---|
| Stop build | Ask the server to stop generation | Show a pending cancellation state until acknowledged. Preserve any saved work. |
| Pause updates | Pause optional rotating text or motion | Do not imply that server work has paused. Resume from the latest state. |
| Change format | Revise the requested output | Before submission, edit directly; during generation, explain whether restart is required and confirm it. |
| Leave and return | Continue elsewhere while the job persists | Keep a stable return location and retrieve the same job on return. |

Do not add a job-pause button unless the backend can actually suspend and resume execution. Microsoft's guidance supports dismissal and correction, but these controls still need truthful operational semantics. [1]

### Tips, navigation, and completion

Keep the existing **500 ms eligibility gate** for tips. Default to no tip in the MVP. If tested, show **one task-relevant tip at 10 seconds**, one action, dismissible, with no rotation. Never replace a warning or current progress with a tip.

Navigation away should not cancel a durable job. On return or in another tab, request the server snapshot rather than starting again. If background durability is not available, do not invite the user to leave. Gemini's documented mobile research workflow explicitly supports leaving and notification, illustrating the capability Compass would need to provide. [45]

When work completes, replace the progress region with the saved draft immediately, retain its evidence receipt, and announce readiness politely. Do not play a completion sequence first, auto-open an external Share Page, or publish without review. Manus's asynchronous promise and Notion's saveable report handoff illustrate different ways to separate execution from consuming the result. [43][18]

**Decision:** Let users stop monitoring safely; do not make them perform another task to justify the wait.

## 9. Technical Implementation: One Job, One State Owner, One Rendered Task

### Choose transport after defining the job contract

Use the current transport if it already provides reliable status. Otherwise, start with a durable asynchronous job and **2,000 ms polling**, respecting server `Retry-After`; reduce polling to **10,000 ms** in a hidden tab and reconcile immediately on return. These are implementation defaults to tune against service load.

| Transport | Fit | Recommendation |
|---|---|---|
| Polling | Small team, existing HTTP endpoints, sparse milestones | MVP default when no event infrastructure exists. |
| Server-sent events | One-way job updates with reconnect support | Prefer if already supported; retain a snapshot endpoint. SSE is server-to-client, not bidirectional. [8] |
| WebSockets | A genuine requirement for ongoing bidirectional communication | Do not introduce solely for this loading card. |

Azure's asynchronous request-reply pattern provides a useful contract: accept the request with **HTTP 202**, provide a status location, and expose documented operation states. Its guidance also covers cancellation and idempotency. [10]

### Case study: Retries are a backend problem as well as a button problem

Stripe documents idempotency keys as a way to retry without accidentally performing the same operation twice. Disabling a button alone cannot protect against a lost response, browser refresh, or a second tab. [36]

Apply that pattern to a build intent. Reuse its key after an uncertain submission outcome and retrieve the associated job. A deliberate new format or explicit new attempt gets a new intent identity according to the server contract, rather than a fresh random key for every network retry.

### React structure and event reconciliation

```text
SharePageBuild(taskId)
  TaskHeader
  FormatDecision or FormatReceipt
  BuildProgress
    CurrentBenefit
    OutcomeGroups
    WorkDetails
  BuildOutcome
    DraftPreview or EmptyState or ErrorState
  PersistentPrimaryAction
  BuildControls
  PoliteStatusRegion
```

Use a reducer or explicit state machine, with server job state as the authority. React recommends avoiding contradictory, redundant, and duplicated state; do not maintain independent `isLoading`, `isDone`, and `hasError` flags that can disagree. [34]

A proposed event envelope contains `jobId`, `attemptId`, `revision`, `sequence`, `eventId`, `type`, `phaseCode`, and structured outcome data. Deduplicate by event identity; ignore stale revisions; reconcile sequence gaps with a snapshot; accept terminal states only from the authoritative job revision. Cancellation and completion races resolve from that state, not arrival order alone.

SSE reconnects automatically and supports event IDs, but the application must implement replay or snapshot recovery. Non-HTTP/2 connection limits also matter across tabs. [8]

Coalesce visual updates to **1,000 ms** rather than forcing every step to remain visible. Skip fleeting intermediate steps into the completed receipt. **Never delay a ready result** to finish a progress animation.

### Localisation without concatenation

Map allowlisted event codes to complete catalogue messages. Keep interpolation and plural selection inside the translated message; W3C documents why concatenated fragments prevent natural reordering. [41]

```json
{
  "en": {
    "build.findClips": "I'm finding the clips that answer your question.",
    "build.clipReceipt": "I've added {count, plural, one {# clip} other {# clips}} to your draft."
  },
  "de": {
    "build.findClips": "Ich suche Clips, die Ihre Frage beantworten.",
    "build.clipReceipt": "Ich habe {count, plural, one {# Clip} other {# Clips}} in Ihren Entwurf aufgenommen."
  }
}
```

The German examples are draft translations; validate formality and product terminology. Keep buttons, statuses, errors, and receipts as independent complete messages, not sentence fragments assembled from server text.

**Decision:** A clean renderer depends on a coherent job model; CSS cannot repair conflicting message ownership.

## 10. Measurement: Test Understanding, Safe Return, and Perceived Speed

### Use HEART to separate experience from system performance

Google's **HEART** framework covers Happiness, Engagement, Adoption, Retention, and Task Success. Its Goals-Signals-Metrics approach starts with the desired experience rather than whichever events happen to be available. [33]

For Compass, the goal is: users understand that a page is being built, understand why the work matters, know their options, and can review a useful result. Watching longer or expanding more logs is not automatically better.

| Metric | Proposed definition | Interpretation |
|---|---|---|
| Actual build latency | Server accepted to saved outcome; report p50 and p95 | Keep separate from UX perception. |
| First meaningful content | Accepted job to first usable, persisted draft section | A spinner or status sentence does not qualify. |
| Refresh rate | Jobs with a refresh during active generation / started jobs | Possible uncertainty; inspect alongside connectivity. |
| Repeat submission rate | Equivalent requests within a proposed **5-minute** window / started jobs | Separate intentional rebuilds from accidental duplicates. |
| Unused outcome | Completed jobs not opened within **24 hours** / completed jobs | More informative than treating every navigation as abandonment. |
| Safe return | Jobs left during work and reopened within **24 hours** / jobs left | Measures successful background use. |
| Comprehension | Unprompted explanation of work and next action | Primary check on value communication. |
| Perceived duration and ease | Estimated seconds plus a consistent **7-point** ease item | Attitudinal outcome, not a substitute for actual time. |
| Guardrails | Result quality, failure rate, accessibility defects, retries, compute cost | Prevent an attractive loader from hiding a worse service. |

All windows and scales above are proposed measurement conventions. Track explicit cancellations separately from leaving the page.

### Case study: An engagement framework can mislead if the goal is wrong

The HEART paper distinguishes engagement from simple totals and illustrates moving beyond coarse activity measures in Gmail. That distinction matters here: a loader that requires constant attention could increase on-screen engagement while reducing usefulness. [33]

Therefore, interpret lower loader dwell time positively when users safely leave and return to a useful draft. The relevant mechanism is reduced supervision, not reduced interest in the product.

### Proposed usability study

Recruit **12 researchers**, initially six working in English and six in German, spanning new and experienced Compass users. This is a formative sample, not a representative estimate of preferences. Include keyboard, screen-reader, reduced-motion, and narrow-layout sessions, with targeted additional recruitment where needed.

Counterbalance matched **30-, 60-, and 120-second** builds with the same eventual output quality. Do the first waiting task without concurrent think-aloud, which would itself occupy attention; follow with retrospective probing. Ask perceived duration before revealing actual time. Test at least one long step, a partial result, and a safe departure and return.

Useful questions include: "What was Compass doing?", "Which part helped you trust the page?", "What did each completed item give you?", "Could you leave?", "What would you review before sharing?", and "What did you expect to happen next?"

For an A/B test, randomise consistently by user, or workspace if collaboration creates contamination. Keep backend timing and output quality equivalent, stratify by latency, and preselect comprehension or post-task ease as the primary outcome. Use baseline data for power and report confidence intervals; do not invent a universal sample size.

**Decision:** Listen for "too much is changing" as a busyness signal, and "is it doing anything?" as an opacity signal. Optimise neither silence nor activity in isolation.

## 11. Competitive Landscape: Evidence Handoffs Matter More Than Loader Fashion

### Research and insight platforms

The table distinguishes documented analysis capabilities from exact loading presentation. "Not documented" does not mean the product lacks a progress UI.

| Platform | Documented relevant workflow | Progress-UX implication or limit |
|---|---|---|
| Qualtrics | Research Hub generates summaries from uploaded documents and supports previewing research assets. [32] | Useful artifact context; exact analysis-progress treatment is not established. |
| Dovetail | AI contribution is marked; human edits add a human contributor; outputs remain source-traceable. [24] | Preserve authorship and provenance after completion; exact loader is not established. |
| UserTesting | Generate an insight summary from completed task results; duration varies with completed sessions; review and source access follow. [28] | Strong example of variable input size and evidence-linked review, not a documented timing formula. |
| Maze | Describes editable, traceable AI insights and editable generated reports. [62] | Editability is documented; exact loading presentation is not. |
| Lyssna | Synthesize produces structured, editable summaries of open responses. [30] | Reviewable summaries matter; progress rendering is not established. |
| Remesh | Live and asynchronous research, with AI-assisted discussion guides and findings reports. [40] | Distinct live and asynchronous contexts; no verified report-loading pattern here. |
| Discuss | Genie summarises research, finds themes and quotes, and supports highlight reels. [48] | Close to Compass's evidence mix; exact generation-progress presentation is not established. |
| aha insights technology | AI analysis includes filters, tagging, vocabulary analysis, and composites. [50] | Relevant research platform, not Aha! Discovery; exact loader is not established. |
| Condens | AI finds quotes and highlights; summaries link to transcript moments. [26] | Source-linked outcomes are directly relevant; exact loader is not established. |

The actionable competitive pattern is **reviewable, traceable output**, not evidence that one loading animation has won the category.

### Document and presentation generators

| Product | Documented creation and handoff | Lesson for Share Pages |
|---|---|---|
| Gamma | Official tutorial describes AI creation and editable generated slides. [31] | Show the artifact rather than prolonging a chat narrative; exact current assembly animation is unverified. |
| Beautiful.ai | Review a slide-by-slide outline before generation; change layouts while preserving copy and numbers. [22] | Separate content decisions from visual assembly. |
| Canva | Review and reorder an outline, generate the design, then edit and share. [27] | Keep format decisions before generation. |
| Notion | Shows sources during research and allows saving the result as a page. [18] | Carry research context into the final artifact. |
| Google Docs with Gemini | Prompt document creation and inspect sources; the documented feature is desktop. [23] | Keep source inspection close to editing; exact wait treatment is not established. |
| Tome Slides | Official archived notice states sunset on **April 30, 2025**. [38] | Historical inspiration only, not a current competitor benchmark. |

### Case study: UserTesting and Dovetail expose different parts of the trust problem

UserTesting explicitly warns that summary generation varies with the number of completed sessions, then offers review and source access. That connects duration uncertainty with a concrete input factor and a useful output. [28]

Dovetail makes AI and subsequent human contribution visible. This addresses a different question: not "is it working?" but "who produced this, and what has been reviewed?" Compass should combine the two ideas: calibrated expectations during generation and clear evidence and review status afterwards. [24]

### Praise, criticism, and a defensible opportunity

The reviewed evidence does **not establish a reliable cross-product ranking of widely praised progress UX**. One Manus review praises staying on track autonomously, but that is not proof that its loading interface is broadly preferred. Maze's selected testimonials praise analysis quality, not specifically its loader. [43][62]

Specific criticism is more concrete: a Figma Make user reports processing stopping with no error and asks for better messaging or recovery; the OpenAI report describes an apparently stuck bar and repeated retries. These are useful failure cases, not prevalence estimates. [47][42]

Voxpopme's opportunity is a **video-evidence work receipt**: actual selected clips with timestamps, exact quotes linked to source moments, and explicit unsupported sections. Source links alone are not novel, as Condens and Dovetail demonstrate. The opportunity is integrating them into one calm build-to-review experience, with access controls intact. Do not claim exclusive industry novelty or show coverage scores unless they are genuinely measured. [26][24]

**Decision:** Compete on inspectable research value and reliable recovery, not on copying the most animated agent interface.

## 12. Edge Cases: Design for Real Timing, Not a Perfect Demo

### Proposed timing policy

| Trigger | Recommended response |
|---|---|
| Submission | Acknowledge immediately; target feedback within **100 ms**. Prevent duplicate activation while retaining keyboard focus. |
| **500 ms** elapsed | Reveal the compact task card if still running. Tips become eligible under the existing rule, but remain optional. |
| Completion under **2,000 ms** | Show the result directly. Do not replay skipped steps. |
| **10,000 ms** elapsed | Reveal outcome structure if useful; optionally test one relevant tip. Do not begin rotating copy. |
| **30,000 ms** elapsed | Emphasise a supported leave-and-return option. This is not a failure threshold. |
| No meaningful phase progress for **30,000 ms** | Reconcile with the server. A long step may still be healthy; do not invent new milestones. |
| No confirmed transport health for **15,000 ms** | Reconnect or fetch a snapshot. Say "I'm checking the latest progress. You don't need to refresh." Do not declare generation failed. |
| **60,000 ms** elapsed | Offer a calm checkpoint based on verified state. The brief says waits can normally last two minutes, so one minute is not inherently unusual. |
| **120,000 ms** elapsed | Hand over to the established long-wait pattern. Use "This is taking longer than usual" only if telemetry supports that comparison; otherwise say "I'm still building your page. You don't need to refresh." |
| Server deadline or terminal failure | Show the relevant recovery state immediately. A client timer alone must not create a failure. |

These are initial policy values, not research findings. Nielsen's attention heuristic supports offering another path during long waits, but does not establish a universal 30-second background threshold. [14]

### Case study: Silent interruption is worse than a visibly incomplete result

The Figma Make report describes a job that stops updating without an error, leaving the user unsure whether it has completed. The user found workarounds but explicitly wanted better messaging and recovery. [47]

Compass should never make the researcher infer health from animation. A server snapshot should distinguish running, waiting for input, partial completion, empty output, failure, and cancellation. Azure's asynchronous pattern uses explicit operation states and a persistent status resource, providing a stronger basis than a client-only spinner. [10]

### Failure and recovery matrix

| Situation | User-facing response | Implementation guardrail |
|---|---|---|
| Complete failure | Explain that no page was built; offer retry and retained request details. | Preserve the intent and diagnostic reference without exposing internals. |
| Partial result | Show the saved draft with named missing parts and targeted retry. | Never replace successful sections with a generic error. |
| Empty result | Explain the actual reason and a relevant next action, such as widening the question. | Do not present an empty page as successful completion. |
| Very fast milestones | Skip to the latest meaningful state. | Keep the receipt, not a delayed playback queue. |
| Cancel races with completion | Show the server-confirmed outcome and explain if the draft completed first. | Resolve by job revision, not whichever event arrived last. |
| Navigation, refresh, second tab | Resume the same task and outcome. | Authorise server access; never trust a cached job ID alone. |
| Offline or expired session | Distinguish inability to fetch status from failure of the build. | Recover the snapshot after connectivity or sign-in returns. |
| Permission change | Explain that content is no longer available where appropriate. | Recheck evidence and sharing permissions server-side. |
| Long German labels or zoom | Wrap naturally without overlap or hidden controls. | Test translated strings, narrow layouts, and reflow. [41][54] |
| Event flood or missing events | Show the latest verified outcome calmly. | Deduplicate, reconcile gaps, and keep terminal states stable. |

Internal tool names can reveal sensitive source locations, confuse users about model limitations, or make temporary implementation details look like a product promise. Translate allowlisted events into safe product language; keep diagnostics available to authorised support rather than in the visible step label.

Guard against launch regressions by replaying real timing traces: instant completion, one slow phase, repeated events, missing events, reconnect, background-tab throttling, and partial results. Test through production-like proxies if streaming is used. Budget and retry limits must also prevent an apparently harmless refresh from launching another expensive video-processing run.

**Decision:** The acceptance test is not whether the happy path looks clean. It is whether the task remains truthful and recoverable when timing and delivery become messy.

## Synthesis: The Best Loader Reduces the Need to Watch

The core tension is between **visibility** and **supervision**. Operational transparency can raise value perceptions, but AI image-generation interviews found many participants scarcely noticed the cues. More visible work is not automatically more useful work. [7][49]

| Strategy | Mechanism | Scope and time horizon | Trade-off | Evidence and recommendation |
|---|---|---|---|---|
| Chat transcript | Preserves conversational turns | Useful while defining or discussing a task | Progress becomes a growing reading burden | Retain the conversation, but do not append every generation event. |
| Persistent task card | Separates decision, execution, and outcome | Best first release for this bounded build | Requires a coherent job identity and state model | Fits the supplied problem and React's advice to avoid duplicated state. [34] |
| Detailed agent panel | Makes execution inspectable | Useful for complex tasks or expert investigation | Can expose irrelevant or sensitive detail | Borrow Devin's optional separation, not its developer-log density. [29] |
| Streaming draft | Gives useful output before final completion | Later enhancement where sections are stable | Early content may be mistaken for reviewed final evidence | Show only persisted sections with clear draft status. |
| Background task | Replaces waiting with safe return | Most valuable for longer jobs and multitasking | Needs durability, discoverability, and notification semantics | Gemini and Manus document this model; implement the capability before promising it. [45][43] |

Three divergences matter. First, **showing effort is not the same as explaining quality**. A long checklist can prove that many actions ran without proving that the selected quotes support the summary. Preserve inspectable evidence instead.

Second, **cleaner is not necessarily quieter in the right way**. Removing every status line can recreate the stuck-bar ambiguity reported by users. The target is one meaningful current statement plus optional depth, not silence. [42]

Third, **the best small-team design may be less technically elaborate**. A durable job polled reliably can support a more credible experience than a polished event stream without replay, cancellation semantics, or state reconciliation. The asynchronous request-reply and SSE sources describe different transport mechanisms; neither eliminates the need for an authoritative status contract. [10][8]

For Voxpopme, the defensible product direction is therefore **artifact-centred progress**: preserve the format choice, show honest evidence work, deliver a saved draft, and retain a receipt that helps researchers review it. Do not delay an outcome to demonstrate effort. Do not require users to supervise the process to believe it is running.

**Decision:** Ship the coherent task model first. Add richer preview, estimates, and background notification only when they improve demonstrated customer understanding or freedom.

## A. Recommended State Model for the Component

Use one lifecycle state, with separate connectivity and presentation flags. This follows React's recommendation to replace contradictory flags with a coherent status model. [34]

```text
choosing_format
  -> submitting
  -> running
  -> ready | ready_with_gaps | empty | failed

running
  -> cancel_requested
  -> cancelled | ready | ready_with_gaps | failed

running
  -> needs_input
  -> running
```

`needs_input` is conditional: include it only if the backend genuinely requires a decision. Do not invent a follow-up to keep the user occupied.

| State | Visible content | Allowed transition or action |
|---|---|---|
| `choosing_format` | Format question and clear start action | Select format; submit once. |
| `submitting` | Immediate acknowledgement | Receive job ID, or reconcile an uncertain response using the same intent key. |
| `running` | Format receipt, one truthful status, confirmed milestones | Receive progress, request cancellation, or leave if durable. |
| `needs_input` | One specific question and its consequence | Resume on answer; keep completed work. |
| `cancel_requested` | "I'm stopping the build." | Await server acknowledgement; completion may win the race. |
| `ready` | Saved draft and evidence receipt | Review, edit, then share explicitly. |
| `ready_with_gaps` | Saved draft, named omissions, targeted recovery | Review useful sections or retry missing work. |
| `empty` | Reason no usable content was produced | Revise scope or source selection. |
| `failed` | Plain explanation and retained request | Retry deliberately or seek help. |
| `cancelled` | Confirmed stop and any retained draft | Restart explicitly or return to research. |

Keep `connection = connected | reconnecting | offline`, `longWait`, `detailsExpanded`, and `updatesPaused` orthogonal. None should silently convert a running job to a failed one. Terminal outcomes are monotonic within an attempt; an explicit retry creates a new attempt.

For the first backend integration, completion-only step events are enough to show true receipts. Add specific active-phase copy only when phase-start events or the server snapshot support it. The generic fallback is "I'm building a Share Page from your research."

## B. One-Page Design Principles

The principles combine the supplied acceptance criteria with status-message, human-AI interaction, and component guidance. [9][1][3]

| Principle | Implementation rule | Acceptance check |
|---|---|---|
| One coherent process | One task ID, one state owner, one card | Format choice, progress, and draft cannot appear as competing assistant messages. |
| One Compass identity | Show the name or avatar once per task group | No confusing duplicate speaker labels. |
| Outcomes before mechanisms | Use a first-person benefit sentence | A researcher can explain why the current work matters. |
| Truth before precision | No invented steps, coverage, percentages, or ETA | Every visible claim maps to a supported job fact. |
| Quiet by default | One current line; optional details | No automatic growing transcript, rotating tips, or competing animations. |
| Fast stays fast | Reveal extra UI after 500 ms; skip fleeting states | Completion is never delayed to display progress. |
| Evidence survives completion | Keep a compact receipt with source access | The value of the work remains inspectable after the loader disappears. |
| Control has a real meaning | Distinguish stop, pause updates, and restart | Each control's wording matches its server or presentation behaviour. |
| Leaving is a capability | Persist jobs and provide a stable return path | Refresh and another tab recover the same job. |
| Accessibility is structural | Stable polite live region, logical focus, reduced motion | The flow works without watching animation or hearing every event. |
| Translation is whole-message | Catalogue complete messages and plural forms | German does not overflow, concatenate awkwardly, or expose English server text. |
| Drafts remain reviewable | Name omissions and support correction | Researchers can inspect evidence before external sharing. |

The main case is Compass itself: the existing issue is described as two distinct messages, not merely an over-styled spinner. A single reusable component removes that structural duplication while retaining the format decision and the result. The proposed acceptance checks should be applied to real event traces, not only a static design.

**Release principle:** Prefer the smallest design that can tell the truth about the job and deliver a reviewable draft.

## C. Prioritised Prototypes and Tests

| Priority | Prototype or implementation | What to test before expanding scope |
|---|---|---|
| **P0** | One inline task card replacing the two-message progress stack | Can users identify one task, its chosen format, and the next action at 30-, 60-, and 120-second waits? |
| **P0** | Server job identity, status snapshot, idempotent submission, and recovery states | Refresh, reconnect, and second-tab access do not create duplicate work or lose results. |
| **P0** | Generic active copy plus true completion receipts | Users understand progress without unsupported claims about what is currently running. |
| **P0** | Keyboard, screen-reader, reduced-motion, and German layouts | No lost focus, announcement flood, clipped text, or inaccessible controls. |
| **P1** | Benefit-led status versus a neutral "Building your Share Page" baseline | Does specific wording improve comprehension or confidence without exaggerating quality? |
| **P1** | Compact evidence receipt versus status-only completion | Do users inspect clips and understand what Compass contributed? |
| **P1** | Long-wait and partial-result variants | Do users distinguish a slow job, a connection problem, and a usable incomplete draft? |
| **P2** | Real partial preview and optional title editing | Does the activity help, or create rework and false finality? |
| **P2** | Calibrated estimates and background notifications | Are predictions credible, and do notifications improve safe return? |
| **P2** | One relevant, dismissible tip | Is it useful enough to justify attention during the wait? |

Start by testing the structural fix against the current design, not several simultaneous changes. Then isolate copy and evidence receipts. HEART's Goals-Signals-Metrics approach supports this sequence: establish the desired understanding, identify its signals, and only then choose the metric. [33]

Do not prioritise a library migration, elaborate animation, an exhaustive agent timeline, or a global notification centre for the first release. None is necessary to remove repeated Compass labels and competing progress messages.

## D. Open Questions for Voxpopme Customers

1. **What do researchers think they have commissioned?** A finished page, a draft, a showreel, or a selection of evidence? The label and completion handoff must match that expectation.
2. **Which work is valuable enough to mention?** Selecting clips, checking source links, arranging findings, or identifying gaps may matter differently to insight and product teams.
3. **Do three outcome groups clarify or overcomplicate the wait?** Test them against a single sentence and completed receipt, not only against the current cluttered stack.
4. **When do people want to leave?** Observe real working context rather than asking only whether a background option sounds useful.
5. **What makes the result feel credible?** Clip thumbnails, timestamps, exact quotes, source counts, and gap notices may have different value and privacy implications.
6. **What does "Stop" mean to customers?** Stop computation, keep a draft, discard the page, or return to editing the request? Test the cancellation explanation explicitly.
7. **How often is changing format mid-build genuinely necessary?** This determines whether restart complexity is worth supporting.
8. **What do German-speaking users expect from terminology and address?** Validate "Share Page", "draft", "Compass", and the proposed formal address with the actual customer base.
9. **Which accessibility preferences are not captured by reduced motion alone?** Test static progress, announcement cadence, keyboard flow, and returning to a completed result.
10. **What does an incomplete page let people do?** Determine which missing sections make a draft unusable and which can be reviewed or repaired later.
11. **Where should a returning researcher find the job?** The same Compass conversation, a recent-task item, the destination page, or more than one of these?
12. **What does trust look like after several builds?** First-use reassurance may become repetitive; test experienced users rather than relying on an initial reaction.

The small AI studies show why these questions remain open: their tasks, populations, and delays differ substantially from enterprise video research. They support informative feedback as a candidate, not a universal winning design. [46][49]

**Final recommendation:** Prototype one calm task card with a retained format receipt, truthful benefit-led status, optional work detail, and a source-linked draft handoff. Prove that customers understand it and can safely stop watching before adding more to watch.

## References

### Waiting, perception, and human-AI interaction

- Buell and Norton, *The Labor Illusion: How Operational Transparency Increases Perceived Value*. [7]
- Harrison, Yeo, and Hudson, *Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations*. [59]
- Nielsen Norman Group, *Response Times: The 3 Important Limits*. [14]
- *The Effect of Skeleton Screens*, ECCE study. [15]
- Maister, *The Psychology of Waiting Lines*. [16]
- *Waiting for GPT: Probing Interaction Patterns in High-Latency RAG Chatbots*, exploratory pilot. [46]
- *While We Wait... How Users Perceive Waiting Times and Generation Cues during AI Image Generation*. [49]
- Microsoft Research, *Guidelines for Human-AI Interaction Design*. [1]
- Microsoft Design, *UX Design for Agents*. [35]

### Accessibility and design systems

- W3C, WCAG 2.2 Understanding: Status Messages; Pause, Stop, Hide; Animation from Interactions. [9][4][5]
- W3C, WCAG 2.2 Understanding: Contrast Minimum; Non-text Contrast; Focus Order; Target Size Minimum; Reflow. [60][55][56][53][54]
- MDN, ARIA `progressbar` role. [2]
- Harvard User Research Center, historical generative-AI chatbot accessibility review. [37]
- Material Design 3, progress indicators. [3]
- Carbon Design System, loading patterns. [12]
- Atlassian Design System, progress bar. [6]
- Fluent 2, progress-bar usage. [57]
- Ant Design, Steps. [58]
- Radix UI, Progress. [61]
- Shopify Polaris, deprecated Loading component. [11]
- MUI X Chat, message appearance and grouping. [52]

### Implementation and evaluation

- React, *Choosing the State Structure*. [34]
- MDN, *Using Server-Sent Events*. [8]
- Microsoft Azure, *Asynchronous Request-Reply Pattern*. [10]
- Stripe, *Idempotent Requests*. [36]
- W3C Internationalization, *Working with Composite Messages*. [41]
- Google, HEART and Goals-Signals-Metrics user-experience measurement paper. [33]

### Agent, research, and document products

- OpenAI, Deep Research help and ChatGPT agent introduction. [21][20]
- Anthropic, *Use Research on Claude*. [44]
- Perplexity, Research Mode help. [19]
- Google, Gemini Deep Research mobile help; document creation in Google Docs. [45][23]
- Notion, Research Mode help. [18]
- Cognition, Devin session tools. [29]
- Manus, developer App Store description and individual review. [43]
- GitHub Next, Copilot Workspace historical project page. [25]
- Figma, Introduction to Figma Make. [39]
- Canva, AI presentation creation. [27]
- Gamma, official creation tutorial. [31]
- Beautiful.ai, DesignerBot creation workflow. [22]
- Tome, archived official Slides sunset notice. [38]
- Qualtrics, Research Hub. [32]
- Dovetail, AI help. [24]
- UserTesting, AI insight summary help. [28]
- Maze, AI analysis and editable reports. [62]
- Lyssna, analysis features. [30]
- Remesh, research platform overview. [40]
- Discuss, Genie generative-AI capabilities. [48]
- aha insights technology, platform overview. [50]
- Condens, AI support for the research process. [26]
- First-hand failure reports: OpenAI Community, apparently stuck Deep Research loading bar; Figma Forum, Make stops mid-prompt execution. [42][47]

## References

1. *Guidelines for human-AI interaction design - Microsoft Research*. https://www.microsoft.com/en-us/research/blog/guidelines-for-human-ai-interaction-design/
2. *ARIA: progressbar role - ARIA | MDN*. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/progressbar_role
3. *Progress indicators – Material Design 3*. https://m3.material.io/components/progress-indicators/guidelines
4. *Understanding Success Criterion 2.2.2: Pause, Stop, Hide | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html
5. *Understanding Success Criterion 2.3.3: Animation from Interactions | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html
6. *Progress bar - Examples - Components - Atlassian Design*. https://atlassian.design/components/progress-bar/
7. *A*. https://www.hbs.edu/ris/Publication%20Files/Norton_Michael_The%20labor%20illusion%20How%20operational_f4269b70-3732-4fc4-8113-72d0c47533e0.pdf
8. *Using server-sent events - Web APIs | MDN*. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
9. *Understanding Success Criterion 4.1.3: Status Messages | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html
10. *Asynchronous Request-Reply Pattern - Azure Architecture Center | Microsoft Learn*. https://learn.microsoft.com/en-us/azure/architecture/patterns/asynchronous-request-reply
11. *Loading — Shopify Polaris React*. https://polaris.shopify.com/components/feedback-indicators/loading
12. *Loading Pattern*. https://carbondesignsystem.com/patterns/loading-pattern
13. *Faster progress bars*. https://dl.acm.org/doi/epdf/10.1145/1753326.1753556
14. *Response Time Limits: Article by Jakob Nielsen - NN/G*. https://www.nngroup.com/articles/response-times-3-important-limits
15. *The effect of skeleton screens | Proceedings of the 36th European Conference on Cognitive Ergonomics*. https://dl.acm.org/doi/10.1145/3232078.3232086
16. *Enter Title Here*. http://www.columbia.edu/~ww2040/4615S13/Psychology_of_Waiting_Lines.pdf
17. *Skeleton Screens 101 - NN/G*. https://www.nngroup.com/articles/skeleton-screens
18. *Research Mode in Notion AI | Notion Help – Notion Help Centre*. https://www.notion.com/en-gb/help/research-mode
19. *What is Research mode?*. https://www.perplexity.ai/help-center/en/articles/10738684-what-is-research-mode
20. *Introducing ChatGPT agent | OpenAI*. https://openai.com/index/introducing-chatgpt-agent
21. *Deep research in ChatGPT | OpenAI Help Center*. https://help.openai.com/en/articles/10500283
22. *AI Presentation Maker | Create Slides & Decks in Minutes*. https://www.beautiful.ai/designerbot
23. *Create personalized documents with Gemini in Google Docs - Google Docs Editors Help*. https://support.google.com/docs/answer/15541879?hl=en
24. *Dovetail AI - Dovetail*. https://docs.dovetail.com/help/dovetail-ai
25. *Copilot Workspace*. http://githubnext.com/projects/copilot-workspace
26. *How Condens AI Supports Every Step of Your Research Process*. https://condens.io/product-updates/condens-ai-supports-research-process
27. *Presentations and slides for any occasion | Canva*. https://www.canva.com/presentations/
28. *AI insight summary – Knowledge Base Home*. https://help.usertesting.com/hc/en-us/articles/13268691111453-AI-insight-summary
29. *Devin Session Tools*. https://docs.devin.ai/work-with-devin/devin-session-tools
30. *Lyssna Analysis Features | Tag, Filter, Export & Share Insights | Lyssna*. https://www.lyssna.com/features/analysis
31. *Welcome to Gamma | Gamma*. https://gamma.app/docs/Welcome-to-Gamma-xola1gmvi12uqhx
32. *Research Management Software - Research Hub*. https://www.qualtrics.com/strategy/research-hub
33. *heart-metrics-author-version*. https://research.google.com/pubs/archive/36299.pdf
34. *Choosing The State Structure*. https://react.dev/learn/choosing-the-state-structure
35. *UX design for agents  - Microsoft Design*. https://microsoft.design/articles/ux-design-for-agents/
36. *Idempotent requests*. https://docs.stripe.com/api/idempotent_requests
37. *Review of Generative AI Chatbots' Accessibility | User Research Center*. https://urc.library.harvard.edu/blog/review-generative-ai-chatbots-accessibility
38. *Tome Slides is Sunsetting on April 30th, 2025 | Tome Help Center*. https://web.archive.org/web/20250418170859/https://tome.app/help/en/articles/10744234-tome-slides-is-sunsetting-on-april-30th-2025
39. *Intro to Figma Make | Developer Docs*. https://developers.figma.com/docs/code/intro-to-figma-make
40. *Remesh | AI-Powered Market Research & Employee Insights Platform*. https://www.remesh.ai/
41. *Working with Composite Messages*. https://www.w3.org/International/articles/composite-messages/
42. *Deep Research loading bar stuck with no progress - ChatGPT - OpenAI Developer Community*. https://community.openai.com/t/deep-research-loading-bar-stuck-with-no-progress/1378216
43. *‎Manus - AI Agent & Automation App - App Store*. https://apps.apple.com/us/app/manus-ai-agent-automation/id6740909540
44. *Use research on Claude*. https://support.claude.com/en/articles/11088861-use-research-on-claude.md
45. *Use Deep Research in Gemini Apps - Android phone & tablet - Gemini Apps Help*. https://support.google.com/gemini/answer/15719111?co=GENIE.Platform%3DAndroid&hl=en
46. *Waiting for GPT: Probing Interaction Patterns in High-Latency RAG Chatbots | Proceedings of the Extended Abstracts of the 2026 CHI Conference on Human Factors in Computing Systems*. https://dl.acm.org/doi/full/10.1145/3772363.3799266
47. *Figma Make stops mid-prompt execution | Figma Forum*. https://forum.figma.com/report-a-problem-6/figma-make-stops-mid-prompt-execution-45184
48. *Genie- Your Qualitative Research Assistant | Discuss*. https://www.discuss.io/platform/generative-ai
49. *While We Wait... How Users Perceive Waiting Times and Generation Cues during AI Image Generation | Proceedings of the Extended Abstracts of the CHI Conference on Human Factors in Computing Systems*. https://dl.acm.org/doi/10.1145/3706599.3719725
50. *Aha Insights Technology for Consumer Market Research | ResTech*. https://ahaonlineresearch.com/about-aha
51. *ui.shadcn.com*. https://ui.shadcn.com/docs/components/progress
52. *Message appearance - MUI X*. https://mui.com/x/react-chat/display/message-appearance
53. *Understanding Success Criterion 2.5.8: Target Size (Minimum) | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
54. *Understanding Success Criterion 1.4.10: Reflow | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/reflow.html
55. *Understanding Success Criterion 1.4.11: Non-text Contrast | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html
56. *Understanding Success Criterion 2.4.3: Focus Order | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html
57. *React Progress Bar - Fluent 2 Design System*. https://fluent2.microsoft.design/components/web/react/core/progressbar/usage
58. *Steps*. https://ant.design/components/steps.md
59. *ProgressBarsVisualCHIv15CAMERA1*. https://www.chrisharrison.net/projects/progressbars2/ProgressBarsHarrison.pdf
60. *Understanding Success Criterion 1.4.3: Contrast (Minimum) | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
61. *Progress*. https://www.radix-ui.com/primitives/docs/components/progress
62. *Maze AI | Research at the pace of change*. https://maze.co/ai/