The anatomy of a UX ticket an engineer accepts without a meeting

UX findings ship when they arrive shaped like work: a title naming the broken behavior, an agreed severity, reproduction steps, a cited rule, a suggested fix, and an effort estimate. Everything else dies where UX feedback usually dies: page 14 of a doc nobody opens after the readout meeting.

This is the exact anatomy of a UX ticket an engineer accepts without calling a meeting, with the research on why each field earns its place and two copy-paste templates at the end.

The same finding, filed twice

A worked example, fictional but painfully familiar. Your signup form rejects passwords against rules it never shows, throws a generic error, and wipes both password fields. Someone on the team noticed. Here is how that finding usually lands in Jira:

Now the same finding, shaped like work:

Same problem, same author, same afternoon. The first version gets a “can you clarify?” comment and dies. The second gets an estimate in standup and ships on Thursday. The difference is not writing talent: it is 5 fields, each of which exists to kill one specific reason engineers reject tickets.

Why each field kills a rejection reason

Ticket quality determining fix speed is measured, not folklore. In “What Makes a Good Bug Report?” (FSE 2008), Bettenburg and colleagues surveyed developers and reporters across Apache, Eclipse, and Mozilla. Developers ranked steps to reproduce, stack traces, and test cases as the most helpful things a report can contain. Those are exactly the items reporters find hardest to provide, a gap the paper calls an information mismatch.

For UX findings there is rarely a stack trace, so the annotated screenshot does that job: it pins the exact element and state you are talking about. Map each field to the objection it removes:

• “Can’t reproduce” → steps to reproduce. Numbered, starting from a URL, ending at the failure. Marker.io’s guide lists irreproducibility and missing environment as the classic bounce reasons, and the Bettenburg survey says steps are the single most valued content.
• “Not a priority” → severity with a shared definition. “Major” means nothing until the team has agreed what Major means. Definitions below.
• “I don’t think that’s a problem” → the named rule. “Confusing” is your opinion. “Violates Nielsen #9, published 1994, cited in every HCI curriculum since” is a checkable claim. The argument moves from taste to evidence.
• “Too vague to estimate” → suggested fix + effort. A concrete proposed change gives the engineer something to accept, amend, or beat. “Quick win · ~1 hr” lets a PM slot it into a sprint without a discovery meeting.

Severity vs priority: they are not synonyms

Severity measures how badly users are hurt; priority is a business decision about when to fix it. Severity feeds priority. It never replaces it.

The canonical severity scale is NN/g’s 0 to 4 rating (Nielsen, 1994), which combines three factors: frequency (how often users hit it), impact (how hard it is to overcome), and persistence (one-time trap or every-visit tax). We collapse it into the three tiers a ticket queue understands, with a default queue behavior for each:

The honest footnote: the right-hand column is a default, not a law. Priority layers business context onto severity. A Major on a settings page hardly anyone visits can wait behind a Minor sitting inside your checkout. What the severity field buys you is a shared starting point, so the priority debate is about business, not about whether the problem is real.

Copy-paste ticket templates for Jira and Linear

Two templates, same 10 fields, formatted for each tool. Linear’s own method guide says to “write short and simple issue titles that directly state what the task is”, which is the title rule from the anatomy above wearing a different badge: name the behavior, skip the emotion.

*Title:* <the broken behavior, not the emotion: "X happens when Y">
*Severity:* Major  (Blocker = users fail or lose work · Major = users struggle · Minor = friction)
*Where:* <URL or screen name>

*Steps to reproduce:*
# Go to <URL>
# <action>
# <action>

*What happens:* <actual behavior>
*What should happen:* <expected behavior>

*Rule violated:* <e.g. Nielsen #9 · Recover from errors, or WCAG 2.5.8 Target Size>
*Suggested fix:* <one concrete change>
*Effort:* Quick win · ~1 hr  (or: Deep fix · ~2 days)

*Screenshot:* <attach, with the failing element circled>
*Labels:* ux-debt, <rule tag, e.g. nielsen-9>

<!-- Title goes in the issue title field: state the broken behavior -->

**Severity:** Major  <!-- Blocker / Major / Minor -->
**Where:** <URL or screen name>

**Steps to reproduce**
1. Go to <URL>
2. <action>
3. <action>

**What happens:** <actual behavior>
**What should happen:** <expected behavior>

**Rule violated:** <e.g. Nielsen #9 · Recover from errors>
**Suggested fix:** <one concrete change>
**Effort:** Quick win · ~1 hr

**Screenshot:** <attach, with the failing element circled>
**Labels:** ux-debt, nielsen-9

Delete any field you genuinely cannot fill rather than padding it. A short, complete ticket beats a long one with three fields of “TBD”. If you skip anything, never skip the steps: that is the field the research says developers miss most.

How many tickets should a UX audit produce?

A focused audit of 3 core flows typically lands 10 to 25 findings; file Blockers and Majors individually, and batch Minors into one ticket per screen. That range is a field observation from running audits, not a study, but it is stable: signup, onboarding, and the core loop reliably hide that much.

The batching rule matters more than the count. Filing 25 individual tickets turns your backlog into confetti and guarantees the Minors get closed in a bulk “won’t fix” sweep 6 months from now. File every Blocker alone, every Major alone, and roll the Minors up: “Settings screen: 4 minor UX fixes” with each finding as a checklist item. One estimate, one review, 4 fixes.

If you want to generate the findings themselves, we walked the full method in a complete heuristic evaluation example and condensed it into a founder’s UX audit checklist you can run in an afternoon. And if you are weighing doing this yourself against paying someone, the real cost of a UX audit has the numbers.

Keeping UX debt visible after the audit

Label every finding ux-debt plus a tag for the rule it violates: nielsen-9, wcag-2.5.8, hicks-law. Two labels turn your UX debt from a vibe into a query. “Show me open ux-debt” becomes a saved filter you can pull up in sprint planning; “we keep shipping nielsen-1 violations” becomes a pattern you can name in a retro. When someone asks how bad the UX debt is, the answer is a link, not a shrug.

This anatomy is also, not coincidentally, the exact format ClapBack outputs. An agent uses your product like a real user, and every finding arrives as a pre-filled Jira or Linear ticket: severity, the cited rule, an annotated screenshot, a plain-language reason it matters, and a suggested fix with an effort estimate. The template above is the manual version; the agent is the version where you paste a URL.

Either way, the rule stands. A finding in a doc is an opinion with good intentions. A finding in a ticket, with steps, a severity your team defined, and a rule someone can look up, is work. Work gets shipped.