Customer Feedback Widget for Existing Product Pages

You are improving an existing product surface for this audience: Product designers, SaaS founders, and frontend builders improving live product pages.
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 lightweight customer feedback widget that users can open on demand, plus a subtle post-task nudge only after a meaningful completion event such as publishing, checkout, booking, export, or issue resolution.

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:
- Use a compact collapsed trigger such as Feedback, Report issue, or Share feedback, positioned in an existing help, footer, side rail, or bottom-corner pattern where it does not cover primary controls.
- Expanded state should show a short heading, one sentence explaining how feedback will be used, category chips for Bug, Confusing, Idea, Praise, and Other, an optional rating or sentiment control, and a concise details field with a character counter.
- Include optional email, screenshot/context consent, and privacy microcopy only when useful; do not require contact details for general feedback.
- Place the primary submit button after the details field, with secondary dismiss and later options visually quieter than submit.

Interaction behavior and states:
- Keep the widget available on demand at all times, but only show proactive prompts after a completed task, never on first page load or in the middle of checkout, payment, destructive, or support-critical flows.
- Use cooldown rules: do not show a proactive prompt again after dismissal or submission for at least 30 days, while keeping the manual trigger available.
- When a category is selected, update helper text and optional follow-up fields so the user sees why the detail matters.
- After submission, show a brief thank-you state and keep the user on the original page with their prior context intact.
- Include these states with explicit UI copy and behavior: collapsed, expanded, category selected, attachment uploading, submitting, success, validation error, network error, dismissed, reopened.

Mobile and responsive behavior:
- On small screens, open as a bottom sheet or inline panel that keeps the trigger reachable and avoids covering fixed navigation or the current primary CTA.
- Keep the first mobile view to one rating/category question plus the optional details affordance; move advanced fields below the fold.
- Ensure the text area resizes with the keyboard visible and that submit/dismiss controls remain reachable without horizontal scrolling.

Accessibility requirements:
- The trigger must be keyboard reachable, have a visible focus state, and announce expanded/collapsed state with appropriate semantics.
- Every control needs a persistent label; do not rely on placeholders as labels.
- If implemented as a dialog or sheet, manage focus on open and close, support Escape, and restore focus to the trigger.
- Validation and network errors must be text-based, programmatically associated with the affected fields, and not communicated by color alone.

Implementation constraints:
- Use existing modal, popover, sheet, toast, field, and button components; do not introduce a new widget library or visual language.
- Capture page URL, product area, timestamp, user role or account tier when available, and selected category as hidden metadata, but expose privacy-sensitive captures for consent before sending.
- Emit analytics events for trigger viewed, opened, category selected, submitted, dismissed, and failed submission.
- Route submitted feedback to the existing support, product, or research destination with a clear source tag.

Quality checklist before finalizing:
- The prompt asks after a real task or stays on demand; it does not interrupt first page load.
- The flow can be completed in about 1 minute and starts with structured choices before optional free text.
- The widget preserves existing brand tokens and components.
- The design includes dismissal, cooldown, failure, and success behavior.
- Mobile behavior is specified as a bottom sheet or native compact pattern, not a cramped desktop popover.

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".