# Design QA without the screenshot-ticket loop ## Short narrative Design QA should not die in screenshots, tickets, and another backlog cycle. Mode's wedge is not `Design QA` as a feature label; it is escaping the broken loop between noticing a visual issue and getting a reviewable product change. ## Why this wedge matters Question it answers: > What painful workflow does Mode help teams escape? Narrative: > Design QA often turns into screenshots, comments, tickets, and another backlog cycle. Mode is more compelling when it is framed as the action layer after someone notices the issue: fix or propose the change in product context, then send it to review. This protects us from the bad interpretation: > "Is Mode just a design QA detector or visual bug tracker?" The stronger story is: > Mode turns design QA pain into product-native action: start from the shipped UI issue, make a scoped change with context intact, and move it toward engineering review. ## How it supports the launch spine This should support `Fix one real product UI issue` as a concrete pain/proof wedge. It gives the launch story an emotionally obvious reason to act, but it should not become only a screenshot-ticket critique. ## Strategic bet Design QA, shipped UI drift, and visual polish debt are painful and recognizable. If Mode can convert that pain into action, this wedge can create urgency without relying on abstract category language. ## Why Mode is suited Mode can sit after issue detection: start from the real product surface, make a scoped change in context, and move it toward something engineering can inspect. ## Product entry / CTA path Ask users to bring a design QA item or UI polish issue that would otherwise become a screenshot-ticket. ## Proof needed Show one design QA issue corrected against the existing product. The proof should include before/after, existing component/context cues, and the review path. ## Launch-spine relevance This wedge gives the launch spine pain and specificity. It pairs naturally with `Fix one real product UI issue`, but may need Alex review on whether those stay separate for launch or merge into one active CTA. ## Risks / confusions - Do not frame Mode as merely detecting design QA issues. - Avoid hard quantified time-savings until a named proof asset supports them. - Avoid making engineers the enemy; the enemy is the screenshot-ticket-backlog loop.