We made a lamp. Why?
For one, we like making things—sometimes just for the sake of making things. But this lamp was made to explore one of the many connected home hypotheses we’ve been wrestling with lately. Specifically, we wanted to address the unnecessarily large gap that exists between interacting with a connected product via its physical affordances and interacting with it via a mobile app. We’ve found ourselves hunting through an app to manipulate a nearby lamp and we think that’s silly.
Because we believe the design of all beloved products—for the connected home or otherwise— starts with the product’s most fundamental, common use case, we first focused on how someone would turn our lamp on and off without their phone. So, our lamp turns on and off with a simple, pleasant touch.
We designed a connected lamp to rethink the way we use our smartphone in the connected home. The primary interaction with this lamp is a physical touch.
While this interaction allows quick access of the lamp’s basic functionality, the more advanced attributes (i.e. color control) are accessible through a smartphone app. instead of requiring people to hunt through the hierarchy of an app to fine tune the qualities of a single lamp, one can simply tap their phone on the lamp to fine tune its attributes. In other words, we’ve designed a deep link to a particular lamp based on a particular context.
For more advanced control, the phone simply has to be tapped against the lamp to bring up the app interface.
This “tap-to-tweak” behavior seems to work well for our lamp, and we feel it can scale nicely across other connected products. It can surface the range of settings that are too complex to be manifested in hardware but are not quite heavy duty enough to warrant diving deep into an app. For designers, it also creates an alternative to putting a screen on the connected device by using the screen in your pocket.
Tap-to-tweak can be used for various connected devices (sketches by Christina Wolf)
This might seem like more high geekery from the already-too-geeky world of smart home products, but we think this actually begins to address a significant issue that prevents wider adoption of connected products. This issue is rooted in there currently being basically two ways—a false dilemma—of interacting with the connected home:
- Traditional, direct interaction, like turning on a light with a physical switch.
- Less familiar, indirect interaction, like setting up an automation program of a group of lights with a smartphone app.
More often than not, most members of a household are either uninterested or incapable of managing the connected home ecosystem. This does not mean they don’t want to tweak the light of a connected lamp or change the schedule settings of a coffeemaker. Nonetheless, they are left with basic, direct control, because adjusting individual attributes of a product are stashed in an app alongside other more expert features.
As a result of this disconnect, it is common for a member of the household to be deemed IT admin of the home, left to manage smart home administrivia (yuck). Or, the connected products are eventually ignored/retired/rejected by the household. In bridging direct and indirect interaction, this separation between person and product is made less. It also flattens the odd, enterprise-like control schemas that often arise in a connected home. In these ways, we believe tap-to-tweak helps humanize the connected home.
As it goes with explorations, we generated a few questions and issues with tap-to-tweak that require further wrestling. If you have your own thoughts on how these issues might be addressed (or if you have more questions to throw on the pile), we would love to hear them.
- What is the right interaction to pair your phone with your device? Tap to pair or hold to pair?
- Is there a proxy for tap-to-tweak for objects that are out-of-reach (eg. a lightswitch)?
- Are there any hard-and-fast rules, precedents, or metaphors that can help draw the line between what (core) affordances should be on a connected product and what (advanced) affordances should be abstracted into software?