Avoid the pitfalls of pasting improbable dummy placeholder text (lorem ipsum or otherwise) into your user interface designs.
When communicating UI design, you’ll sometimes use temporary placeholder text (“dummy” text) in your wireframes, mockups, or even interactive prototypes.
Below I list some of the problems with pasting perfect pieces of placeholder text all over your UI design.
Note: in this article, placeholder text refers to temporary dummy text (e.g., lorem ipsum) that appears in UI design mockups and documentation. It does NOT refer to the placeholder text labels that appear inside form fields in a published app or live website.
Common placeholder text problems
Unrealistically concise titles, labels, descriptions, etc.
Intentionally or unintentionally, placeholder text often depicts headings, labels, text blocks, etc. as shorter (i.e., containing fewer characters) than real-life content will actually be in the final product.
This might happen due to bad assumptions, wishful thinking, or from a conscious or subconscious desire to make the design to look nicer.
- Invites designers and reviewers to ignore and defer design concerns such as:
- Text overflow (e.g., text wrapping vs. ellipses vs. other)
- Proper static font sizing
- Whether to specify dynamic font sizing.
- It will be more expensive to address such design issues later (and/or might result in a worse implementation than if those aspects of the design had been considered and specified earlier.)
- The design under review doesn’t have the same visual effect the real-life product will.
Related: on occasion, placeholder labels are longer than the real-life text will typically be. Some of the same problems can result.
Ambitious UI elements that no one will want to fill with real text
Sometimes designs include well-intended text-filled elements… that are doomed. Perhaps a place in the UI is carved out for a page summary or detailed user instructions. These UI elements appear sensible and look nice with dummy placeholder text! But when it comes time to actually write something to put in there, problems become apparent.
- In the abstract, design reviewers can lazily assume all sorts of compelling, life-changing, product-selling copy will fill the spaces reserved for text.
- Reviewers might even be lulled into not thinking about that element at all. It looks good in the mockups… and it’s probably there for a reason, right?
- When the time finally comes, however, filling those elements with text might not work out:
- No one knows what to actually put in there; or
- Any text that is put there is not useful or is unwanted noise.
- Perhaps some pages can make good use of that text-filled element, but other pages just don’t need it at all. Design guidance is needed for when the element is empty.
- Perhaps the amount of text actually written for this element in the final product results in an unbalanced or odd-looking UI. Not what the designer intended. If the truth was known earlier, the designer could have improved the design before it was even implemented.
Multiple elements copied and pasted with the same placeholder text
Just about any app or website has the potential for repeated elements on the same page (e.g. article previews, product cards, etc.) It’s common for the designer to copy and paste the same components with the same lorem ipsum placeholder text for each instance in a UI mockup.
Identical blocks can give an unrealistic impression of the design
- Everything lines up nicely
- Everything looks neat and tidy
- The overall effect is not realistic
Identical blocks can obscure design and layout issues
- Allows designers and reviewers to misunderstand or ignore issues of alignment, sizing, layout rules, etc.
- Many of these layout details would be immediately apparent if the placeholder text were simply varied instead of repeating the exact same text for each
- For example, cloned box-elements displayed side-by-side are always the same height. What happens if one box has more text? Does it wrap to more lines and make that box taller? If so, do all the other boxes have to match that height? What if one box has way less text? Does the box get shorter? Is there a maximum and/or minimum height for boxes? Etc.
- Again: it is better to consider, address, and specify around these issues sooner rather than later.
Filling every possible data slot with text, when in real life that won’t happen
Mockups often include all of the data that is possible to include, in every instance. In the final product, however, all the data might not always be available or necessary.
For example, a user account panel may need to be able to display address, phone number, email address, etc. But what if the address and phone number were optional when the user signed up, and she left them blank?
For similar reasons as mentioned above, it helps to create and see mocked-up examples where optional data is not shown, in various configurations. This will clarify the impact (or lack of impact) missing fields have on layout. For example: should there be “holes” where the missing data would have been, or does the other data “move up” to fill the gaps?
Holding on to lorem ipsum for too long
Content is very important. Depending on your product, it might be the most important thing.
The further along you are in the project, the more you should be using and testing real content in conjunction with the design.
As your initial design graduates from lo-fidelity sketches/wireframes, realistic content needs to replace more dummy content. As your mockups graduate to higher-fidelity prototypes, lorem ipsum should be banished, and you should be incorporating and testing the actual intended content wherever possible.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
BetaTesting Blog 