LAN-Based Installation of USB-Only Postage Meter
Nature of product/system: Postage meter and LAN connectivity device used by small businesses
Persona: Small business owners and employees
Stage at which I joined the project: Project kickoff
My role: All UX design and research, plus instructional design
Type of research: Formative and summative, qualitative and quantitative usability testing
Research Technique(s): In-person usability testing, in a lab and on-site settings
What was the problem?
Pitney Bowes needed to add LAN and WiFi connectivity to a postage meter that was originally designed to communicate via analog modem. The UX challenge was to create unboxing procedures and instructions that enabled non-technical users to successfully install the meter via a USB-to-LAN device (named the Communication Device). The company did not want to charge customers for the Communication Device, so the chosen device was:
Inexpensive
Not error tolerant
Had no inherent user interface.
Numerous additional UX challenges:
The display on the meter had only two-lines of 20 characters.
Project management insisted on giving users the choice of Ethernet cable or WiFi connectivity during installation.
Though the meter users had minimal technical expertise, project management was unwilling to direct users to have their IT consultant do the installation unless users experienced serious network errors during installation.
What were the stakeholder assumptions?
Users would be able to navigate the choice of wired versus WiFi connectivity.
Small business employees would be able to follow software-presented instructions to install the Communications Device, regardless of how their office’s network was set it up.
Users would understand the relationship between the installation procedures for the Communications Device and the procedures for the meter.
The status of the Communications Device could be communicated to users by the color and blink pattern of the three LEDs in its RJ45 port.
The connectivity status of the meter could be adequately communicated to users via its two-line by 20 character display.
Which method(s) did you choose and why?
Given the product was a physical device, in-person, moderated usability testing was the appropriate technique. When it was time to learn about the variations among customer networks, we switched to testing at customer sites.
Did it work? If not, what would you do differently next time?
Six iterations of instructions and firmware, and 64 test sessions (55 at customer sites) were needed before users’ success rate reached an acceptable level.
How were your recommendations tied to both user and business value?
Analog phone lines were becoming obsolete. It was a business imperative to enable Internet connectivity for this product, or it would not be salable.
How was your research received?
The development team resisted the initial test results. They believed if users “Followed the directions,” they would succeed. Since we needed to learn the array of networks the device must accommodate, I began taking the lead software engineer with me to customer sites.
After the second test session, he realized I wasn’t exaggerating the complexity of the process and how unprepared users were to navigate it. Almost immediately, he became an advocate for UX among the team members, insisting on significant changes to the firmware to make it more error-tolerant.
Even with this, it took three additional iterations to create firmware and instructions users could complete successfully. Without this team member’s change of heart, the project would never have had a chance at success.
How did your results bring impact?
We were able to reach the objective of transitioning the product from inevitable obsolescence to viability until a replacement that was Internet-ready could be developed.