Extreme length and malformed data belong in prototype tests

What it is

Average-length “normal” samples will not catch truncation, wrapping, overflow, or parse failure. Extreme length (empty, tiny, huge) and malformed format (emoji, right-to-left scripts, scientific notation, identifiers with spaces, bad encodings) have to be first-class test data already at prototype time, not defects left for after launch. This is not nitpicking: names, addresses, amounts, and log ids already look like this in live systems. Wait until engineering is done and the rework lands on locked components. Unlike placeholders that hide edges, this asks you to put hostile samples in on purpose, even when a production store is not yet at hand.

Why it happens

Layout and validation are hypotheses about strings: a max width, a national phone, no zero-width characters. Extremes exist to break those hypotheses. A long title covers an action; a short title strips a list of scannability; a bad format breaks search and copy. People also change strategy on extremes: stop reading, guess, blame themselves. If the prototype never offered those strings, those strategies and the matching compensations (expand, copy, warn) will not be designed. The earlier the extreme, the cheaper the compensation; the later, the more you get an ellipsis and a shrug.

Studying it

Build a hostile table per input and display field: empty, one character, language-upper-bound, mixed script, injected specials, wrong separators. Force the task script to use a hostile record at least once; do not wait for a participant to draw one by chance. Code overflow, whether truncation is recoverable, and whether error copy blames the user. Internationalization walkthroughs and fuzzing can be scaled down to a prototype: you are not attacking the system, only layout and validation. Do not treat “the one long title the designer hand-set” as coverage—that one was usually quietly shortened.

Where it stops holding

Meaningless noise (thousands of Zs) has no ecological meaning on some fields and wastes the session; hostile values should come from the tail of that field’s live distribution. Security testing (injection) has its own method and ethics; malformed format at prototype time is experience and validation, not a penetration test. Some extremes appear only in a language or on a device; construct the sample for the target market. Truncation costs more for assistive-tech users; hostile tests should include overlong text under a screen reader.

Applying it

• For every critical field, prepare four records: shortest, longest, empty, one malformed format, and write them into the script.
• Do not shorten demo data to make a screenshot pretty.
• Overflow must have a testable compensation (expand, wrap, prompt), not a designer’s “it would ellipsize.”
• Hand the hostile table to engineering as acceptance, not as polish for later.

Related

• Same group: Q5.11.1 Placeholder data hides edge cases that real data would surface · Q5.11.3 Privacy-sensitive tests need de-identified data, not live production feeds · Q5.11.4 Attractive sample data leads reviewers to underestimate live complexity
• Adjacent: Q5.03 Interactive prototypes · Q5.01 Fidelity levels
• Search terms: extreme data in prototypes · hostile data · truncation testing