Regiscan
When I was on Cumberland Group’s IoT and Digital Platforms team, one of our first customers was a major temperature-controlled warehousing and transportation logistics company based in North America. We were hired to implement an IoT solution that consisted of a network of smart temperature sensors to replace the customer’s antiquated system of analog thermometers used to monitor the ambient temperature in their freezer storage warehouses.
- What I did: UI Design, UX Design, User Flows, Wireframing, High Fidelity Mockups
- Client: Cumberland Group / Internal
- Role: Primary UX Designer
Problem
During the engagement's first milestone, we were manually registering the temperature sensors into our data platform for each site deployment. This made the process incredibly clumsy because:
We might have been able to put up with these pain points, but this bottlenecked process wouldn’t be sustainable once we passed the site deployments on to external contractors for the subsequent milestones.
Solution
Regiscan was a mobile app that leveraged the phone’s camera to scan a device’s QR code and extract its identification number (ID) and serial code (SC) for use in device management tasks. Technicians would be able to use Regiscan to register devices, delete devices, and check on the status of a device to ensure data was being reported and connectivity levels were acceptable. Our goal was to improve the speed and efficiency of the site deployment process and for technicians to be able to perform site deployment tasks themselves.
Creating a better deployment process
After deploying a few sites myself, I had first-hand experience with how the bottlenecked process hampered an on-site technician’s capabilities to troubleshoot their own work. From those experiences, I distilled three pain points to tackle in the design of Regiscan:
Pain Points
Solutions
Sketching out paths for action
My early sketches emphasized the “scan” in Regiscan, relying on the user’s cellphone camera to scan a device’s identifying QR code to initiate various workflows. The intention was to keep the first step simple since the app had to be easy enough to use while wearing cold-weather gear.
But sharing these initial concepts with the engineers on the team made me realize my designs were a bit short-sighted. Because the sensors were part of an enterprise Platform-as-a-Service solution, there were several details I hadn’t accounted for, including:
I was so caught up in the novelty of building an app to solve the challenges that were immediately in front of me, that I hadn’t considered how it would work in the larger scale of managing devices in our data platform.
Guided device management
Getting schooled by engineering and mapping out user flows helped me think through how and when the app interface could require the user to provide necessary technical details for device management.
Create
When creating, or provisioning, a new device, the type of device determined the subsequent steps in the process, with sensors needing the extra step of being assigned to a gateway before registration. The “confirm & repeat” option would bring a user back to the beginning of the process with several of the fields, such as Site and Zone, pre-filled, speeding up the sometimes repetitive process of provisioning multiple devices.
Delete
Instead of using a numeric code to prevent unauthorized or accidental deletions, as explored in my initial sketches, I used a confirmation modal for when technicians needed to delete a device. This was much simpler and, while it wasn’t necessarily making the process any speedier, it didn’t require technicians to commit a code to memory.
Troubleshoot
Installing wireless sensors in massive warehouses meant that troubleshooting was an inevitability for technicians. For this, I wanted users to be able to check and confirm temperature data was being properly reported and connectivity levels were acceptable without having to rescan the device each time. A refresh button added to the end of the Device Details screen would allow users to manually re-query the status of a device instead of waiting the set interval for the devices to “phone home.”
Back to the drawing board
Learning about the technical requirements the engineers were accounting for led me back to the drawing board - literally. I added fields to the Create New Device screen for information like:
On the Delete Device screen I included the device’s site as a required field in the deletion process because I thought it would be a good idea to require the user to confirm where they were deleting the device from.
Based on my own experiences troubleshooting devices in freezer rooms that sometimes got down to -10°F, I had a pretty consistent idea of the information I wanted to be highlighted on the Device Details screen.
Polishing the details
Finalizing the UI design was, for the most part, a pretty straightforward line from sketches to blockframes to mockups, though I wanted to do my best to apply two lessons I learned early in the ideation process:
On the Create New Device screen, I opted for a dropdown menu to select the device type instead of the two check boxes seen in the sketches. Using a dropdown menu wouldn’t restrict device types to just gateways or temperature sensors and would allow us the option to include a variety of devices as needed.
To make the Device Details screen as informational as possible, I recreated the data visualizations that a user might see in our platform dashboards. Metrics like Average Temperature and Device Connectivity would provide technicians with even more critical information at-a-glance as they used the app.
With the exception of Battery Life, Last Check-in, and Last Error, I made all info fields full screen-width. Stacking all the details this way kept information easily scannable in top-to-bottom fashion and made the interface more modular, allowing for fields to be removed or replaced depending on the device and customer.
Last but not least, I added Asset ID, Area, and Zone as required fields to the Delete Device screen. These made certain that the user was aware of the unique device they were managing and served as additional safeguards against accidental device deletions.
Conclusions & Takeaways
Unfortunately, development of the Regiscan app stopped there. Scope creep and ballooning costs resulted in the whole customer engagement being prematurely shut down once the first couple of milestones had been reached. If I had the opportunity, I would have tested for three things:
Although it was disappointing to not get the chance to develop the app and use it in context, the experience wasn’t a total loss. I had the unique advantage of designing the app based on pain points that almost everyone on my team dealt with first hand and I learned about the importance of reconciling technical needs with intended UX outcomes.
