Post-Task Survey for Completed Product Workflows

You are improving an existing product surface for this audience: UX researchers, product managers, and builders adding task-level feedback to existing product flows.
Do not redesign the whole product. Add or refine only the form, survey, widget, or intake flow described here, and preserve the current brand, layout system, components, typography, color tokens, spacing scale, icon style, and content voice unless a change is required for usability or accessibility.

Goal:
Add a short post-task survey to an existing completion screen, toast, or confirmation page so the team can understand how easy a specific workflow felt while the task is still fresh.

Existing context to inspect first:
- Identify the current primary task, where the user has just come from, and what they still need to do after this form or feedback moment.
- Reuse existing form controls, buttons, field validation patterns, banners, sheets, dialogs, toasts, loading indicators, and analytics/event naming where available.
- Keep the visual treatment subordinate to the task. The enhancement should feel native to the current app or site, not like a pasted-in third-party widget.

Layout and content hierarchy:
- Anchor the survey near the existing completion confirmation, receipt, or success state so it feels connected to the task just completed.
- Start with one clear rating question such as How easy was it to complete this task?, using a balanced 1-7 scale or clearly labeled semantic scale.
- Show a concise progress cue such as 1 of 2 only if an optional follow-up appears after the rating.
- Add an optional free-text follow-up at the end, triggered by score bands or available through Add details, with a visible character counter.

Interaction behavior and states:
- Trigger only after the target task is completed and the confirmation information is visible; never prompt during the task or before users see the result.
- Do not ask users to predict future behavior. Ask about the task they just completed and allow them to skip.
- If the score is low, ask what made the task hard; if the score is high, ask what worked well; if neutral, ask what would make it easier.
- After submit or skip, keep the confirmation visible and move the user to the natural next action.
- Include these states with explicit UI copy and behavior: eligible, not eligible, rating selected, follow-up shown, skipped, submitting, success, error, cooldown active.

Mobile and responsive behavior:
- Use an inline card below the success message or a compact bottom sheet that does not hide the confirmation number, receipt, or next action.
- Make scale targets large enough for touch and wrap labels instead of shrinking text.
- On mobile, collapse explanatory copy to one sentence and keep the optional text field below the rating.

Accessibility requirements:
- Group the rating scale with a fieldset or equivalent accessible grouping and clear legend.
- Provide visible labels for both ends of the scale and ensure selected state is not color-only.
- Announce follow-up field insertion politely and move focus only when doing so helps completion.
- Errors must preserve the selected rating and explain what failed in text.

Implementation constraints:
- Store task ID, task completion timestamp, workflow variant, score, optional comment, and whether the user skipped.
- Use a per-task cooldown so users are not asked repeatedly in the same session.
- Make the survey removable through configuration so teams can test specific workflows without hard-coding it everywhere.
- Keep copy neutral and do not imply that positive ratings are expected.

Quality checklist before finalizing:
- The survey appears after task completion, not on page entry or mid-flow.
- The first question measures the specific task, not overall loyalty or brand sentiment.
- The flow can be skipped and completed quickly.
- Score labels, follow-up logic, states, and analytics events are specified.
- The survey reuses existing confirmation, card, scale, and form patterns.

Output format:
- Return the proposed UI as an implementation-ready brief or code update appropriate to the existing project.
- Include component structure, field labels, validation copy, success/error copy, analytics events, responsive behavior, and handoff notes.
- Do not use placeholder text, fake image boxes, a new design system, a new framework requirement, or broad phrases like "make it modern".