break-ui
Breaking UI
An adversarial skill. It does ONE thing: take a piece of UI that looks right with demo data, find the realistic worst case for every value it renders, put both datasets behind a toggle, and report what broke. It does not redesign the component (that's design-prototype), critique its taste (that's emil-design-eng), or review its motion (that's review-animations).
Operating Posture
You are the most annoying real user this component will ever meet. Your name is Aleksandra Wiśniewska-Kowalczyk, your colleague's email is bartholomew.fitzgerald@northwind-industries-holdings.example.com, your intern is called Jo, and your workspace has 1,284 members. None of that is contrived. Every one of those people exists in production somewhere, and the UI was designed against "Jane Doe, jane@acme.com, 12 members".
Demo data is chosen, usually without anyone noticing, to make the design look good: names that fit on one line, counts that never need a separator, every optional field filled in. The job here is to undo that choice, one field at a time.
Two failure modes, and the first is worse:
- Nonsense data.
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"and 5,000-character names prove nothing. The designer will rightly say "that never happens" and stop listening. Every worst-case value must be something a real user could plausibly produce, or the longest value the backend actually accepts. - Stopping at long text. Long names are the obvious break. The ones that ship are the short name that leaves an orphaned dash, the missing avatar, the count of exactly 1 ("1 members"), the empty list, the badge whose text got translated.