back

Design engineers should test with ugly data

Pretty data makes weak interfaces look strong.

A dashboard with short names, perfect avatars, round numbers, and balanced chart data will almost always look fine. That does not mean the design is ready.

If you want to know whether a UI works, test it with ugly data.

Long names expose layout guesses

Short names hide problems. "Maya Lee" fits anywhere. Real names do not.

Try names like:

Watch what breaks. Does the row grow too tall? Does the action button move away from the content? Does the name overlap the badge? Does truncation hide the only useful part?

Long text forces you to decide what the component is allowed to do.

Missing images are normal

Avatars fail. Product thumbnails fail. Logos are missing. Users upload bad images. APIs return nothing.

If the design only works with a perfect image, the component is not finished.

A missing avatar might need initials. A broken product image might need a neutral placeholder. A missing company logo might need a simple fallback shape. The fallback should look intentional, not like a browser error.

The easiest test is simple: remove the image source and reload.

Empty arrays are not rare

A list with five items looks complete. A list with zero items asks a different question: what should the user do now?

Empty is not always the same state. A table can be empty because the user has not created anything. It can be empty because filters removed every result. It can be empty because loading failed and the app swallowed the error.

Those states need different messages. "No projects yet" is fine for first use. It is wrong when the user searched for a project and got no matches.

Huge numbers change the rhythm

Metrics often look best in mockups because the numbers are chosen by hand.

Test the ugly versions:

Different number lengths can shift charts, cards, and tables. If a metric sits next to a label, a very large value may crowd it. If numbers update live, non-tabular digits may make the UI wobble.

Numbers are content. Treat them like real content.

Translated text is a stress test

English is often compact. Other languages may be longer. A button that says Save in English may become much wider in another language.

You do not need full translation support to test the risk. Make labels 30 to 50 percent longer and see what happens.

If the layout only works because every label is short, it is fragile.

Narrow screens reveal priority

A wide screen lets weak hierarchy hide. A narrow screen forces choices.

When space runs out, what stays visible? What wraps? What collapses? What becomes secondary?

If everything is treated as equally important, the mobile layout will feel crowded. Ugly data plus a narrow viewport is one of the fastest ways to find that problem.

Keep a small ugly data set

You do not need a complex testing system to start. Keep a few bad examples around and use them while building.

  1. One very long name.
  2. One missing image.
  3. One empty list.
  4. One huge number.
  5. One long translated label.
  6. One narrow viewport.

If the UI still feels clear after that, it is probably much closer to production-ready.

Good data shows you the design. Ugly data shows you the product.