Designing IoT Experiences Within the Context of Available Data
When I wrote my post about “conversing” with my fridge penguin, I didn’t realize that it was going to be the first of two posts about the importance of considering context when designing an experience, especially when designing for the connected ones that will make up the Internet of Things. But, this past weekend I received a notification from my fitness tracker that made me reflect even more on this topic.
My fitness tracker and I have been together for almost three years. Well, not literally the same fitness tracker, as I have bought newer models along the way, but I have been loyally using the same type of fitness tracker since the summer of 2013. This past weekend I received a notification in the fitness tracker companion app telling me to “…take a deep breath. Maybe two.” My fitness tracker had noticed that my Resting Heart Rate was 15bpm higher than my monthly average, so this triggered the application to tell me to “Take a Deep Breath”. While I completely understood the mechanics of why this had happened, and understood why it’s a good idea to let people know that their heart rate is higher than normal, this message really bothered me. I was disappointed. I felt that my fitness tracker should have “known” better than to send a message that ended up feeling more patronizing than supportive, and here’s why:
You have my data…. so use it!
As I mentioned, my fitness tracker and I have a long-standing relationship. We have been together for over 5 million steps. I felt like we knew each other pretty well; at least I thought we did. My fitness tracker knows how often each week I work out and on which days. I know that it knows this because earlier in the week it had even told me that I had missed my usual Tuesday workout. I understand that my increased resting heart rate is a data point that my fitness tracker monitors and tracks and, in isolation, it makes sense to alert me about its increase. But it’s one data point in a sea of others that the fitness tracker has about me. So it disappoints me that someone on the tracker’s design team didn’t step back and look the broader context of the various metrics in combination with each other. An elevated heart rate, combined with a drastic change in established patterns of activity probably indicate something unusual is happening in that person’s life. And if this pattern change has been caused by something that is also bringing stress into their life (as indicated by the elevated heart rate), then telling them to “Take a Deep Breath” might come across as patronizing, and will not evoke the desired emotional reaction.
As more devices around us become connected, collecting all sorts of data about our patterns of behavior, our expectations of their IoT predictive learning and autonomous sense-making capabilities of the various devices with access to that data are going to rise. We are going to expect our devices to “know better” whether a device, or some combination in our personal IoT cloud, is actually that smart or not. And when those expectations aren’t met, we need to ensure there is a way to provide that feedback into the system.
Let me tell you when you are wrong
At theO’Reilly Design Conference, I thoroughly enjoyed Mike Kuniavsky’s talk “When the cloud decides: Designing for predictive machine learning for the IoT“ and a few points from his talk really came into focus in this situation with my fitness tracker. One of the three predictive system questions Mike talked about was control, and the question of how to adjust a system when you have no control. He went on to talk about various levels of automation with regard to sharing control and responsibility with algorithms. I hadn’t previously thought of my fitness tracker as a predictive learning system, but it is. Based on my activity and patterns, its companion app shows me different notifications and alerts, for example the notification about my elevated heart rate. For some of the alerts, the companion app has a level of automation which allows it to respond to data with an action if I approve. For example, the app might challenge me to make a certain step count, or go to bed by a certain time, and I can choose to accept or not accept these challenges, thereby setting expectations within the system. But that element of control is not persistent throughout the app, so it is selective in terms of how I can adjust the predictive behavior.
In that same talk, Mike outlined five design patterns for predictive learning systems, the fourth of which was “Create clear ways for people to adjust the predictive behavior.” So, if we go back to my fitness monitor example, the system was “correct” in its two separate data points: I had missed a workout on a particular day (and all subsequent “usual” workouts that week) and, several days later, I had an elevated resting heart rate. When the companion app told me that I had missed my “usual” Tuesday workout, the system provided me with no way to adjust its expectations for the rest of the week. So, although I knew I was not going to be following my typical pattern of behavior, I could not adjust the system’s expectations. In a well-designed system (adhering to the five patterns Mike outlined) I would have liked to have had a “give-me-a-break-it’s-a-rough-week” button which would have adjusted the system’s expectations of my behavior, and thus the notifications it would send me. Then, based on that adjustment, the notification about my elevated resting heart rate would have been delivered within the context of the system knowing I was having a rough week. The tone of that message would have been adjusted to be delivered in a way that would have been perceived as less patronizing and, therefore, would have elicited a more favorable response.
When I think about context, it is usually about the physical contexts of place and space of use. But, as this experience with my fitness tracker has shown me, with more and more devices being connected, and the pool of data about us growing, we are also going to need to start thinking more about context within the landscape of available data. With predictive learning becoming ubiquitous, we are going to expect the content delivered to us to just make sense based on our behavior and patterns of use. But, since life is never absolutely predictable, we need to ensure that we provide a way to also adjust the predictive behavior to reduce friction when things change. So don’t forget to consider the “give-me-a-break-it’s-been-a-rough-week” button.
Six Oversights to Consider Before Building an IoT Product
In this white paper, we outline six oversights that organizations face when entering the realm of IoT.