Jim Nielsen’s “Sanding UI” Turns a Tiny Flexbox Bug Into a Wider QA Lesson

# Jim Nielsen’s “Sanding UI” Turns a Tiny Flexbox Bug Into a Wider QA Lesson

*Event date: 2024-09-21*

By IO Digest Desk

A short post that circulated on September 21, 2024 makes an unusually durable point about interface quality using one very ordinary bug. Writing on his blog, Jim Nielsen describes a development habit he compares to sanding wood: build something, click through it repeatedly, feel for splinters, make small adjustments, and keep repeating until the rough edges are gone. The metaphor is simple, but the example he uses shows why this style of testing still matters even in an era of mature browser tooling and automated checks.

Nielsen says he was working on a standard list of radio options and using flexbox to lay out the control and its label. The visual result looked fine, but his repeated click-through uncovered a dead spot between the radio input and the text label where clicks did not toggle the control the way he expected. Because the label and input were already associated correctly, the problem was not semantic markup. It was spacing. A flexbox gap that made the UI cleaner visually had also created a small interaction void.

That kind of defect is exactly the sort of thing many teams fail to catch early because it lives in the gap between correctness and experience. The control technically existed. The label technically existed. The association technically existed. But the user’s hand does not interact with markup abstractions. It interacts with pixels, hit areas, and habits. If a person sees a single visual unit and clicks anywhere inside it, the software should behave as if the whole area belongs to the same action. A dead zone, however small, reads as friction.

Nielsen’s fix was similarly modest. He removed the flexbox gap and added padding to the label instead, which preserved spacing while making the control behave as a fully clickable unit. There is nothing novel about the CSS technique on its own. The stronger point is process. He found the issue not by reasoning about flexbox from first principles, but by using the interface repeatedly through multiple navigation patterns and trying to break it. The post specifically mentions clicking, using the browser back button, right-click navigation, in-app back affordances, and keyboard shortcuts.

That approach blurs the line between development and QA in a productive way. Nielsen calls it “kind of a QA tactic,” but he frames it more as craft discipline than checklist compliance. In woodworking, you sand, inspect, run a hand over the surface, then sand again. In interface work, he suggests, teams should use software the same way their users will use it until the awkward spots become impossible to ignore.

The lesson scales beyond a radio button. Modern UI stacks make it easy to ship polished-looking components quickly, and CSS features like flexbox remove enormous amounts of layout friction. But speed of assembly can disguise subtle interaction mistakes, especially when spacing, motion, and navigation are treated as cosmetic layers instead of functional parts of the product.

That is why the post resonates. Nielsen is not arguing against frameworks or against modern CSS convenience. He is arguing for a deeper standard of finish. A product can be technically correct and still hand users a dozen tiny splinters. The only reliable way to discover many of them is still the oldest one: keep touching the thing until it feels smooth.