User testing a new feature – the content perspective



Can you spot the fatal error?



Web managers and content editors should be participating in the testing of new features on your website (or separate apps if you have them). See James D Clarke’s blog on how not to launch an app for some of the things you can help avoid.

It’s not just about checking for typos or even house style:

• The manager or content person is usually not the person who has carried out the technical development, so you have a fresh pair of eyes to bring to the project.
• You have a pretty good idea about the level of ability and understanding of your users – and may be able to get hold of some ‘real’ users to help your techies complete their testing. 
• You’ll probably be a quite technically-savvy person, so if you personally struggle with any element of the application, it should be a major flag that there’s a problem. 
• And out of sheer self-interest, you’ll be at the sharp end of responding to any complaints, so it’s a good idea that you try to iron out any flaws before launch.

Test scripts

If your organisation is well-versed in user acceptance testing (UAT) and protocol-driven, you may be given a script to follow. This is a series of instructions about which buttons  to press and what to enter in which boxes. You will be asked to ‘pass’ or ‘fail’ specific actions, and provide notes.

Offer to be the guinea-pig for the test script before other users are asked to follow it, so you can ensure the script is well-written and makes sense to people who haven’t been involved in development.

Beyond the script

Even if you do have a script, it’s always worth going ‘off-piste’ and looking at other aspects that may not have been included, because the script is often about technical functionality and you have other feedback to offer.

Look at all the content for house style, spelling, grammar, punctuation and plain English. But most importantly, check the text actually assists the user of the application. Is there too much distracting and irrelevant introduction blurb, or are some key instructions missing?

Persistent issues

If you discover persistent styling issues (developers seem Fond Of Using Capitals, for example), you must gauge whether you can provide one overall change instruction that the developers can apply throughout the site, or whether you need to go through each page editing as you go. The latter can feel very time-consuming and pedantic but remember not everyone is trained to spot stray apostrophes – your skills are needed to avoid distraction and nuisance for users.

Not just the obvious

Remember to look at text that doesn’t appear at first glance. When you fail to complete a mandatory field in a form, does error text appear, and does it make sense? If you have to register to use a function, what is the wording in the email confirming that you filled in the form? If there are security questions, are there enough options for everyone to use them (not everyone has an oldest niece, a place they got married, or a pet)?

Break it – they’ll thank you

Lastly, actually positively try to break the system. Put letters in a phone number field and see what happens. Put in the wrong password. Click buttons if you are not sure what they do.

Don’t feel bad if you spot errors. Your development team should have built in time to fix any problems, and in the long run they will be pleased that it was you who spotted the problems, and not the big boss or an important external stakeholder. Be nice when you provide your feedback, and offer to help where you can, because you have a lot to offer.