Site Launched? Review Your Copy

If you’re building an app or an online product, you’ll likely go through pretty clear-cut development, beta test, release, and revision processes.

If your product or service is online, each process should include the text you’re using in your interfaces.

Over the last few months, we’ve seen:

1. how to user-test your web copy in development and
2. how to use beta-test feedback to enhance your text so that it communicates more effectively in the context of your interfaces.

Today, we’re adding a third step to that equation: reviewing the text after launch. This includes considering things like error messages, system emails, marketing content, and so on.

Why review text after launch?

The testing process—from user testing with a handful of individuals, through beta testing with a raft of passionate advocates, to releasing to an actual market—takes in bigger and bigger sample sizes each time, the final one being the biggest of all.

For developers, this provides an increasingly clear picture of how robust and functional the system is for large groups of people using it in a plethora of slightly different ways.

For UX specialists, including writers, and communicators, including marketers, at least some aspect of the functionality’s robustness lies in how effectively it communicates with users, anticipates their needs, and responds to them.

No matter how great your product is technologically, if users can’t understand your button text or instructions, they won’t be able to use it.

A text review after launch lets you tweak the whole of the product—and the whole of the marketing message—in situ, and in tandem.

Basically, it gives you a chance to make the messages consistent, and align your product most closely with users’ expectations.

The review

Okay, so you’re sold on the review. But where do you begin?

Usually, you’ll be able to divide your text review into three parts:

1. the product interfaces, including errors
2. system emails and other notifications
3. the marketing content, including sales pages, FAQs and help content, and maybe some campaign emails.

Since your devs are likely to be battling bugs and making tweaks, it may not be a bad idea to start the review by looking at the product interfaces. This is, after all, your offering, and the other items in the list above need to be built around the product itself.

Get the product right first, and it’ll be easier to tweak your comms to match.

Reviewing the product interfaces

Bug reports and customer support requests are good places to start looking for issues with interface text, as they tend to reveal points of miscommunication or confusion.

You may well find that terminology or phrasing that worked fine in beta bewilders a broader market, so try not to dismiss any request as too simplistic before you actually consider it.

With so many users working through the product’s various processes at once, it becomes very clear if there are logic issues in the way instructions are phrased. It’s easy to see where linkages between steps in a process are weak or failing. And from the support requests, it can be a pretty straightforward matter to amend those issues.

Once you feel the interfaces of your product are as tight as can be, and you’ve amended your brand vocabulary where necessary, it’s time to turn to your system emails.

Reviewing system emails

To do this, go back through your interfaces from start to finish, as a user would, for each process. Each time you complete an action that triggers an email or notification (or is triggered by one), check that that notification reflects:

• the context of the trigger within your product
• the language used within that context
• the user’s context on receiving the notification
• the context into which you want them to move.

That sounds a bit complicated, but all it means is that when the user gets a notification, they need to know who it’s coming from, why, and what they need to do about it (if anything).

So, for example, if the trigger for the notification is that the user clicked “Sign up” and entered a username and password to join your service, you might want to reference their “sign up” in the system email.

Maybe you’ll thank them for signing up. And perhaps you’ll provide them with links to key pages on your site or in your help content to make it easy for them to get started using your product.

You’ll probably also want to ensure consistency between the emails as you do this, so that they carry the same branding, tone, vocabulary, and so on throughout.

Reviewing marketing content

At the very least, if in the process of the previous two steps, you’ve changed the wording in some interfaces, you might need to retake screen captures for marketing collateral and FAQs.

You might also need to alter the on-screen references in your help content, or instructions in promotional emails.

And if you’ve tweaked your brand vocab, you might need to alter certain references in your marketing materials.

The benefits

A recent post-launch copy review that I was part of significantly strengthened the brand’s voice through the product interfaces.

It wasn’t an outcome I was expecting, but the post-launch review allowed us to tweak our interfaces to a sort of “final version” that built on all the prior “drafts” on interface text we’d used through user and beta testing.

This final review allowed us to combine everything we’d learned about our userbase along with our growing sense of the (new) brand’s and product’s position and personality.

The post-launch review shifted out instructional text forward from merely functional to clear and friendly. Our system emails improved from stilted but successful to relaxed, efficient and effective. And our sales and help content complemented the product so closely that they made the usage experience seem almost effortless.

Not a bad outcome for a few hours of work.

Do you complete post-launch reviews of your product’s interfaces and materials that surround and support them? I’d love to hear about it in the comments.