- Notification design is important, especially in the light of ubiquitous computing.
- Designing to allow interrupted attention is crucial.
- Context matters: Users are no longer in a room at a desk on a computer.
With all the talk about unplugging, disconnecting, screen time, and going “off the grid”, there’s clearly been a shift in the way we interact with technology and the implications it has for society (as well as possibly our mental health). The National Day of Unplugging is dedicated to people spending ~24 hours (sundown to sundown) without engaging with technology under the premise of doing things like being more present, destressing, etc. While I could go on about how something meant to help us has become this burden of sorts, I’m more interested in the implications (from an experiential standpoint) of being forever-on.
I first noticed this subtle shift when talking to someone a few weeks ago on HipChat. I was in the middle of a conversation on my laptop and knew I had to step away from the computer for a few minutes, but I didn’t feel any need to notify my conversation partner about this. Two main reasons - 1) if it were actually all that important/crucial, I could always answer it on my phone, and 2) the message wasn’t going anywhere so if I got back to him immediately or within the next 5-10 minutes, it didn’t really make a difference.
I’ve noticed an almost identical interaction pattern with Facebook Messenger. I no longer worry whether or not the person is there, nor do I feel the need to alert others of my status. In fact, most of my conversations via FB happen over the course of hours, days, even weeks at a time. The transparency of status is completely irrelevant to our interaction because we both know the messages will be there if and when the other party gets around to responding.
Of course, there are drawbacks to this. Everybody knows the dread associatied with the assumption that, because you have a smartphone/phone/computer/laptop/tablet/smartwatch/whatever, that you can be reached any day, any time, and that creates this obsessive need to have notifications turned on for everything. The problem gets worse as we move into more-ubiquitous forms of computing, such as wearable technology.
This past weekend at Madison+UX, Philip Likens gave a talk about wearable computing, mentioning that he’s abandoned most of his wearables due to notification overload. In (roughly) his own words, having his phone, his watch, and his Google Glass all vibrate simultaneously any time anything happened became a little overwhelming. So now, instead of having some sense of what’s going on, he doesn’t even carry his phone on his person - totally shut off.
I’m inadventently running the same experiment - I put my phone on silent for the conference (due to the exorbitant amount of Twitter notifications I was getting) and I simply forgot to put it back on vibrate for the first day or two. What I realized is that I spent less time on minor distractions (increasing my overall flow), and I only checked the phone when I wanted to. It was back to on-demand instead of being always on, and it’s really refreshing.
So what does this mean to us as Experience Designers? A few things:
- Be mindful of the perceived status for your users. Do they know their status? Does your service need a smartphone app? A watch app? Do they all need to sync between each other? What about notifications? What’s important enough to potentially disrupt someone’s train of thought?
- Given all of that, understand the context your users will be in. If you’re allowing them to do all of these different things in all of these different ways, how does the context of their interaction change if it’s on a computer versus a phone versus a watch?
- Is your interaction temporally bound? Can they pop in and out multiple times over the course of a day, a week, a month? Does it have to happen now?
- What’re the implications of your product/service as wearable computers become more ubiquitous? What types of notifications can you design? Apply Laban Movement Analysis to technology.
And of course many more.
All User Experience posts: