How to ensure your designs work if you can't access sample data
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:
Truncate/hide the cell content after a certain length (i.e., โwe should really usโฆโ)
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.
This allows you to see how content might change the component and shows Engineers how the design is supposed to behave at different resolutions.
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.
This is helpful right now. We are adding a grid view to a product area that has historically been table view only and it's tripping me up with all the little indicators and pieces of text we want to show/hide without growing the container. We've opted to build a WIP design system to experiment using absurd placeholder text like a "Longest name in the world because some people want to..." title component. We don't pay attention to error states as often as we should, but our engineers always ask about them. I think we just assume it's going to work every time, or that it should anyway. To help catch some of this, I do a design review with engineers every sprint. They call out a bunch of "if, then" scenarios that I wouldn't have considered.
Thanks again for writing this, I'll share it with my design team. :)