At 6:56 p.m., I had 12 unanswered design questions and a review tool I had built so another developer would not have to answer them in a ticket comment.

We were preparing a major Teams-tab overhaul. The work had a four-tier design brief, 16 open decisions, and a deliberate coding gate: Tier 2 and above stayed blocked until the reviewer signed off. Tier 4 contained the billing and credit logic, so we kept that part frozen until the state machine was settled. That was not process theater. A wrong answer there would turn a visual rewrite into a behavior change with money attached.

The review tool was meant to make that gate usable. It put the brief in one place, grouped questions by tier, and gave the reviewer a structured route through the decisions. I also posted a ticket comment that pointed straight at the tool. The intended sequence was simple: read the brief, answer the grouped questions, lock a tier, then let implementation advance.

The diagnostic was in the reply location

The first response did not look like failure. The other developer had answered enough questions to settle the major Tier 4 billing calls. They were reviewing the work. They simply did it inline in the ticket instead of in the tool.

That distinction mattered. I was tempted to classify the situation as incomplete sign-off and keep steering them back to the interface. But the evidence pointed somewhere else. The unanswered material was not trapped behind a broken screen or an unclear workflow. The review had already moved to the ticket, where the discussion was already happening.

The 12 remaining questions covered visual polish, labels, scope, and one contradiction that could not be waved away:

Tier 4
- Does voiding an item unlock credit?
  The current brief contains rules that imply both answers.

That was the work. We did not need a better destination for it. We needed an answer.

Three options, one useful path

I had three reasonable choices.

I could keep routing the reviewer into the tool. That preserved the cleanest audit trail, but it would make the answer depend on changing someone else’s working habit. The tool had already been offered. Repeating the invitation would optimize for the artifact instead of the decision.

I could revise the tool until it felt easier than an inline reply. That was the most seductive option because I had built the thing. It also lost on diagnosis. No error message, missing control, or confusing tier layout had stopped the review. The reviewer had chosen the ticket as the place to think out loud. Rebuilding the interface would solve a problem I wanted to have, not the one in front of us.

So I copied the remaining questions into one fresh ticket comment and told the other developer to answer there. The structured tool stayed available, but it stopped being the gate to progress.

The comment retained the shape that mattered. Each unresolved decision was explicit. The contradiction was named. The scope and label questions were separated from the billing rules. Nothing technical disappeared just because I abandoned the delivery mechanism.

The tool was not the review

I still think the tool was worth building. It forced the four-tier brief into a durable form and made the dependency visible: no state-machine decision, no Tier 4 implementation. Without it, the first pass would have been a looser conversation and we would have had less clarity about what remained open.

But an internal tool has to earn the right to sit in the critical path. A reviewer using the ticket comment was not resisting review. They were using the channel with the least switching cost. Once that became obvious, treating the tool as mandatory would have turned a coordination aid into a delay.

The useful boundary is not tool versus no tool. It is structure versus ceremony. Keep the decision list, the tiers, the gate, and the contradiction. Drop the interface requirement when it is the only part nobody is using.

That evening, the fastest way to use my review tool was to stop asking anyone to use it.