How to ensure your designs work if you can't access sample data

How designing limit tests can help you avoid nasty content surprises

Art by midjourney

"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 look like in your design.

Two rows of a table. One default, one limit test

This allows you to see how content might change the component and shows Engineers how the design is supposed to behave at different resolutions.

Two cards, one default, one limit test

This is especially helpful if you, like me, couldn’t get access to sample data.

Create limit tests around your design limits, not sample data

One of the biggest problems with including content in your design is that you might not have access to it. As a result, you may not want to deal with the headache of trying to ‘fake’ descriptions/text that distracts your stakeholder’s attention.

After all, this is one of the arguments for using Lorem Ipsum in your designs.

However, the Limit Test is different: in many cases, it’s a wrong piece of data that’s not trying to be realistic. Instead, it’s trying to answer a design question: at the extreme, what does your design look like?

This is often a question that your Engineering team wants to know. After all, they often do QA testing around specific scenarios, such as:

• What if I input nothing but blanks in this field?

• What happens if I edit a field and I don’t change anything?

• What if I input 15 digits into the 9-digit phone number field?

• Etc.

As a result, seeing the extreme case of a design component can help you in this scenario.

With my Data Visualization component, for example, I hadn’t realized how bad the overlap was with some values since I didn't have sample data. However, if I had mapped out this extreme example, I probably would have been able to see some of the problems.

Of course, not every design component needs a limit test: some will likely be fine, no matter what. However, some design components that you may want to limit testing include:

• Data Visualizations of any kind

• Cards or other things mapped to a grid layout (especially Hierarchical grids)

• Titles and Subtitles

• Large paragraphs of text

• Hyperlinks (and some buttons) that may run long

• Data Tables

• Tooltips, especially context-sensitive help

• etc.

Using limit testing doesn't doesn’t just help engineering; it can also provide some user insights.

Test your users with limit testing to gain insights

Seeing the extremes of a design can help Engineering and spark unexpected conversations with users.

For example, to make our site more accessible, your team might want to make your hyperlinks more descriptive to guide the user better. However, you're unsure if that’s the right approach, especially since you have many of them.

So how do users react to having eight hyperlinks on the page with descriptive text like “Learn more about how our Product helped X” on the page? Do they see them, or is it just background noise?

If we included one hyperlink, they might notice it much easier. However, with eight hyperlinks, our “limit test” version can allow us to get to the heart of the issue and get critical user feedback.

However, I’d recommend limiting test versions as alternative design solutions to avoid disrupting regular testing.

After walking your users through one design solution during testing, you can show them design alternatives and help them understand which works better for them and why.

Designing for the extremes doesn't doesn’t just apply to research

You never want to be surprised, as a Designer, about how the final product looks. However, sometimes, it happens because we do not consider the content that will fill in our design.

We know, as designers, that we should not design for the average person. However, we may only sometimes know how to include content and test how extreme cases work.

This unfamiliarity around content can be a hidden hurdle that trip designs up. However, it doesn’t have to. By creating a limit test, which forces you to think about the extreme, you’re considering how your design may shift and reduce any nasty content surprises.

Take some time to think through the limit case, especially if you’re spending time showcasing different types of designs. It’s a small step that can significantly impact how the final product is received.

I’m creating a Maven course on Data Storytelling for Designers. If you’re interested in learning (or would like to provide feedback), consider filling out this survey.

Kai Wong is a Senior Product Designer and Data and Design newsletter writer. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.