Creating perfect labels is an iterative process.
Ask anyone that has ever built a custom barcode label. Even though there are numerous WYSIWYG (What You See Is What You Get) label development tools available on the market, they all seem to suffer from the same fatal flaw: there are always subtle differences between what the label designer shows on the screen, and what the label printer produces on paper.
There are always subtle differences between what the label designer shows on the screen, and what the label printer produces on paper
This often leads to expensive “pixel pushing” by software developers, or worse: costly delays when issues aren’t discovered until labels are filled with real data.
Imagine the following scenario:
You’re in the midst of on-boarding a new strategic trading partner when you discover that this trading partner requires all inbound pallets to be labeled in a very specific manner (to ensure proper induction into their conveyor system). This means you’ll need to develop a custom shipping label in order to meet compliance.
The shipping label they’ve requested has a barcode to the left of some text. The barcode needs to be large enough to be scanned from a distance, but small enough so that it doesn’t overlap the text to the right.
Your software developer begins building the label template based off the sample your trading partner provided. In the label design tool, everything looks great. The barcode modules are thick enough to fill the space, and the barcode does not appear to be overlapping any other fields:
Since this software developer is working remotely, he doesn’t have access to an expensive direct thermal printer with which to test his label, so he finishes integrating the label with the WMS and submits his work for review.
A couple weeks later, the label is finally tested in a QA environment and a physical label whirs out of the label printer in the shipping office. To everyone’s dismay, there is one fatal flaw: the barcode overruns the text fields to the right and is totally unscannable:
Now, the label is sent back to the developer for rework. Depending on his workload and competing priorities, it may be another few weeks before he can address the defects and submit a new version for review. This vicious cycle ends up looking something like the following:
- Developer creates the label template in the label designer
- Developer positions and sizes fields according to the customer requirements
- Developer exports label to a format compatible with the printer(s)
- Developer or sysadmin integrates the Printer Object File into the WMS
- QA Analyst tests the label with live data and a live printer
- QA Analyst retrieves the label from the live printer
- QA Analyst scans or photographs label and sends it back to the developer for review
- Repeat steps 2-7 until an adequate solution is achieved
Throughout the testing process, physical labels are being handled/exchanged, buttons are being pressed, hardware resources are being consumed/shared, and employees are walking to and from the hardware and their desks, often passing their coworkers multiple times en route. All of these steps have been shown to facilitate the spread of bacteria, viruses, and respiratory illnesses (such as COVID-19).
Throughout the testing process, physical labels are being handled/exchanged, buttons are being pressed, hardware resources are being consumed/shared, and employees are walking to and from the hardware and their desks, often passing their coworkers multiple times en route
Fortunately, with LabelZoom, all of these steps can be avoided.
One of the many features that makes LabelZoom unique is its real-time preview functionality. Rather than printing a label to a physical printer, the developer can generate an accurate preview of the label on their workstation and rectify any sizing/positioning issues before delivering their work to another team. This “shift left” testing methodology is growing in popularity because of the numerous benefits it brings to the Software Development Lifecycle (SDLC).
Below, we use LabelZoom to generate a preview of the same label. We can edit the data in real time to validate field positions against known data sizes. With this instant feedback loop, we’re able to spot the defect much sooner than we could previously:
A quick tweak to the barcode’s module width and we can see that the barcode now fits perfectly within the bounds allotted:
Summary
In summary, a multi-week process was just condensed into a matter of seconds, and there were far fewer touchpoints in the process. We significantly reduced the amount of time taken, as well as the number of germs spread, and it’s all thanks to having better tools.
If the only tool you have is a hammer, it’s hard to eat spaghetti.
David Allen
A good tool improves the way you work. A great tool improves the way you think.
Jeff Duntemann
