Electronic shelf labels can show a barcode or QR code that looks perfectly sharp to a person and still fail at the scanner. The reason is simple: human readability and machine decoding are different acceptance tests. A shelf template may preserve the right product ID but shrink the symbol too far, remove the quiet zone, resample it onto the e-paper pixel grid, or place it where glare, shelf angle, or scanner geometry makes decoding unreliable. For retailers using electronic shelf label product range, that turns a small content-design choice into a store workflow problem.
This guide explains how to design and validate electronic shelf label barcodes and QR codes as operational identifiers rather than decoration. It is aimed at retail technology teams, integrators, template owners, and procurement managers who need codes that staff can scan repeatedly during picking, replenishment, cycle counting, price checks, or label binding. The broader electronic shelf label solutions context still matters, but the scope here is deliberately narrow: symbol generation, rendering, placement, scanner behavior, and acceptance evidence.
Treat Scannability as a Measured Workflow Requirement
Start by naming the exact task. A staff member scanning a shelf identifier from 20 centimeters with an imager is not the same use case as a customer scanning a QR code with a phone from an oblique angle. The code type, physical size, expected distance, lighting, scanner engine, shelf height, and whether the label can be touched all change the design boundary. If these variables are missing from the requirement, a supplier can only prove that a code was displayed-not that the store task works.
A useful requirement therefore defines the expected reader, the data encoded, the normal and worst credible viewing positions, and the response required after a successful decode. The last item is often overlooked. A barcode that scans correctly but resolves to the wrong SKU is a data-integrity failure, not a display success. Keep the identifier chain traceable from master data through template rendering, label binding, wireless update, and the application that receives the scan.
| Decision item | What to define before design | Evidence to keep |
|---|---|---|
| Code purpose | SKU lookup, shelf location, picking action, product page, or maintenance ID | Approved workflow and data owner |
| Reader | Handheld imager, ring scanner, mobile device, or fixed reader | Exact test devices and settings |
| Geometry | Distance, angle, shelf height, label orientation | Photos and measured test positions |
| Rendered symbol | Symbology, encoded value, size, quiet zone, contrast | Native-resolution template export |
| Pass rule | Decode success under representative attempts and positions | Timestamped test sheet and exception log |
Choose Barcode or QR Code by the Task, Not by Habit
One-dimensional barcodes are efficient when the workflow needs a short identifier and the scanner can approach the label with predictable orientation. QR codes carry more information and tolerate rotation better, but their modules become small quickly when designers try to pack long URLs or rich payloads into a compact shelf label. On an e-paper display, that density matters because every bar or module has to map cleanly to a finite pixel matrix.
The price tag design guide already covers what information deserves space on a price label. For machine-readable codes, use a stricter rule: encode only what the task needs. If a QR code is intended to open a product page, use a controlled short URL or identifier rather than a long tracking string unless the longer payload has been validated at the actual rendered size. If a staff barcode only needs a location ID, do not consume pixels with extra fields that the receiving application can retrieve after decoding.
Render at the Label's Native Pixel Grid
A common failure is generating a symbol at one resolution and then allowing a CMS, browser, image editor, or label template engine to scale it again. Resampling can make some bars or QR modules one pixel wide and neighboring elements two pixels wide. The result may still look acceptable at normal viewing distance, but the scanner sees distorted proportions and uneven edges.
The safer production flow is to generate the symbol for the final pixel dimensions, preserve integer module widths where possible, and avoid last-stage interpolation. Treat the quiet zone as part of the symbol, not as optional white space that another content element may occupy. If the template supports multiple ESL sizes, validate each size separately rather than assuming a responsive layout preserves scannability.
- Generate the symbol from the authoritative identifier, not from a screenshot of another label.
- Render at the final label resolution or a controlled integer scale.
- Keep clear space around the full symbol on every template state.
- Do not place promotional badges, strike-through prices, or status icons inside the quiet zone.
- Recheck the symbol after localization because translated text can push or resize nearby objects.
Control Contrast, Background, and Refresh State
Machine-readable symbols benefit from a simple visual hierarchy: dark modules or bars on a clean light field with no decorative texture behind them. Accent colors and complex promotional backgrounds may be useful elsewhere on the label, but they should not force the scanner to separate the symbol from a noisy field. If a code uses an accent color supported by a particular display, validate that exact color and reader combination instead of assuming it behaves like black.
Also test the label in the display states that actually occur in stores. A freshly commissioned unit, a label after repeated content changes, and a unit viewed under strong aisle lighting may not look identical. The purpose is not to invent a universal refresh limit; it is to confirm that the chosen template remains decodable under the exact update mode and environment the project will deploy. If visual artifacts appear, compare a full refresh and the standard operational refresh before diagnosing the scanner.
Place the Code for the Scanner, the Shelf, and the Human
Mechanical integration can ruin an otherwise correct symbol. Holders can cover the code edge, deep shelf rails can shadow it, and a steep label angle can produce a poor camera view. The ESL mounting accessories guide is therefore part of scannability validation: test the production mount, not a loose label held in the hand.
For staff scanning, place the symbol where a hand can approach without moving products or twisting the scanner around a shelf lip. For customer-facing QR codes, check whether the code is still reachable on upper and lower shelves and whether the phone camera can focus without the user blocking the aisle. If two codes appear on the same label-such as a product barcode and a campaign QR code-separate them enough that the reader does not select the wrong symbol under normal aiming behavior.
Run a Scanner Matrix Instead of a Single Demonstration
A single successful scan proves almost nothing about fleet reliability. Build a small matrix that combines representative label sizes, code sizes, scanner types, shelf positions, and lighting. The matrix should include the smallest code you intend to approve and the most difficult normal geometry, such as a low shelf or a label mounted behind a protective lip.
| Test dimension | Minimum useful coverage | What a failure tells you |
|---|---|---|
| Label format | Small, common, and large ESL templates | Whether scaling rules are robust |
| Reader type | Primary store scanner plus approved fallback | Whether one engine is masking a weak symbol |
| Distance/angle | Normal use plus credible off-axis positions | Whether placement needs adjustment |
| Lighting | Normal aisle light and strongest expected local light | Whether contrast or reflections are limiting |
| Content state | Base price, promotion, multilingual, alert state | Whether template changes disturb the symbol |
| Update state | Commissioned and repeatedly updated examples | Whether rendering remains stable through normal operation |
Record failures as combinations, not anecdotes. "QR code sometimes fails" is not actionable. "Small ESL, lower shelf, phone camera, promotion template, high-angle scan" points to a controllable design or placement condition. That evidence also makes supplier conversations more productive because the problem is reproducible.
Troubleshoot in the Right Order
| Symptom | Check first | Likely corrective direction |
|---|---|---|
| No reader decodes the symbol | Encoded value, symbol generation, native pixel size, quiet zone | Correct the template or symbol generator before changing hardware |
| One scanner model fails | Reader configuration, supported symbology, focus/distance | Validate reader settings and approved device scope |
| Upper shelves work, lower shelves fail | Viewing angle, shadowing, holder geometry | Change label angle or code placement |
| Base template works, promotion fails | Object movement, code resizing, background overlap | Lock code dimensions and reserved region across states |
| Code scans but opens wrong record | SKU/location mapping and binding data | Fix master-data or binding controls; do not treat as a display defect |
| Intermittent after updates | Rendered image state and update completion | Compare endpoint image and update logs using the ESL update troubleshooting guide |
Make Data Integrity Part of the Acceptance Test
Scannability has two independent pass conditions: the reader decodes a symbol, and the decoded value points to the correct record. For a location code, verify the physical shelf position against the location master. For a product code, compare the decoded identifier with the label binding and the price record shown on screen. This protects against a subtle failure where the graphic is technically valid but belongs to a different SKU.
During rollout, sample both newly bound labels and labels that have been moved or re-used. Rebinding is a higher-risk moment because the device identity, shelf position, and product assignment can change together. Keep a simple exception path so staff can quarantine a label whose code scans correctly but resolves to conflicting data rather than improvising a manual correction.
Write the Requirement Into the RFQ and Template Specification
Procurement should ask for more than "barcode supported." State the required code types, smallest approved label format, intended reader classes, template states, and evidence expected during sample approval. The supplier should identify any constraints that depend on screen resolution, display technology, or software renderer. Use the product catalog only as a starting point for the exact hardware discussion; the final requirement must be tied to the selected model and project template.
- Provide native-resolution screenshots or exported label images for every approved size.
- Identify the symbol-generation component and how scaling is controlled.
- Demonstrate the code on the production mount, not only on a desktop sample.
- Test with the buyer's real scanner fleet or an agreed representative subset.
- Document how template changes are versioned and regression-tested.
- Define who owns a mismatch between decoded ID, bound SKU, shelf location, and displayed price.
FAQ
Q: Can an electronic shelf label display a normal retail barcode?
A: Yes, many ESL templates can render one-dimensional barcodes, but capability is not the same as guaranteed field readability. The symbol must be sized and rendered for the exact display resolution and validated with the intended scanners.
Q: Are QR codes easier to scan than barcodes on small labels?
A: Not automatically. QR codes tolerate rotation well, but dense QR payloads create small modules. A short payload in a well-sized QR code may perform better than a dense code, while a simple one-dimensional identifier can be more space-efficient for a staff workflow.
Q: Should the code be tested after every template change?
A: Any change that can alter code size, position, background, or neighboring content should trigger regression testing. Localization and promotion states are common reasons a previously safe reserved area changes.
Q: What should be saved as acceptance evidence?
A: Keep the template revision, rendered image, exact label model, mount, encoded value, test readers, test positions, pass/fail record, and any exceptions. That is enough to reproduce a failure later without relying on memory.
Govern Symbology Across Label Sizes and Store Workflows
A code that works on one label family should not automatically become the template for every form factor. Smaller shelf labels have fewer pixels, promotional labels may use a different orientation, and freezer or warehouse positions can change the scanning angle. Create a symbology matrix that ties each business task to the permitted label sizes, reader types, and payload rules. If a combination cannot preserve a stable quiet zone and usable module width, choose a shorter payload, a different symbology, or move the scan target to another label element rather than forcing the same artwork onto every device.
Template governance should also separate human-readable text from the machine-readable identifier. Printing the SKU or location ID next to the symbol gives staff a recovery path when a code is damaged or a scanner is unavailable, but the visible text must be generated from the same authoritative field. This prevents a common operational defect in which the printed text and encoded value diverge after a template edit or data mapping change.
| Governance item | Release question | Practical control |
|---|---|---|
| Payload source | Which system owns the encoded value? | Map one authoritative field and log transformations |
| Allowed symbology | Which code types are approved for each task? | Maintain a task-by-label-size matrix |
| Human-readable backup | Can staff confirm the value without decoding? | Render the same identifier as text where space allows |
| Localization | Can translated copy move or resize the symbol? | Lock the code zone and test longest-language templates |
| Exception handling | What happens when scanning fails? | Define manual lookup and defect reporting steps |
Regression-Test the Renderer, CMS, and Firmware Path
Scannability can change even when the business template appears unchanged. A CMS renderer update, font engine change, image compression setting, label firmware release, or new device resolution can alter the final pixel pattern. Treat the symbol as a regression-test object. Keep a small library of representative payloads, including short and long identifiers, edge-case characters allowed by the application, and the smallest approved physical rendering. After a software or firmware change, push those templates to real labels and repeat the scanner matrix instead of validating only a preview image.
When a regression appears after an update, compare the rendered endpoint state with the normal ESL update troubleshooting guide evidence path. The question is not only whether the label received the update, but whether the received bitmap still preserves the symbol geometry that passed the previous release. Store a screenshot or bitmap export alongside the reader result so engineering can distinguish data errors, transmission problems, rendering changes, and physical scanning conditions.
Use a Store Rollout Sampling Plan Instead of a Single Bench Pass
Bench validation proves that the design can work. A rollout sample proves that it still works in the store environment. Select shelves that represent high and low mounting positions, bright and shadowed aisles, common rail angles, refrigerator doors if relevant, and the reader models actually issued to staff. Include labels from more than one production lot when possible. The objective is not to manufacture a universal success percentage; it is to expose configuration-specific failure modes before the template is replicated across thousands of endpoints.
Record every failure with the label model, template version, encoded value, reader model, distance/angle condition, and whether a second attempt succeeded. A clustered pattern is more useful than a single pass/fail number. Failures only on one label size suggest a pixel-density or layout problem; failures only on one reader suggest scanner settings or optics; failures at one shelf angle suggest installation geometry. This evidence makes corrective action faster and prevents redesigning the wrong layer.
For rollout preparation, link the approved scan template to the physical placement rules in the ESL mounting accessories guide and to the deployment records maintained by the retail operations team. Teams evaluating a broader program can also review about LEGOYO, use contact LEGOYO for technical questions, and keep the approved workflow referenced from the LEGOYO homepage project entry point rather than distributing uncontrolled template copies.
Final Procurement Perspective
Electronic shelf label barcode and QR code support should be judged as a complete workflow: authoritative data, controlled rendering, physical placement, reader compatibility, correct record resolution, and regression evidence. That approach is more useful than a feature checkbox because it tells the store whether scanning will still work after real templates, mounts, promotions, and operational changes are introduced. Teams preparing a project can review the broader display solutions overview and LEGOYO technical blog resources, then use the request a project quotation process to discuss the exact label sizes, templates, scanners, and validation boundary required for the deployment.
