Mock Up the Extreme Data Cases

Design mockups are usually drawn with ideal data: short, tidy names, every image present, and a list of exactly five items. Production has users with zero items, users with a thousand, and people whose names run past thirty characters. A state missing from the mockup is decided on the spot by whoever implements it, and that decision comes back as a layout bug. This article covers the extreme-data screens to include at design time, and how to check them in review.

Why extreme data belongs in the design phase

Implementers treat the mockup as the answer. When they hit a state it does not show, one of three things happens:

• They ask the designer (which costs waiting time, and many skip it)
• They decide for themselves (results vary from person to person)
• They do nothing (the broken layout ships)

Fixing it later means redoing design, implementation, and testing. Drawing one more screen up front is far cheaper.

Six extreme-data cases to include

1. Empty (zero items)

Every new user sees this screen first. Do not stop at "No data"; show what to do next.

2. Exactly one item

A layout built for a list can look stretched with one row, or leave a lone divider floating.

3. A large amount (1,000+)

Pagination or infinite scroll? Does the counter still fit when it reads "1,284 items" with a thousands separator? Decide here.

4. Extremely long text

Long names, long URLs without spaces, body text with line breaks. For each field, choose: wrap, truncate with an ellipsis, or provide a way to see the full text.

5. Missing values (no image, empty optional fields)

What is shown when no avatar is set? When an optional field is empty, do you hide the whole row or show "Not set"?

6. What a user without permission sees

Hidden, disabled, and "error on click" are three different designs. Draw which one applies, and whether a reason is shown.

How to check this in design review

1. For each screen, list which of the six cases apply
2. For any case with no mockup, state whether you will draw it or leave it to the implementer
3. If left to the implementer, write the rule in one line (for example: "truncate long names to one line; show the full name on tap")
4. Copy the agreed rules into the acceptance criteria of the implementation ticket

To keep the effort small, do not draw every screen. If the pattern is the same, draw one representative screen and note "same rule applies".

A failure example: the header that broke on a long name

The mockup showed the user name "Taro Tanaka". In production, one customer had a 40-character organization name, and the header button was pushed off screen. The implementer was not at fault: the mockup had no such state and nobody had decided. A one-line rule such as "truncate header names at 15 characters" would have prevented it.

Putting it into practice with Bugoon

Even a careful design cannot predict every extreme case. If you embed the Bugoon widget in your site, whoever finds a broken screen can take a screenshot on the spot, circle the problem with an annotation, and send the report. The recorded operation steps show what data led to that screen. Reports connect to GitHub Issues, so each one can go straight onto the design backlog as "extreme data to add to the next mockup".

If you tag each production layout break with which of the six cases it belongs to, your next design-review checklist grows from real examples.