CHECK LIST

Manual Pre-Launch QA Series 4/8

UI Matching Checklist

15 checks to clear before a multilingual manual ships

Published: August 2026 · Author: Hansem Global

Use this checklist to self-verify that a multilingual manual matches the shipping product: its UI, its physical buttons and labels, its on-screen messages, its part numbers, and its firmware version. It applies once manual translation, technical document translation, and user manual translation are complete. Run it in two stages, a self-check followed by an independent cross-check. Before you start, lock the baseline date fields in the sign-off record below.

  • Who this is for Technical writers, manual owners, localization PMs, QA staff, product UI owners, and manufacturers producing manuals with AI tools.
  • When to use it After the final firmware build is locked, right after per-language screenshots are produced, whenever labels, molded text, or part information change, and before final sign-off.
  • Use with The companion UI Matching Guide explains the rationale and application of each check.

These are the general, industry-neutral checks selected from the standards Hansem Global has built across 36 years of localization programs for global manufacturers. They do not replace a product specification, a release note, or market regulatory requirements.

Document and sign-off record

Baseline date (governs all comparison)Shipping firmware build no.
Product / modelDocument version / pub. date
Target languagesLaunch markets
Molded text / label drawing rev.Part number / box contents rev.
Self-check by / dateReviewer check by / date
Release decision☐ Approved: all 8 Grade A items closed at zero, baseline dates confirmed aligned
☐ Rejected: return for correction and re-verification

Severity grades

  • A Critical / mandatory Leads directly to a failed user operation, inconsistent safety information, incorrect certification data, or a launch delay. Must be zero at sign-off.
  • B Major / recommended A miss produces customer claims, higher support call volume, rework, and erosion of brand trust. Target zero wherever possible.
  • C Minor / supporting Low impact on its own. Accumulated, it drives quality variance between language editions and raises operating cost.
  • Before starting, pin the final firmware build, the per-language UI strings, the molded-text and label drawings, the part number list, and the manuscript to a single baseline date.
  • Work the items in grade order: A first, then B, then C.
  • Run two stages: a self-check, then a cross-check by someone outside the manual work.
  • Mark any item that does not apply as N/A and record the reason in Notes.
  • The 8 Grade A items must be at zero before the deliverable ships.

The 15 checks

Category A · Screenshots ↔ final UI
NoCheck and acceptance criterionGradeSelfRev.Notes
1Was every screenshot in the manual captured from the shipping firmware?
Look for captures left over from interim development builds or earlier versions. Compare screenshot capture dates against the shipping build date.
A
2Is the text inside each screenshot captured from that language’s UI build?
Confirm English UI screenshots have not been reused in non-English manuals. Capture from the per-language build.
A
3If the product has no multilingual UI, does the manual state that the UI is displayed in English?
Confirm the manual says so plainly, so readers do not assume they can change the display language. Wording and placement stay consistent across every language edition.
B
4Has personal and test data inside screenshots been scrubbed?
Prevent exposure of real user names, emails, phone numbers, account IDs, and location data. Confirm dummy data was used.
B
Category B · Molded text and physical labels
NoCheck and acceptance criterionGradeSelfRev.Notes
5Do the button, switch, and port names in the manual match the molded text on the product exactly?
Catch mismatches such as the manual saying POWER while the product is molded ON/OFF. Check icon markings the same way.
A
6Is the “product marking plus local-language gloss” convention applied consistently?
Where molded text is fixed English or a symbol and a gloss is needed, confirm the convention, for example POWER (Encendido), is uniform throughout.
C
7Do the position, wording, and pictograms of warning and safety labels match the manual’s safety section?
Confirm pictograms and signal words under ANSI Z535.6, ISO 3864, and ISO 7010 are synchronized between the physical label and the manual.
A
8Do the certifications the product actually holds match the manual’s certification page?
Confirm mark types, certification numbers (including the FCC ID where applicable), and marking format agree. Reconcile against the approved mark list from Part 3.
A
Category C · On-screen text ↔ quoted text
NoCheck and acceptance criterionGradeSelfRev.Notes
9Do alerts and menu paths match the firmware display character for character?
Once firmware strings are locked, compare every quoted string in the manual. Taking the firmware string resource files directly lets you verify down to words, symbols, and spaces.
A
10Are on-screen messages and the manual’s quotations written from the same translation basis?
Confirm a single shared glossary governs both, so firmware and manual do not render the same message two different ways.
A
11Do menu path notations (for example, Settings > Network > Connect) match the per-language UI menu names?
Confirm the per-language menu translation matches the manual, and that the path separator is used consistently.
A
12Is the quoting convention for buttons and menus (quotation marks, bold, brackets) consistent?
Confirm the same convention is applied throughout the manual.
B
Category D · Part numbers and barcodes
NoCheck and acceptance criterionGradeSelfRev.Notes
13Do the part numbers in the accessory list match what is actually in the box?
Confirm per-market differences in box contents are reflected, and that the manual describes the regional configuration accurately.
B
14Do the part numbers, barcodes, and QR data agree between product and manual?
Verify by scanning with an actual scanner and confirming the same data is returned. Visual comparison does not detect these errors.
B
Category E · Version and firmware sync
NoCheck and acceptance criterionGradeSelfRev.Notes
15Is there a change-control record covering UI, molded text, and manual changes?
Confirm the product-to-document change history is traceable in a single system. Record the requester, the date applied, and the list of affected language editions.
B

Findings summary

GradeChecksOpenClosedN/ASign-off rule
A Critical8Must be 0 to ship
B Major6Target 0. Log impact and fix plan
C Minor1Track and resolve in the next release

Frequently asked questions

  • If even one Grade A item is open, can we still ship? The rule is zero at sign-off. Grade A items are the ones where the document tells the user something the product does not do, or where safety and certification information disagrees. If you override the rule under deadline pressure, record the exception reason, the approver, the residual risk, and the remediation date in the sign-off record.
  • Do we run all 15 checks in every language? How long does it take? Run the 8 Grade A items in every launch language, with one exception: items 5, 7, and 8 (molded text, labels, certification) are judged against the physical unit and are language-independent, so they are checked once. What repeats per language is the screenshot and on-screen text work. For a 60 to 120 page manual, budget roughly one to two hours per language for the self-check.
  • What is the practical way to compare menu paths and on-screen messages in full? Get the per-language UI string resource files (.strings, .xml, .json) directly from the firmware team. Extract the quoted strings from the manual and diff them against those files, and you can verify words, symbols, and spaces by script. Transcribing from screenshots by eye cannot guarantee character-level agreement, and the error probability scales with the number of languages.
  • Firmware updates after launch. What happens to the manual? Establish the scope of the change first. If UI strings or the menu hierarchy moved, the affected screenshots and quoted text are invalid and every affected language edition has to be updated. Keeping the list of affected language editions in the check 15 change record makes that determination straightforward. Where printed copies are already in distribution, the usual approach is to update the online manual first and route users to the current version through a QR path.
  • Why are part numbers and barcodes part of UI matching? Because the user reads the box contents and the manual’s part information together. When per-market contents or QR data diverge, the wrong manual ends up in the box and distribution errors follow. As a product-to-document synchronization problem, it belongs in the same family as screenshots and molded text.

Pre-Launch QA Series for Multilingual Manuals (8 parts)

The series follows a multilingual manual from translation intake to market release, one gate at a time. Each part pairs a guide with a self-check checklist.

  • Part 1 · Translation integrity Catching defects in translated files before editing
  • Part 2 · DTP Multilingual typesetting and layout integrity
  • Part 3 · Regulatory Market-specific regulatory and standards marking
  • Part 4 · UI matching Synchronizing product screens with the document (this checklist)
  • Part 5 · Accessibility EAA, WCAG, PDF/UA, and Section 508 conformance
  • Part 6 · Multi-channel output Consistency across PDF, HTML, and mobile
  • Part 7 · Print Bleed, CMYK, font embedding, and print readiness
  • Part 8 · Data management Turning source files and TM into reusable assets