It’s embarrassing when you make an obvious mistake. It’s worse when it represents your company or entity, and it’s painful when that mistake is spread far and wide.
An iPhone app promoting Mitt Romney’s campaign is the latest example of this: a simple typo led to widespread amusement, in a word campaigns invoke regularly: America.
The app offered a series of overlays that allowed users to take a photo with a Romney-branded overlay, and the photo with the overlay could be shared on social media. But then people noticed that one overlay misspelled, in large letters, America, and it went viral. The misspelled overlay was even used as one of the screenshots in iTunes (seen at right).
Romney’s campaign spun up quickly, taking down the screenshot right away and pushing an update for the app. Amazingly, their update was approved in about 24 hours (normally it takes a week or more), meaning Apple was probably paying attention and pushed it through. Most of us aren’t so lucky. Even when you do update something to fix a mistake, it can linger: Google caching, screenshots taken by visitors, lag time for pages to be re-indexed and even historical records like archive.org can keep a mistake alive long into the future.
The mistake shows the importance of the QA process, and how it can’t just be limited to whether it looks good in a particular browser or if clicking a button takes you to the right spot. You need to make sure your page type, graphics and even meta tags are accurate and correct.
My time as a copy editor for a newspaper chain ingrained in me that you should always double check what you’re handed, early and often, no matter how many people supposedly have looked at it. Many times you’ll find in the rush to make the deadline, steps got missed and mistakes therefore make it through. Here are examples of things to double-check:
- Just as you’d check headlines in a newspaper, check the type in header tags. Both humans and machines scan those and read them more carefully; those typos are the most obvious.
- Check all phone numbers and E-mails with the client to ensure their accuracy. At the newspaper people would call the phone number at the end of an article to make sure it was correct – I can’t tell you how many times I tripped across a magical 9-digit or 11-digit phone number that needed correction.
- Check graphics a bit more carefully than type. Many times graphics bypass the text writers/editors as they’re generated by a different person. In the web equivalent, designers design graphics, while a copywriter or the client itself will provide the type. Since the designers are sidestepping the standard copy process, it helps to confirm everything.
- Don’t misspell class names in code, like CSS. Enough of us look at each other’s work to see how they approached a challenge, and the code is available in a mouse click or two. For engineers it’s a bit deeper, but misspelling class names in code doesn’t give clients or partners a reason to feel confident about your work.
- Check your meta tags carefully. We had a situation where meta tags on one client’s site had a principal site owner’s name misspelled for more than 18 months. It was caught and fixed when we rebuilt the site, but it’s incredibly embarrassing.
- Always confirm with the client whether the copy you’re being provided in a design is live copy or dummy copy. Sometimes, the designers will place obviously dummy copy, like lorem ipsum, but sometimes they don’t, and it’s not as clear. Just as newspapers are shamed when they let dummy copy go to print, a development firm should always be a line of defense from dummy copy going live, and helping to ensure that it’s removed well before launch.
- Similarly, confirming the pictures that are being used are final is also important. One of our design partners put dots inside pictures that needed replacement; that was ingenious and gave us a way of knowing that items were going to change. We don’t see that often though, and so it’s best to just ask.
The QA process is important, and part of that is ensuring you have the proper depth of QA for the project you’re working. Don’t be afraid to ask too many questions; your clients and partners would rather be asked more questions and get it right, than less and lead to mistakes. Bad QA is bad for “Amercia.”
Footnote: Thanks to Charles Apple’s post for inspiration. His blog is informative, whether or not you’re a journalist. Check it out here.
