One sentence, one component: a workable test for patch versus redesign

The one-sentence rule looks like a style preference until you notice what it measures. The giveaway, according to the RAXXO post on dev.to, is catching yourself explaining a screen's structure before you can describe the fix ^[2]. Read that as a compression test. If the fix will not fit without a preamble, the preamble is the defect, and the component in front of you is only where it surfaced. A patch is the case that does compress: one sentence, one component ^[1], the label left stale after a feature rename or the form field that swallows a paste, shipped the same day ^[4].

The repetition signal appears at two thresholds in the same post. The summary says a redesign answers the same complaint from four different users in a month ^[7]. The body says the per-tool list of nominally different complaints has to grow past three in a month ^[6]. Those are one trigger, not two: past three is four, so the fourth unrelated report is what moves a screen out of the ticket queue ^[16]. The fragile part is the qualifier, that the users have not talked to each other ^[5]. Report counts are cheap to keep. Independence is a judgement, and it is the judgement carrying the signal.

Then the invariant, which is the part worth stealing: export formats and saved URLs do not change, only the screens around them ^[3]. Both of those artefacts have already left the building. An export sits in someone else's directory, a saved URL sits in someone else's bookmarks, and neither can be renegotiated by a design pass. That makes the rule a cheap proxy for the fourth question on his checklist, whether a redesign changes what the tool promises or only how it delivers on that promise ^[13]. The question needs a conversation with yourself. The rule needs a diff.

What the test does not do is size the work. That falls to the first question, one screen or a flow, where a settings panel is a weekend and an onboarding redesign touches every screen after it ^[10]. And to the second, which forces the loss to be named concretely: for OhNine, a menu bar app people check in half a second between tasks, the thing at risk is trust in a glance, and a sharper layout that adds friction there has made the tool worse ^[11]. The four questions run in a fixed order with no skipping ahead ^[9], and the answers go into a note beside the changelog entry, so the scope is on record before the design file opens ^[15]. He credits that sequence with stopping at least two redesigns that would have been prettier and less useful ^[14]. In a studio of one, the written note is the only audit there is ^[15].