Test Your Web Copy: the Why, When and How

You’ve written and reviewed your home page copy. And you’re happy with it.

But does it make sense to users? There’s only one way to find out, and that’s to get it in front of those people.

It’s time to talk testing.

Why test your copy?

To me, this question is a lot like the question “Why test your page flows or layouts?”

Yet I have few clients who test page layouts, let alone copy. I think it might be that the adoption of commonly accepted page layouts convinces site owners they don’t need to test. If this landing page layout works for [name your largest competitor], then of course it’ll work for you …or so the argument goes.

Even if that were the case (and I don’t believe it is), the language you use to communicate your new concept or service will be different from your competitors (we hope!).

Yes, it might make perfect sense to you, everyone in your office, your business partner, your life partner, and your pet beagle. But those individuals are all too close to the game to see your text objectively.

You need to test it.

What to test when

If you’ve created a new vocabulary for your product or service—especially if the product introduces a new concept about which you’ll need to educate users—testing the key terminology at the same time you test the site’s wireframes is ideal.

You might already be testing your IA labels as part of your wireframe test, so why not test key text at the same time? You could test:

• your tagline or selling proposition
• the title flow of the steps in your “How it works” copy
• calls to action and button labels
• the names you’ve given to your product’s payment tiers
• and so on.

Of course, you can also test terminology on your marketing or promotional pages as well as in your app itself, if that’s what you’re selling.

If you’ve already gone through wireframe testing before you draft your copy, you can try testing key terminology and concepts in laid-out pages, but this is less than ideal.

Wireframes let you test basic page layout, so they’re the best place to test key terminology. But if you drop only key terminology into a laid out page, it’ll look unfinished and may well disconcert users.

And if you decide to go ahead and test full copy then, you’ll never know if users did (or didn’t) get the message because of the terminology itself, or the way it was used in sentences, or because of other aspects of the page design.

Let’s see how confusing this can become through a couple of case examples.

Test case 1: copy in wireframes

Not long ago, I got to test the key terminology listed above as part of user testing of wireframes. The product was a social-network-based transactional service. The target audience could be described a mass market: keen to shop, but not technologically savvy.

We devised a vocabulary for this product, and used it to explain what the concept was and how it worked in about 60 words on the home page.

As well as this, we needed to develop a compelling headline that contained a CTA, and a button CTA that made sense to users.

We drafted this content, dropped it, unstyled, into the wireframes, and did in-person user testing with them.

The outcomes were invaluable: by asking users what they understood about the service from looking at the homepage, we:

• were able to identify key terminology that was necessary for comprehension of the service—and cut the rest
• identified opportunities to link key words to informational pages that explored concepts in full, which reduced homepage word count without risking confusing anyone who didn’t get it
• were able to hone the terminology to reflect users’ own language and their expectations. For example, instead of calling calling picture “images”, we found we could better meet user expectations by calling pictures “artwork”. Happily, this also elevated user perceptions of product quality. Win!

Test case 2: copy in the laid out page

In a project with a design agency, we literally could not keep those passionate designer types from creating page visuals. We had two different page layouts to test, and an established vocab that we tweaked to appeal to a broader audience. So we dropped the vocab into the two layouts and took them to users.

The results weren’t really useful. As you’d expect, some users preferred one page over the other—but whether that was because of the layouts, or what was being communicated in each, we couldn’t tell.

We found that users overlooked certain options within the interface, some of which used our tweaked brand vocabulary. From a UX perspective, we couldn’t tell if that was because:

• the colours prevented these options from standing out
• there were distractions on the page
• the terminology wasn’t communicating what we wanted it to.

We did find that the users’ expectations of the terminology weren’t reflected in what we were showing them, but we didn’t know whether the visual elements were masking—or intensifying—those effects.

From this test, it was hard to know where to go. We had a bunch of suggestions for developing the terminology to better suit users, but in some cases they were conflicting, they didn’t really fit the brand, and the test hadn’t really revealed priority items that, if we got them right, would make a big difference to users’ understanding.

How will you test?

As these cases show, the basic rules of UX testing apply to copy and vocab testing.

If you want to:

• use as few words as possible
• to communicate as much as possible
• as quickly as possible
• to as many of your target users as possible

…test your copy in your wireframes.

That means you’ll need to develop your copy as you design your user experience, not afterward—but in my books, that’s just good UX practice (no matter how few people do it). It also gives you the best chance of connecting with your target users right off the bat. And that’s your main objective, isn’t it?

Have you ever user-tested your copy? How will you test it next time? Tell us how you do it in the comments.