Copy Review
Every word on a page is part of the product. A typo in a button is as broken as a broken button. Learn to spot copy defects before users lose trust.
1 The Hook — Why This Matters
In 2021, a Wellington charity launched a fundraising campaign. The donate button on their homepage read "Donte now". Three weeks passed before a volunteer noticed. During that time, the organisation lost an estimated $12,000 in donations because donors hesitated to click a button that looked like a scam.
The developer had copy-pasted the label from a rough mock-up. No one checked it. The button worked perfectly, but the words were wrong. A single typo destroyed trust and cost real money.
Copy review is not pedantic. It is a guardrail against the fastest way to lose credibility.
2 The Rule — The One-Sentence Version
Every word matters. A typo in a button is as broken as a broken button.
Users cannot see your code. They only see words, labels, and instructions. If the words are wrong, misleading, or inconsistent, the feature is broken in their eyes. Copy review treats text as a first-class testing target.
3 The Analogy — Think Of It Like...
Publishing a book.
One typo on page 1 makes readers doubt page 200. They start wondering if the author bothered to check anything at all. The same happens on a website. A misspelled heading tells users the whole product might be sloppy. Copy review is proofreading the entire user experience, not just the paragraphs.
4 Watch Me Do It — Step by Step
Here is a real NZ example: checking a local council website for copy defects. Follow these steps every time you review a page.
Scenario: You are testing the "Contact Us" page for a Christchurch council site before it goes live.
- Read every heading, button, error message, and tooltip aloud Your mouth catches awkward phrasing that your eyes skip. If it sounds wrong, it is wrong.
- Check spelling and grammar Look for misspellings, missing apostrophes, and subject-verb disagreements. Spell-check helps but does not catch everything.
- Check punctuation consistency Does every button end with a full stop, or none of them? Mixed punctuation looks unprofessional.
- Check microcopy clarity Labels like "Submit" or "OK" are vague. Prefer "Send message" or "Save changes." Users should know exactly what will happen.
- Check legal text and placeholders Look for "Lorem ipsum", "Insert text here", or outdated copyright years. Placeholders ship to production more often than you think.
- Check tone and voice consistency Is the site formal on one page and casual on the next? Mixed tone confuses users and weakens brand trust.
- Check NZ localisation Use "organisation" not "organise", "postcode" not "zip code", "cancelled" not "canceled". Check te reo Māori macrons: Āuckland not "Auckland" when used in te reo context.
| Element | What to check | Result |
|---|---|---|
| Page heading | Spelling, grammar, tone | Pass |
| "Contact us" button | Clarity, consistency | Pass |
| Error message | Helpful, not robotic | Fail — says "Error 400" |
| Footer legal | Placeholders, year | Fail — "Copyright 2023" |
| Address field label | NZ locale: "postcode" | Fail — says "zip code" |
Three defects found in five minutes. None were code bugs. All would have damaged trust if they reached users.
Scenario 2: Copy review on a financial app with brand and tone issues.
A NZ investment app is reviewing its dashboard messaging. The app uses a mix of formal institutional language and casual conversational tone, creating confusion about whether the product is trustworthy.
| Element | Current Text | Issue | Fix |
|---|---|---|---|
| Portfolio header | "Your investment portfolio performance" | Formal, institutional | Keep as-is (appropriate) |
| Balance summary | "You're doing great!" | Too casual for financial product | "Your balance: $50,000" |
| Loss indicator | "Oops, down 2%!" | Too flippant for negative outcome | "Down 2% this month" |
| Error on deposit | "Something went oopsie" | Unprofessional for financial context | "Deposit failed. Contact support." |
Mixed tone shakes user confidence in a financial product. Copy review caught this before it shipped. A single voice—either institutional or friendly—must be chosen and applied consistently.
5 When to Use It / When NOT to Use It
✅ Do it when...
- A new page or feature is ready for review
- A build contains UI text changes
- You are doing a final pre-release check
- The site targets NZ audiences
❌ Skip it when...
- You are testing pure back-end APIs with no UI
- The build contains only code logic changes
- You are in the middle of deep functional testing
Before you apply this technique, ask:
- Do you have access to the real content or at least a realistic mock-up (not Lorem ipsum)?
- Are you familiar with NZ locale rules and your company's style guide?
- Do you have time to read every visible word, or just skim key sections?
- Is this a public-facing page where tone and polish matter to trust?
6 Common Mistakes — Don't Do This
🚫 Assuming someone else checked
I used to think: The designer or product manager proofreads the copy.
Actually: Everyone assumes someone else did it. In most teams, no one does. The tester is the last line of defence. If you do not check it, it ships broken.
🚫 Only reading body text
I used to think: Typos only matter in paragraphs.
Actually: Buttons, error messages, empty states, and tooltips carry the most user-facing text. A typo in a button label is more visible than a typo in a paragraph. Read every visible word, not just the paragraphs.
🚫 Trusting spell-check alone
I used to think: If spell-check passes, the copy is clean.
Actually: Spell-check will not catch "form" when you meant "from", "pubic" when you meant "public", or "zip code" on a NZ site. It also misses tone, consistency, and locale errors. Your eyes are still required.
🚫 Reviewing placeholder or draft copy as if it were final
I used to think: I can spot-check copy in early builds even if it says "Lorem ipsum".
Actually: Placeholder text hides copy issues until final content arrives. Review the real copy, not draft mockups. If real content is not ready, defer copy review. Otherwise, you might miss locale errors, tone issues, or missing microcopy that only real content reveals.
When this technique fails
Copy review fails when you review without access to final, real content. If the page still contains placeholders or draft copy, your review will miss actual defects. Also fails if you do not understand the target audience's locale (NZ English, te reo Māori conventions). Copy review requires context; do not rush it on incomplete builds.
Senior engineer insight
The most dangerous copy defects are not typos — they are grammatically correct sentences that say the wrong thing. I once signed off a NZ government self-service portal where the error message on a failed identity check read "Your details could not be verified at this time." That is polite, spell-check-passing prose. What it should have said was "Your date of birth does not match our records — please check and re-enter." The first version sent users in circles for weeks. The second took 30 seconds to write once we understood the problem. That experience changed how I approach copy review: I now check whether each error message, tooltip, and empty state tells the user exactly what happened and exactly what to do next.
The most common mistake Grad testers make with copy review is treating it as a final polish pass — reading headings and buttons while ignoring error messages, empty states, and validation text, which is exactly where broken copy causes the most user friction.
From the field
On a contract for a Wellington regional council, the team assumed the content team had written all the user-facing text to the NZ Plain Language Standard — they had approved a content strategy document that said so. Three days before go-live, I did a systematic copy review pass and found 47 defects across 12 pages: "zip code" on four forms, "organisation" spelled four different ways across pages, a rates-payment button labelled "Proceed" with no indication of what would happen next, and — most critically — a privacy notice that still contained placeholder text reading "INSERT LEGAL COPY HERE" in 10-point grey font at the bottom of a consent screen. The council's legal team had not seen it because no one had run copy review on the consent flow. We pushed the launch by five days. The lesson that generalises: content strategy approval is not the same as content review. Someone still has to read every word on every screen before it ships.
7 Now You Try — Interview Warm-Up
Scenario: You are reviewing a sign-up form for an NZ tourism app. Spot the copy defects in this list:
- Heading: "Sign up for our newsletter"
- Button: "Submitt"
- Error: "Email is require"
- Label: "Enter your zip code"
- Footer: "Copyright 2023"
Write down every defect you can find before revealing the answer.
Defects found:
| # | Defect | Should be |
|---|---|---|
| 1 | "Submitt" | "Subscribe" or "Sign up" |
| 2 | "Email is require" | "Email is required" |
| 3 | "zip code" | "postcode" (NZ locale) |
| 4 | "Copyright 2023" | Current year or dynamic |
Tip: The heading is fine. The other four defects span spelling, grammar, locale, and placeholder issues. Four defects in five lines of text.
Why teams fail here
- Copy review is treated as optional: teams prioritise functional defects and treat copy as cosmetic, so text bugs ship to production unnoticed until a user or journalist spots them.
- No one owns it: developers assume the writer checked, writers assume the tester checked, product managers assume both checked — and the "Donte now" button reaches a live fundraising page.
- NZ locale rules are not documented: teams copy-paste forms from US or Australian templates and miss "zip code", US-spelling of "organisation", or missing macrons on te reo Māori words, because no one wrote down the rules in a style guide.
- Review happens on wrong content: testers review Lorem ipsum or draft copy in early builds, then assume someone will re-check when real content arrives — but that second review never happens and placeholder text ships.
Key takeaway
Users never read your code — they only read your words, so broken copy is a broken product, and the tester who reads every visible word before release is the last person standing between your organisation and a very public embarrassment.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Interview Questions
What NZ hiring managers ask about Copy Review at the Grad level.
Q1. What are you checking when you test copy on a web page?
Strong answer: Accuracy (does the copy match the specification or source material?), consistency (is the same term used everywhere, e.g., "Account" not sometimes "Profile"?), grammar and spelling (particularly for customer-facing text), readability (is it clear for the target audience?), and compliance (does it meet legal, regulatory, or brand requirements?). For NZ sites, I also check that any te reo Māori text is spelled correctly with macrons and that the meaning is appropriate in context.
Q2. You find a typo in a button label on a production website. How do you report it?
Strong answer: I raise a defect with: exact location (URL, page name, the specific button), what it currently says vs what it should say, a screenshot, and a severity rating. A typo on a main call-to-action button (e.g., "Sbumit" on a checkout button) is higher severity than a typo in a footer legal notice. I check whether the error is in one place or templated across many pages, because the fix scope changes the priority.
Q3. Why would a tester be involved in reviewing copy, not just functionality?
Strong answer: Incorrect copy is a bug — it misleads users, breaks trust, and can have legal implications. A form that says "Enter your Revenue NZ number" but actually expects your date of birth is a functional bug that only appears as copy. A terms-of-service page that says "you agree to being charged $99/month" when the price is actually $9/month is a compliance issue. Testers review copy as part of spec-vs-reality checking — the specification says X, the page says Y.
Q1. Why is a typo in a button worse than a typo in a paragraph?
Buttons are high-trust, high-action elements. A user decides whether to proceed based on a button label. A typo there looks like a scam or sloppy product. Paragraph typos are embarrassing; button typos block action.
Q2. What NZ locale error is common on forms copied from overseas templates?
"Zip code" instead of "postcode" is the most common. Also watch for "organise" instead of "organisation", "canceled" instead of "cancelled", and missing te reo Māori macrons.
Q3. Why should you read copy aloud?
Your mouth catches awkward phrasing that your eyes skip. If a button label sounds confusing when spoken, it will confuse users in silence too. Reading aloud is the fastest way to spot clunky microcopy.