Regiscan

What I did: UI Design, UX Design, User Flows, Wireframing, High Fidelity Mockups
Client: Cumberland Group / Internal
Role: Primary UX Designer

Backstory

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. Due to upcoming regulatory changes in the US, the customer needed to replace their antiquated system of analog thermometers that was used to monitor the ambient temperature in their freezer storage warehouses. My team was hired to implement an IoT solution that consisted of a network of smart temperature sensors that reported temperature data back into a proprietary data platform.

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 a bit clumsy because:

Device management couldn't be done on-site

Each site deployment required at least two people to pull of

Installation technicians couldn’t work independently

We might have been able to put up with these pain points, but we knew this wouldn’t be sustainable once the process was passed on to external contractors.

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.

Define

Creating a better deployment process

After co-deploying a few sites, I learned first-hand how much this bottleneck limited 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

Engineering was responsible for all of the up-front work needed to register devices before a technician could even go on-site for a deployment.

Give the technician, aka the user, a way to register new devices while working on a site deployment

If a device failed or had to be re-registered, only the deployment admin overseeing the installation could delete it from the data platform.

Give the user a way to delete devices from the data platform so they could replace it with a new device or try re-installing it.

On-site technicians had to wait for confirmation from the deployment admin to know whether a device successfully connected to the platform.

Give users an easy way to immediately check the status of a sensor once it’s installed in its designated spot and turned on.

Ideation

Sketching out paths for action

My early sketches of the app prioritized simplicity, since the app had to be easy enough to use while wearing cold-weather gear, and hinged all subsequent user interaction on the initial act of scanning a device with the camera.

Relying solely on the camera to input device info was short-sighted and limiting should we ever offer sensor devices that didn’t have QR codes.

Using an authorization code to delete was not going to create a speedy and efficient experience.

But sharing these initial concepts with the engineers on my team soon made it apparent that I might have been focused a little too much on the "scan" in Regiscan. Because this was all part of an enterprise Platform-as-a-Service solution, I learned I wasn’t accounting for a slew of information that would need to be distinguished:

the variety of devices we wanted to provide
ingress/egress of data
and the (hopefully) many customers we'd eventually have on the platform

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.

Process

Mapping out user flows

Getting schooled by engineering and mapping out user flows helped me think through how and when the necessary technical details could be provided. In this example of the "create new device" user flow, the type of device determined the subsequent steps in the process, with sensors needing the extra step of being "assigned" to a gateway before they could be registered.

The "confirm & repeat" option would bring a user back to the beginning of the Create New Device process with several of the fields, such as Site and Zone, pre-filled, speeding up the sometimes repetitive process of provisioning multiple devices.

In the "delete device" user flow, I got rid of the admittedly bad idea of an authentication code and replaced it with a simple confirmation step. This was much simpler and didn’t require technicians to commit an authorization code to memory.

User flow for deleting (or de-provisioning) existing devices.

In the “device details” user flow I added a refresh button at the end of the process for users to re-query the status of a device while troubleshooting. Since devices “phoned home” to the data platform in set intervals, I wanted users to be able to continuously check for updates without having to rescan the device each time.

User flow for checking and troubleshooting the status of a device to ensure temperature data was being properly reported and connectivity levels were acceptable.

Iteration

Back to the drawing board

Learning about the technical requirements the engineers were accounting for via the user flow maps led me back to the drawing board - literally. I added fields to the Create New Device screen for information like:

Type of device: was it a sensor or was it a gateway the sensor connected to?
Zones: where in the customer site was the device placed?
If it was a sensor, what was its assigned gateway?
Sites, Areas, Tenants: Tenants corresponded to the customer on the platform, Areas corresponded to regions in the US, and Sites denoted the specific facility within a region.

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 at least require the user to confirm where they were deleting the device from.

A simple confirmation box still gives users a path to back out in the rare instance they accidentally deleted a device.

Based on my own experiences troubleshooting devices in freezer rooms that sometimes got down to -10°F, I had an idea of what I wanted to be immediately highlighted at the top of the Device Details screen. Consistent across multiple iterations of sketching out the information hierarchy were details such as:

The device’s battery life
The device’s check-in time
The device’s last error time

Original Sketch

Conceptual Iterations

Design

Polishing the details

The blockframe and mockup process was, for the most part, a straightforward translation of my sketches, though I wanted to do my best to apply two lessons I learned in my sketches:

Create an efficient user experience by being particular about what information I was showing the user and how I was presenting it.

Design the app in a way that addressed current needs but was also open enough to accommodate future versions of the solution offering.

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. It would also be much easier to use with bulky gloves on.

To make the Device Details screen as informational as possible, I recreated the data visualizations that a user might see in the desktop interface of our data platform solution. Statistics 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 time, and last error time, I opted to make everything full screen-width in the end. Stacking all the details this way would keep 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, below are my blockframes and mockups of the Delete Device screen. I took the information requirement a step further and decided to add fields like Asset ID, Area, and Zone. Including these as additional safeguards made certain that the user was aware of the unique device they were managing through the app.

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:

Is the user experience efficient?

Can the customer easily adopt the app?

Can the app be more informative at-a-glance?

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 some important lessons through the process, including:

Keeping layouts modular can accommodate future app iterations

Achieving UX goals should include meeting technical needs