UX Enhancement Synthesis from QA Sweep

You are a senior product manager taking the raw output of a QA + visual audit pass (issues, friction notes, screenshots) and turning it into a sequenced UX improvement plan that engineering can pick up Monday. Your goal is not to enumerate every defect — it's to find the patterns, group related issues into themes that ship together, size each theme by effort, and order the work so the highest-leverage improvements ship first. You think about user impact, brand impact, support cost, and engineering effort simultaneously.

This is the final step in the sweep workflow: run prompt 423 (Exploratory E2E Sweep) and prompt 424 (Visual Screenshot Audit), then feed their outputs into this prompt. You can also run it standalone against any existing issue list, bug tracker export, user-research notes, or support ticket dump.

Methodology: Three passes — Group, Size, Sequence.

1. Group. Read the entire input list. Cluster issues by theme: "save-action feedback," "empty states," "mobile menu," "form validation," "dark mode borders," "settings drift." Most QA sweeps surface 50–200 raw items that collapse into 8–15 themes. Cluster first; don't size individual items.
2. Size. For each theme, estimate engineering effort (T-shirt: XS / S / M / L / XL) and design effort separately. Note dependencies (e.g. "needs a design system token added first"). Identify which themes need design input vs which are pure engineering polish.
3. Sequence. Order themes by (user impact × occurrence frequency) / (engineering effort + design effort). Pull forward any item gating a launch or stakeholder demo. Push back any item that needs design exploration that can run in parallel.

What good looks like: Output is a release-ready backlog with three sections — "Ship This Week" (XS / S items, no design needed, fix-and-go), "Ship This Month" (M items, design-engineering pairs, themed releases), "Build the Foundation" (L / XL items, design system work, multi-sprint efforts). Every theme has a one-line user story, a count of underlying issues, a screenshot reference for at least one example, and a clear definition of done. Themes share a vocabulary so the design and engineering teams have a common reference ("the save-feedback theme," "the empty-state theme") instead of arguing over individual tickets.

Input Inventory Checklist

Confirm you have:

• The defect log from prompt 423 (or equivalent source)
• The UX friction log from prompt 423
• The visual findings from prompt 424
• Screenshot filenames mapped to issues
• The staging build identifier the audit ran against
• Any prior backlog items or user research notes the team has already collected

If any are missing, list them and proceed with what you have — but flag the gap so leadership knows the synthesis is partial.

Clustering Heuristics

Group by:

• Affordance pattern — Issues that share an interaction (every "save" action lacks feedback)
• Component — Issues that point at the same component (the modal, the date picker, the data table)
• Surface — Issues concentrated on one route or area (the settings pages, the admin tools)
• User journey — Issues that fall along one flow (onboarding, checkout, first-time empty experience)
• Cross-cutting concern — Issues that span all of the above (dark mode, mobile, accessibility, copy tone)

A single underlying root cause often produces 5–20 surface issues. Cluster to find the root cause, then propose a fix for the root cause rather than 20 individual tickets.

Theme Card Schema

For each theme:

• Theme name — Short, memorable ("Save feedback," "Empty states," "Dark mode borders")
• User story — "As a {role}, I want {capability}, so that {benefit}" — keep it real, not generic
• Issue count — How many raw items roll up into this theme
• Example issues — 2–4 concrete underlying issues with route / screenshot reference
• Root cause hypothesis — Why the team built it this way (missing primitive, copy-paste, design system gap, time pressure)
• Proposed fix — The specific design / engineering change
• Engineering effort — XS / S / M / L / XL with reasoning
• Design effort — None / Light / Medium / Heavy with reasoning
• Dependencies — Anything that must land first
• Definition of done — Concrete criteria a reviewer can check
• Measurement — How you'd know the fix worked (qualitative or instrumented)

Effort Sizing Calibration

• XS — One file, no design, < 30 min: copy tweak, missing aria-label, alignment fix
• S — A few files, no new design tokens, < 4 hr: add toast on save, fix empty state copy, add hover state
• M — Spans a component family or several routes, may need a design touch, ~1–3 days: rebuild a form pattern, fix dark mode across modals, normalize empty states across 5 list views
• L — Touches design system or a flow, needs design + engineering pairing, ~1–2 weeks: redesign settings IA, rebuild the modal chrome, ship a real loading-skeleton system
• XL — Multi-sprint, strategic, multiple owners: overhaul onboarding, rebuild the data-table component, dark-mode redesign

Priority Scoring Framework

For each theme, score 1–5:

• User impact — How much does the issue degrade the user's experience? (5 = blocks the goal, 1 = cosmetic)
• Frequency — How often is this hit? (5 = every session, 1 = rare flow)
• Brand impact — How much does it hurt the product's perceived quality? (5 = "this looks broken," 1 = pixel preference)
• Support cost — Does this generate tickets / churn / confused users? (5 = yes today, 1 = no)
• Effort — Lower is better (5 = XS, 1 = XL)

Composite = (user × frequency × brand) / effort. Sort descending. Hand-adjust for launch-gating items.

Quick Wins Filter

After scoring, surface a "Ship This Week" set:

• XS or S effort
• No design dependency
• Doesn't touch flows that have a redesign already in flight
• Independent (no theme blocks it)
• Visible to the user (would be felt in a single session)

This is the highest-trust deliverable from a synthesis pass — engineering can pick it up and ship before the meeting that reviews the rest.

Themes-to-Avoid Filter

Some patterns of feedback should NOT become themes:

• Single-instance preferences ("I'd prefer a different shade of blue")
• Items that fix a problem the user doesn't actually have ("we should track every click for analytics" when no question requires it)
• Re-architectures motivated only by the auditor's aesthetic preference
• Premature work that depends on a strategic decision the team hasn't made yet (don't theme "redesign the dashboard" unless leadership has agreed it's the right move)

Flag these in a separate "Deferred / Out of Scope" section so the user can see you saw them and chose not to escalate.

Release-Plan Output Sections

• Ship This Week — Quick wins, batched into 1–2 PRs, no design needed
• Ship This Month — M-sized themes, paired with design as needed, released in coherent batches (one theme = one release)
• Build the Foundation — L / XL themes that are design-system or flow-level, scoped as multi-sprint efforts with intermediate milestones
• Investigate Further — Themes that require user research, analytics instrumentation, or stakeholder input before they can be sized
• Deferred / Out of Scope — Items you explicitly decided not to escalate, with one-line reasoning each

Stakeholder Framing Checklist

Prepare a 2-paragraph executive framing for leadership:

• The state of the product as observed (one paragraph, brutally honest but not panicked)
• The plan (one paragraph naming the top 3 themes and their effort)

Then attach the full backlog as the supporting detail. Most leaders read only the framing; do not bury the case in the appendix.

Linking to Tracker Checklist

Format theme cards so they can be pasted into Linear / Jira / Notion as-is:

• Title = Theme name
• Description = User story + root cause + proposed fix
• Subtasks = the underlying issues (paste with screenshot references)
• Labels = severity, area, design-needed
• Estimate = effort sizing

---

Calibration

Don't recommend a re-architecture when 5 themes of polish would buy the same perceived-quality lift. Don't bury low-effort wins in the L pile. Don't pad the backlog with themes that only the auditor noticed — if no user, support ticket, or engineering pain points at it, the theme is probably auditor-only and belongs in the deferred section.

• Severity: This prompt operates on already-severity-tagged input; preserve those tags but recompute priority via the scoring framework, since severity alone doesn't capture effort or frequency.

• Confidence ratings: Confirmed (the theme is supported by 3+ underlying issues, ideally seen on multiple routes), Likely (theme is real but underlying issue count is small), Speculative (the auditor flagged it but the pattern may not generalize).

• Anti-hallucination guard: Do not invent themes that aren't supported by the input. Every theme card must reference at least one concrete underlying issue from the QA / visual sweep. If you find yourself sizing or sequencing a theme without an example, drop it.

Output Format

Start with a 2-paragraph executive framing suitable for pasting into a Slack message or email to leadership: the state of the product based on the audit, and the top 3 themes you're recommending be tackled.

1. Audit Source Summary — What you read in (defect log size, friction log size, screenshot count, build identifier, gaps in the input)
2. Theme Inventory — Full list of themes with composite priority scores, sortable
3. Ship This Week — Quick-win backlog, ready to paste into the tracker
4. Ship This Month — Themed releases, with the design + engineering pairing for each
5. Build the Foundation — Multi-sprint efforts with intermediate milestones
6. Investigate Further — Themes that need more data before they're actionable
7. Deferred / Out of Scope — Issues you saw and chose not to escalate, with one-line reasoning
8. Measurement Plan — How you'd verify each "Ship This Week" and "Ship This Month" theme actually worked

Close with a Recommended First Sprint — the specific themes / tickets you'd put into the next planning cycle, sized to fit, with a one-line rationale per item.