How designing limit tests can help you avoid nasty content surprises

“This is what the final product looks like.” An Engineer said, which caused me to shift uncomfortably.

He was demoing a Data Visualization component I had designed but with actual data this time. I hadn’t been able to get sample data while designing it, so I wasn’t happy seeing what the finished product looked like.

As I’ve learned to call it, content-last design often can trip up the most polished of designs. While your prototype may look perfect, your design may fall apart once you throw in long names, descriptions, or weird characters (like blanks).

You probably don’t have time to include content that tests for all of this, but there’s a simple way to ensure the design behaves how you want it to: create a limit test of a component.

Doing this allows you to see the extreme cases and ensure that the design behaves the way you want.

Ensure intentional choices with content/design pattern

Often, Designers may not be aware of every detail of a design component, especially if they use Lorem Ipsum. You may be using a Design System where the minute interactions of each component were thought up by someone else.

Imagine you’re using the “table” component in your design system. If one row is particularly long (i.e., something like a description), does your component:

1. Truncate/hide the cell content after a certain length (i.e., “we should really us…”)
2. Wrap the text around to accommodate the additional wording.

If your component uses the first option, you might need to consider an interaction allowing the user to read the full description.

On the other hand, if your component uses the second choice, you might need to consider formatting issues or end up with some ugly tables with broken text at specific resolutions.

This scenario is where a limit testing example helps us understand these issues. A limit test is straightforward: it shows what an extreme example of content might…