When you say “no” to a customer, it’s got to be for a solid reason. One of our most important boundaries we set with clients involves when and how we’ll run user tests for new website layouts or features.
We only run user tests against “real world” content. (Or, in the case of projects that aren’t fully live or public yet, content that looks close enough to what will run at launch.)
We respect that a lot of work on websites tends to happen in parallel. It’s not uncommon for some teams to have writers, designers, and engineers who never even meet each other, because they’re working in their own swim lanes against their own deadlines.
But when we start talking to prospective clients about new website roadmapping or our user experience express audits, we make sure the pages we’re testing include real content. Some content mockups we’ve recently rejected include:
- The usual “lorem ipsum” — standard typesetting test copy that’s been floating around for hundreds of years.
- Passages from a developer’s favorite novel.
- A supermarket shopping list, flowed into paragraphs and repeated ad nauseum.
- The Gettysburg Address.
- The Doctor’s Speech to Akhaten, while one of my favorite television moments, still works poorly as a test for website user behavior.
Any of these items might be marginally useful during early mockups in the design phase of a new website or a new layout. But when it’s time to test whether users can really accomplish what they need to do on your site, dummy text does way more harm than good.
Three reasons why we stopped using “lorem ipsum” during UX testing
1. Your stakeholders can’t help but pick apart their content
Over the past ten years of running user experience tests with both end users and company stakeholders, there’s one thing that holds true no matter what size business we’re working with:
Stakeholders love to scrutinize their content.
It doesn’t matter if it’s a press release that hasn’t been published yet, or an executive biography that’s been on the website for a decade. If you ask a client to “act like a user,” they’re going ignore that request and pull apart all the things they see on the screen, even the elements that technically have nothing to do with the feature you’re testing.
That’s why we try to find the most innocuous, familiar content inside the CMS when trying out new layouts or new features. When it’s not a “hot button” item, most stakeholders will say, “oh, I’ve seen this a million times.” Some of them may shrug and ask us why we’re using that content—and they almost always laugh and agree with us when we tell them the truth.
The UX mantra, “you are not the user,” applies the most to stakeholders. They’re too close to the content to truly act the way real end users do. However, it’s unrealistic to leave stakeholders out of your testing and approval process. Therefore, using real content minimizes the chance that your project gets derailed because a stakeholder can’t visualize what’s really going to happen when a site goes live.
2. Placeholder content can’t accurately predict real world uses
In over twenty years of building websites, I’ve counseled plenty of designers who have staggered away from executive boardrooms, stunned to learn that their carefully composed content guidelines flew out the window the second a layout’s code got deployed.
Try telling a Fortune 500 CEO that their carefully crafted headline, approved by attorneys and brand managers across three divisions and four partner organizations, can’t be used because a designer constrained the space for H1 copy to 40 characters. (This is how you end up watching company leaders abandon their own CMS and just start posting things to Medium.)
To be fair, if I wear my content strategist hat on for a moment, there are plenty of best practices around content length and constraints that developers often try to introduce during user testing. Looking historically at what an organization has always published can show you whether you’ve got a realistic shot at ramming those changes through at this moment in time.
Even if a design sails through approvals with placeholder copy in place, user testing is the perfect opportunity to ward off potential future demons. You can ask CMS editors to stage versions of their most important press releases, asking specific questions about what’s working and not working for their process.
Meanwhile, you can deliberately render your toughest archive copy in a new site’s layout, then ask your stakeholders to judge whether you can write it off as a corner case or if you’ll need to adjust a system’s specs to accommodate “real world” content.
3. Real world content highlights what real end users want to see and do
When user testing new features or layouts with end users, real content helps us weed out “false positive” responses during eye-tracking and click-tracking tests. We assume that most testers want to make us happy by “getting the answer right.” It’s a bias that gets introduced all the time in website development.
For instance, if you’re a product owner in a large organization, of course you’re going to assume that every customer who lands on this page is going to be so delighted and that they’re going to want to click all the things! And if you’ve empaneled sample test users (hopefully from outside your own company), they’re going to make the same assumption when they see a page full of placeholder copy.
On the other hand, when you stage a real-world example of what a page would likely look at “in the wild,” users behave much less predictably. (And that’s where the fun begins.) When tasked with “complete this mission” style examples, we start to see just how important microcopy, wayfinding, and other subtle layout elements really become.
In most of the tests we’ve run for clients, even we’re surprised at how quickly end users will tune out the page elements that don’t help them complete their missions. All that delightful, flowery copy that someone wrote just got skimmed on the way to clicking a “call to action” button. Or it got ignored while users sprinted to an internal site search function.
Getting clearer about when and how to test your website layout with real content
Press a little harder and you’ll often find something you can use to seed a test layout, even if your project’s not yet live. Old press releases, old newsletter copy, even transcripts of interviews or articles about a company that have run elsewhere.
If you’re working closely under non-disclosure rules, as many of our clients do, you can still mock up a proximity of real-world content for an imaginary product, using the same content guidelines you’ll use when your project goes live.
Of course, you don’t have to go through any of these challenges alone. (And, if you’re working in a small shop or if you don’t have the luxury of in-house UX expertise, you don’t have to do it yourself, either.) Clients hire us to help evaluate and test both new and overhauled website designs before, during, and even after launch. Book a discovery session with our team to learn more about what we’ve revealed to clients who just want to know their sites are going to work.
