Start with an inventory, not a homepage read-through
A project can have polished page copy and still feel unfinished because a form error is confusing or a confirmation message uses an old product name. Interface text is easy to miss: it may appear only after a failed action, inside a menu, or in an email sent after someone leaves the site. Before proofreading, make a list of the places where people may encounter words.
Group the list by user journey rather than by file. For a contact flow, include the page heading, field labels, placeholder text, help text, validation errors, submit button, success message, and confirmation email. For an account flow, include sign-up, sign-in, password reset, empty states, and notifications. A student project may need only a short checklist; a small team may prefer a shared spreadsheet with a location, current text, proposed change, owner, and status for each item.
Ask whoever built the interface where text is stored and which states are difficult to reach. Copy may live in design files, a content management system, code, or an email tool. The inventory does not have to capture every string before review begins, but it should give the reviewer a way to notice gaps.
Review words in the interface where they appear
A document is useful for checking spelling and consistency, but it cannot show every problem. Open the working product or prototype and follow the same paths a visitor would. Click menus, leave required fields blank, enter invalid information, submit forms, and look at what happens when a search returns nothing. If a state is unavailable in the build, request a screenshot or a way to trigger it rather than approving unseen copy.
Read short strings alongside the controls they describe. “Continue” might be clear in one step and vague in another. A button label should help someone predict its action; an error should identify what needs attention and, when possible, how to fix it. Check whether a message promises an outcome the product does not actually provide. Review mobile and narrow layouts too: a phrase that fits on a desktop card may be cut off or awkwardly wrapped elsewhere.
Include text outside the main screen, such as browser page titles, image descriptions intended for assistive technology, download names, automated emails, and any handoff instructions the audience will receive. Which items matter will depend on the project, so use the inventory to set a clear review scope.
Proofread in separate passes
Trying to catch every issue at once makes small inconsistencies harder to see. First, check meaning: does the copy accurately describe the action, requirement, or result? Next, check consistency in names, terminology, capitalization, and tone. Finally, make a close pass for spelling, punctuation, missing words, and repeated words. Reading a screen aloud can expose sentences that sound natural in a document but feel too long in a compact interface.
Keep a short style note for recurring decisions. Record the preferred project name, whether buttons use verbs such as “Save changes,” and how common terms are written. For a freelancer, this might be a few lines attached to the delivery checklist. For a team, it can prevent different reviewers from making conflicting edits. Treat the note as a decision aid, not a reason to preserve wording that confuses users.
Be especially careful with similar messages. If one form says “Email address” and another says “Your email,” either may be acceptable, but the variation should be intentional. Do not change interface copy solely to make every string identical; context can justify different wording.
Record fixes so they can be checked
A useful proofreading comment identifies the exact location, the current wording, the replacement, and why the change matters. “Contact form, empty email error: replace ‘Invalid input’ with ‘Enter your email address’” is easier to act on than “Fix form copy.” Attach a screenshot when several similar messages exist. If the issue is a factual or product question rather than a typo, mark it for a decision instead of guessing.
Separate proposed edits from approved edits. In a collaborative project, one person may own the copy while another implements it. A simple status such as proposed, approved, implemented, and checked helps prevent a correction from being accepted in a comment but omitted from the final build. If wording changes after proofreading, review the affected flow again; a small label change can alter how an adjacent instruction reads.
Finish with a delivery-focused review
Before handoff, revisit the inventory against the version being delivered. Walk through the main journeys and the less visible states you flagged earlier. Check that agreed changes appear in the product, not just in a document, and note anything that remains unverified. A final pass is also a good time to remove draft labels, sample text, and outdated names.
Give the recipient a concise record of what was reviewed and any open items. For example, a small team might note that the contact form, account screens, and confirmation email were checked, while a notification triggered by an unavailable integration still needs review. This makes the limits of the proofreading pass visible and gives the next person a practical starting point.
