8 UX Design Challenges with Connected Devices, Part 1
What is a Connected Device Experience?
The first “Connected Device Experience” I ever worked on was used for real-time traffic management. An embedded system processed video camera feeds from highways in and around the Minneapolis metro area trying to accurately measure traffic flow and predict impending congestion. The idea was to use machine vision and edge detection to count vehicles passing through a stretch of highway, then to compare traffic flow with previously measured days at the same time. Using an aggregate of data from many cameras, over time, one could detect localized congestion and predict additional congestion coming soon to a stretch of highway near you. The Minnesota Department of Transportation could then alter ramp metering and update traffic reports to encourage drivers to take another route.
What makes this a Connected Device experience? I was writing code to present a user interface on one system to remotely update and manage another system, which itself had no user interface. In my case, the UI allowed the system operator to draw a polygon to define the portion of the highway to be observed, to include perspective, time of day, latitude & longitude, and a relative bearing for the camera’s field of vision. I was a math student at the University of Minnesota, learning to code and use math at the same time. I was tasked with developing an algorithm to use the above inputs to assist the machine vision software in differentiating a moving shadow from a detected moving edge of real vehicle, providing a more accurate measurement.
Examples of Connected Devices
We think of a Connected Device as an electronic device that may operate independently and leverage cloud computing services, which is connected to other devices or cloud computing services via common networks. These networks include wired Ethernet and wireless networks such as Wi-Fi, Bluetooth, Zigbee, Z-Wave, et al.
Yes, technically, the laptop or phone you use to read this blog post is a Connected Device. But, from our perspective at KRUTSCH as Product Design Specialists, what really defines a Connected Device is something that may operate independently and leverage cloud services. They typically are purpose-built to provide a specific service or function for its end-users.
Examples include:
1. Internet of Things (IoT) Devices
This can include smart thermostats, lighting, door locks and garage door openers.
2. Wearables
Such as a foot pod (measuring running speed/distance) or a smart watch (like a Fitbit).
3. Vehicle Connected Experiences
OnStar and like services to connect your vehicle to your phone.
4. Urban Services
Rental transportation, such as Bird scooters, parking meters, toll system.
5. Enterprise Devices and Appliances
Commercial networking, storage area networking.
Readers of our blog know we like to tell UX design stories, so let’s jump into Part 1,A Story About A Problem.
Part 1, A Story about a Problem
There is no substitute for real-world user testing. Let me repeat that: there is no substitute for real-world user testing. You would think that after decades of designing software experiences, we could just design an app interface where nothing goes wrong or is confusing, everything is a joy to experience, and we are loved and respected for the effort.
One of our most venerable clients asked us to design a user experience for a series of smart energy connected devices. The short version is this: your home or apartment has meters to measure use of electricity, water, and (maybe) natural gas. These meters are equipped with low-complexity transceivers using a protocol called ERT (Encoder Receiver Transmitter (ERT) is a packet radio protocol developed by Itron for automatic meter reading. The technology is used to transmit data from utility meters over a short range so a utility vehicle can collect meter data without a worker physically inspecting each meter. – Wikipedia)
Now, wouldn’t it be fun if meter reading could be done over the inner-tubes, instead of having to send out trucks to cruise your neighborhood? There are other use cases as well, focused around making meter reading more continuous to assist with smart energy initiatives, like throttling your air conditioner during peak periods of electricity usage.
The Problem to Solve
The problem to solve? How to bridge ERT to the Internet. All we need is a box to collect the ERT packets from the meters in/around your home, transcode into IP packets, send to the home’s internet router, and Al Gore does the rest (https://www.snopes.com/fact-check/internet-of-lies/).
What Our Client Started With
Our client had already built the hardware and the embedded software – they are a hardware vendor, so naturally that is where they started:
- One little black box was an ERT Smart Energy Bridge, which captures ERT packets from your home’s water/gas/electric meters.
- The second little black box talks to the first black box, using a low-power radio and protocol called: Zigbee (Zigbee is an IEEE 802.15.4-based specification for a suite of high-level communication protocols used to create personal area networks with small, low-power digital radios, such as for home automation, medical device data collection, and other low-power low-bandwidth needs, designed for small scale projects which need wireless connection. Hence, Zigbee is a low-power, low data rate, and close proximity (i.e., personal area) wireless ad hoc network. - Wikipedia)
So, the two little black boxes work together to bridge your home utility meters to your home internet gateway. Sounds simple, right? Spoiler alert: we were awarded two US Patents for portions of our solution.
Here is what these boxes looked like (we’ve scrubbed client branding from the boxes and packaging).
Let’s highlight a couple of points from the photo:
1. The black boxes are sized like a common wall-wart (AC-to-DC power adapter) and look almost identical.
2. The “packaging mural” underneath the boxes and the Saran Wrap was the focus of one of our patents – more on this later.
High-Level Strategy
A big part of our engagement with the client was to teach their engineering teams to fish, so to speak. That is, to execute a User-Centered Design (UCD) process as part of pre-release user engagement and validation. The short-term goal was to build a working prototype for a next-generation device setup experience, with the following design principles:
- Transparent, error-tolerant device provisioning (setup the little black boxes);
- Establish reusable UX patterns for future product development;
- Develop a usability test-bed for early customer feedback;
- Acclimate engineering and product management to user testing procedures.
If you’ve already your fill of the UX Kool-Aid, these are well rehearsed talk-tracks.
Our Main Success Scenario (a buzz-phrase we like at KRUTSCH) was straightforward: Setup of the network for the little black boxes, get everything plugged-in and talking, and avoid support calls for anything except H/W failures. We’ve been doing UI/UX for Connected Devices for a long time and so we know this is always very, very difficult to do well.
Our Secondary Scenario: Visualization of the little black box network to clarify device topology and hierarchy. This translates into enabling the homeowner to understand how/why utility meter info gets to their iPhone.
Personae
We frequently tell clients that it’s deceptively easy to model users as a single faceless entity—“The User”—walking through a set of simple use cases, with one task-oriented goal in mind. However, that won’t generally reflect a user’s reality. In our experience, empirical discovery is the only good way to know your audience – your target customers. To characterize the people who will use the system, you need to go out and meet them! This project was to directly target consumer homeowners, so that was where we started.
The Software Stack
With the little black boxes completed, we then designed, built, and deployed a small prototype setup experience; a web service to serve up web pages that would be mobile-friendly, and support mobile phones, iPads, and lap/desktops. As it turned out, our test subjects ran the gamut with respect to devices used for the setup experience.
Web Setup on The Happy Path
We use the phrase ‘Happy Path’ to describe what we hope will be a typical experience, assuming the end-user is able to navigate the task list and everything works as designed.
For our prototype, respecting the limitations of the existing hardware and embedded systems, the ‘Happy Path’ looked like this:
Record MAC address of gateway (black box #1)
Connect gateway to router (i.e. plug-in the Ethernet cable)
Connect power supply to gateway (i.e. the wall-wort)
Verify the LEDs (i.e. observe a correct LED display pattern)
Record installation code for bridge (black box #2’s secret code)
Locate ERT meter (gas meter, as one example)
Record ERT type and ID values (from the gas meter’s placard)
Connect power supply to bridge (i.e. another wall-wort)
Verify the LEDs (i.e. observe a correct LED display pattern)
Yeah… simple… uh-huh. These were the required and necessary steps to get these devices to work together, correctly. And, remember that our personae are homeowners.
The test setup involved a simulated drop-ship of a small package from the homeowners local energy utility, with the included Quick Start Guide, as shown below, which was printed on the flip-side of the packaging mural, as previously described above.
Design Principles for Connected Devices
Design Principles vital to a good Connected Device experience include:
1. Discover, don’t Prompt – Trust but Verify
a. Make educated guesses and avoid data entry & mistakes.
2. Knowledge in the World is more accurate than Knowledge in the Head
a. Pre-select obvious choices, not lists to pick from.
b. We know what’s right or wrong; describe what’s happening and tell the user what to do next.
To acknowledge design principles vital to a good Connected Device experience, we asked for some changes to the embedded software on the little black boxes. We won’t bore you with the details, but the highlights included:
1. Gateway (black box #1) was modified to securely, automatically enable joining (i.e. Zigbee pairing with black box #2) which eliminated the indeterminate intervals for discovery/beaconing. In other words, make the system resilient to timing discrepancies.
2. Allow joining of little black boxes without a customer profile or account.
3. We never present the user with lists of discovered little black boxes; we present what appears to be the correct choice, and the end-user visually confirms.
In the end, the end-user should be able to simply plug everything in (power, ethernet), the little black boxes boot-up, and by the time the automated setup prologue completes, everything is discovered, joined and ready to go before end-user setup really starts the web-based setup experience.
FIELD TESTING PLAN
Like good UX’ers, we assembled an outline for a formal usability test. We would observe roughly ½-dozen users going through the setup procedure in their own homes. We would recruit homeowners for a baseline user study for out-of-box experience and setup.
We pretended to ‘drop-ship’ the packaging on the doorstep of each homeowner, then follow the user back inside with our clipboards, cameras, and tripods.
The user study goals were:
1. Understand the effectiveness of the setup experience.
2. Gain insight into a UX design for the more comprehensive versions.
3. Glean the end-user's expectations and observe first-hand what works and what doesn't.
And then… the wheels came off. It was like watching an old episode of “Cops” where the suspect is trying to outrun a pursuing squad car, riding on the rims, tires stripped away by spike strips, sparks flying in all directions.
End Note
In the next installment, 8 UX DESIGN CHALLENGES WITH CONNECTED DEVICES, PART 2, we outline those challenges within the context of our Internet of Things anecdote.
Follow us on LinkedIn to see the next article in your feed and to read the listicle you were hoping for when you clicked.
Ken Krutsch is Founder & President of KRUTSCH, a digital product design firm. From concept to delivery, KRUTSCH specializes in designing consumer and commercial applications. We generate and execute ideas, finding opportunities for our clients to innovate. Because solving the right problem builds careers, organizations and professional relationships.
Follow KRUTSCH on LinkedIn to read the follow-up posts in the series.
