When most support teams think about localizing their help center, they immediately focus on the words – article titles, body text, navigation labels, and metadata. The localization checklist gets checked off, the translated text gets imported, and the project is declared done. But log in as a French or Japanese customer, and you will often find something jarring: help articles written in the correct language, sitting right next to screenshots, diagrams, and annotated visuals that are entirely in English.
This is the hidden gap in most help center localization strategies. Visual content is not decorative. In a support context, it is often the most critical part of the entire article. A customer trying to find the “Settings > Billing” menu follows the screenshot, not the text. When that screenshot shows UI labels that don’t match what they see on their screen – because they are using the French or German version of your product – the entire article fails its purpose, regardless of how accurate the translated prose is.
This article dives deep into the overlooked discipline of visual localization: why it matters, what types of visuals require attention, how to build a repeatable workflow for translating and replacing image assets, and how modern tools are making the process scalable for teams that don’t have dedicated design resources for every locale.
Why Visual Localization Is Non-Negotiable
Before exploring the how, it’s worth building the case for why. Many teams deprioritize image localization because it seems expensive and complex compared to text translation. That instinct is understandable but costly.
Screenshots Are Your UI’s Ambassador
For SaaS and software products, help center screenshots serve as a real-time representation of what the product looks like and how it behaves. When you localize your product UI – and most modern software products do localize their interface – your screenshots become immediately outdated in every language except the one they were captured in. A German customer using a German UI who sees an English screenshot of a dialog box is now navigating a disconnect between their real experience and the documentation’s visual guide.
This mismatch creates a specific and measurable support problem: ticket deflection fails. The customer either files a ticket asking where a button is, even though an article about it exists, or they follow the wrong steps because the visual reference confused them.
Diagrams and Illustrations Carry Embedded Text
Diagrams explaining workflows, architecture illustrations, process maps, and annotated product walkthroughs almost always contain embedded text. Labels, callouts, arrows with descriptions, and step numbers are baked into the image file itself – often as flattened raster graphics, not editable vector layers.
When these images aren’t localized, customers see professionally translated prose interrupted by English labels, technical terms, and UI descriptions. The inconsistency doesn’t just affect comprehension – it signals that your product was designed with certain markets in mind and others were an afterthought.
Cultural and Contextual Relevance
Beyond language, visuals carry cultural meaning. A photograph of a team collaborating in an open-plan American office may communicate “modern company” in some markets and feel foreign or irrelevant in others. Currency symbols in screenshots ($, £, €) tell customers whether the pricing shown applies to them. Date formats, measurement units, and phone number structures embedded in UI screenshots can all trigger confusion or distrust.
True visual localization addresses all of these dimensions – not just translated text labels, but culturally appropriate imagery and contextually correct examples.
A Taxonomy of Visuals That Require Localization
Not every image in your help center requires the same localization treatment. Understanding the categories helps you prioritize effort and apply the right workflow to each type.
1. Product UI Screenshots
These are the highest priority. Screenshots of your product interface become outdated when:
- The product UI is localized and shows different labels in different language versions
- Product terminology changes (a renamed menu item, a restructured settings page)
- Your UI design updates visually (new icons, layout changes, color scheme)
Every localized help article that includes a screenshot should have a locale-specific version of that screenshot captured from the localized version of the product.
2. Annotated Screenshots
These are screenshots with added callouts, arrows, boxes, or numbered labels applied in a design tool. They are more complex to localize because the annotations themselves contain text that is separate from the original screenshot. Localization requires:
- Accessing the original editable design file (Figma, Photoshop, Sketch)
- Translating annotation text
- Re-exporting the localized version
When teams don’t have access to original source files, they’re forced to either skip annotation localization or rebuild the annotated image from scratch – both poor outcomes.
3. Diagrams and Process Flows
Workflow diagrams, architecture maps, and process illustrations typically contain embedded text explaining each step or component. These are often created in tools like Lucidchart, draw.io, or directly in design software. The localization challenge is that text may be part of the image layer structure, requiring the original editable file to modify.
4. Video Thumbnails and GIFs
Increasingly, help centers include video walkthroughs and animated GIFs demonstrating product behavior. These require separate localization consideration: subtitles or captions for video, and replacement frames or re-recording for GIFs where on-screen UI text is central to the demonstration.
5. Infographics and Marketing-Adjacent Visuals
Some help centers include infographics explaining pricing tiers, feature comparisons, or onboarding journeys. These are often the most design-intensive to localize but are also the most visible and brand-relevant. Text is typically heavily embedded and requires significant design work to adapt.
The Core Localization Workflow for Visual Assets
Building a repeatable workflow for image localization requires thinking about three phases: preparation, translation and editing, and deployment.
Phase 1: Preparation – Set Up for Localizability
The best time to make visual localization easy is when you create the source assets. Retroactively localizing a library of flat PNG screenshots is significantly harder than localizing assets that were designed with localization in mind.
Best practices for source asset creation:
- Maintain editable source files for every image. Store Figma, Sketch, or Photoshop source files alongside every exported PNG or SVG used in your help center. Without the source files, every localization requires reverse-engineering the original layout.
- Use text layers, not rasterized text. When annotating screenshots in design tools, always keep annotation text as live, editable text layers – not merged or rasterized into the image. This allows translators to edit text without touching the design.
- Name layers semantically. Use descriptive layer names that help translators understand context without having to reference the article (“billing-menu-label,” “navigation-arrow-step-2”). This speeds up the handoff process dramatically.
- Separate text from visual elements. In diagrams and illustrations, isolate text labels on dedicated layers or groups. This makes it possible to export a text inventory for translation without modifying the visual design.
- Build a screenshot naming convention. Use systematic filenames (product-name_feature_locale_version) so localized variants can be stored, tracked, and updated without confusion.
Phase 2: Translation and Editing – The Practical Handoff
Once source files are organized, the localization workflow for visual assets typically follows these steps:
Step 1: Asset Identification and Export
Your localization project manager or content team generates a list of all images in articles scheduled for a given locale. Each image is reviewed to determine its type (screenshot, annotated, diagram) and whether it contains text requiring translation.
For screenshots of the product UI, the most efficient approach is recapturing them directly from the localized version of the product. Assign a team member with access to the target-locale version of your product – or a staging environment set to that locale – to take fresh screenshots using a standardized screen resolution and zoom level.
For annotated images and diagrams that cannot be recaptured, export the editable source files and the original exported images. Package these with a translation brief that includes:
- The text strings that appear in each image
- Context notes explaining what each label or annotation refers to in the product
- The target language and any glossary terms that apply
- The required output format and dimensions
Step 2: Translation and Design Edit
Translators and designers work together or sequentially, depending on team structure:
- A translator handles the linguistic content – translating annotation text, label strings, and callout descriptions.
- A designer takes the translated strings and edits them in the source design file. This requires awareness of text expansion: German strings, for example, can run 30-40% longer than their English equivalents, which may require resizing callout boxes or adjusting layout spacing.
- For markets with non-Latin scripts (Arabic, Hebrew, Chinese, Japanese, Korean), the designer must also verify that the font used in the design supports the target script and that right-to-left text direction is correctly applied where applicable.
The designer exports the finalized localized image in the same format and dimensions as the source asset.
Step 3: Quality Review
Before uploading, every localized image should go through a brief review:
- Does all text in the image match the translated strings exactly?
- Is the text legible at the display size used in the help center?
- Does the annotated layout still make sense with the longer or shorter translated strings?
- For product screenshots: does the UI shown match what a user in that locale actually sees in the product today?
Step 4: Upload and Article Association
Localized images are uploaded to the help center platform and associated with the correct article and locale. Managing this complex process is much easier when your translation platform integrates directly with your CMS. The Crowdin app for Zendesk localization, for example, has a specific feature to handle image assets seamlessly, allowing teams to manage localized image versions alongside article text in a single workflow without manual file uploads for each locale separately.
Tooling: Making Visual Localization Scalable
The manual workflow above works for small-scale or initial localization projects. For teams managing dozens of locales and hundreds of articles, scalability requires tooling support.
Design Tool Integrations
Figma plugins like “Crowdin for Figma” or similar integrations allow translators to work directly within design files – editing text layers in the Figma environment and exporting translated variants without requiring design expertise. This collapses the translation and design editing phases into a single step.
OCR-Based Text Extraction
For existing screenshot libraries where editable source files are unavailable, OCR (optical character recognition) tools can extract embedded text from images automatically. This generates a text inventory for translation without manual transcription. Once translated, the strings can be reapplied using a template-based approach – though this works better for simple annotations than complex diagrams.
Automated Screenshot Capture
For products with localized UIs, automated screenshot tools can recapture images in each supported locale without manual effort. Tools like Percy, Chromatic, or custom Selenium scripts can navigate to specific product pages in each locale setting and capture standardized screenshots at predefined viewports. These can be integrated into CI/CD pipelines, so screenshots update automatically when the product UI changes.
Translation Memory for Visual Context
When translators work on annotation text, they benefit from translation memory just as they do for article text. String-level TM means that if “Go to Settings” appears as an annotation label in 15 different screenshots, it only needs to be translated once. All subsequent instances are pre-filled from memory, ensuring consistency across the entire visual library.
Handling the Most Common Visual Localization Challenges
Challenge 1: Text Expansion in Callout Boxes
German, Finnish, and several other European languages consistently produce longer strings than English. A callout box sized for “Click here to proceed” may overflow with the German equivalent. Solutions include:
- Build callout boxes with overflow padding in the source design
- Use abbreviations or shortened phrasing agreed upon with the translator
- Resize the callout box in the localized version while maintaining visual proportion
Challenge 2: Right-to-Left Layout for Arabic and Hebrew
RTL languages don’t just require text direction changes – they often require mirroring the entire visual layout. An annotated screenshot with callout arrows pointing left-to-right may need to be flipped entirely for Arabic, with arrows and labels repositioned accordingly. This is significant design work and should be planned explicitly in RTL localization projects.
Challenge 3: Font Support for Non-Latin Scripts
Fonts chosen for English or European-language designs often don’t include glyphs for Cyrillic, Arabic, CJK, or other scripts. When text is edited in a source design file for these locales, the result may display as blank squares or default system fonts that clash with the original visual style. Always verify font coverage before beginning design editing for non-Latin locales.
Challenge 4: Currency and Regional Data in Screenshots
Screenshots of pricing pages, invoice examples, or billing interfaces may contain hard-coded currency symbols, country-specific tax rates, or example data that is inappropriate or misleading in other markets. These screenshots should either be recaptured using locale-appropriate staging environments or carefully edited to replace regional data with neutral placeholders.
Challenge 5: Keeping Visuals Updated as Products Evolve
Localized images become outdated just as quickly as source images – sometimes faster, because they receive less maintenance attention. Build a visual asset inventory that records the product version or date associated with each screenshot. Include visual asset reviews in your regular content audit cycle, and flag localized images for update whenever a corresponding source image is refreshed.
Building a Style Guide for Visual Localization
Just as text localization benefits from a style guide, visual localization should be governed by documented standards. Your visual localization style guide should cover:
- Standard screenshot dimensions and zoom levels for each help center article type
- Annotation style (callout shape, arrow style, font, color codes for each locale if applicable)
- Naming conventions for localized image files
- Cultural image guidelines for each key market (photography direction, example user profiles, UI demo data)
- Font specifications for each script and locale
- Layout rules for text expansion (minimum padding, maximum text density per callout)
This guide becomes the reference for anyone creating or updating visual assets across your localized help centers, ensuring consistency regardless of who does the work.
Measuring the ROI of Visual Localization
Like all localization investments, visual localization should be tied to measurable outcomes. Key metrics to track:
- Ticket deflection rate by locale: Are customers in localized markets resolving issues through self-service at rates comparable to your English-speaking base? If not, visual inconsistency may be a contributing factor.
- Time-on-page for help articles with vs. without localized images: Customers who encounter English images in otherwise localized articles often have shorter, less productive sessions.
- CSAT scores for support interactions that referenced help articles: Agent-assisted resolution is more satisfying when the article being referenced actually matches what the customer sees.
- Search ranking for localized help content: Alt text and image context signals contribute to search performance in local-language SERPs.
FAQ: Localizing Images and Visuals in Help Centers
Do we really need to localize screenshots if our product UI is already translated?
Yes. Even if your product UI is fully localized, help center screenshots capture a specific state and version of that UI. Screenshots taken from the English version of your product will show English labels, even when your German or Spanish customers are using a different interface. The documentation must match the interface the customer actually sees.
What if we don’t have access to the original editable source files for our diagrams?
Start by building that archive going forward for all new assets. For existing images without source files, prioritize the highest-traffic, highest-impact visuals first and recreate them with editable source files as a foundation. For lower-priority assets, consider whether they can be replaced with simpler alternatives (text-based steps instead of annotated diagrams) until proper source files are available.
How do we handle screenshots when the product UI updates frequently?
Build screenshot updates into your product release process. When a UI change affects documented workflows, flag all related screenshots for recapture across all locales. Automated screenshot pipelines (using Selenium or similar tools) can recapture locale-specific screenshots automatically when product code changes, dramatically reducing the manual maintenance burden.
How should we handle images that contain sensitive data like names or emails?
Always use fictional but culturally appropriate placeholder data in screenshots. For localized versions, ensure placeholder names, emails, and company names are appropriate for the target culture. A help article demonstrating an email integration that shows “John Smith at Acme Corp” should use culturally relevant names in Japanese, Arabic, or Brazilian Portuguese versions – this small detail contributes significantly to how native the documentation feels.
Is it worth investing in visual localization for markets where our product isn’t yet fully localized?
Even for markets where your product UI remains in English, localizing help center visuals is still valuable. Translated article text alongside English screenshots is better than nothing – but mismatched visuals should be noted clearly (for example, “Screenshots show the English interface; menu locations are the same in your language”). As product localization progresses, help center visual assets can be updated to match.
How do we manage version control for localized image assets?
Use a digital asset management (DAM) system or a structured folder system within your existing file storage that links each localized image to its source version and the article it belongs to. Record the product version or date when each screenshot was captured. Include image asset reviews in your quarterly content audits. When source images are updated, flag all locale variants for review and update.
