It’s been a couple of months now since the controversial Revolv case, when Google’s Nest, announced it was shutting down its smart home hub service, effectively making a device people bought less than a year ago completely useless. As you can imagine, people were not happy. Not long before, Philips Hue stirred up similar angry reactions when a software update of their smart light hub blocked out many third party lamps that were previously supported. Although Hue quickly released a new update in which the previous functionality was reinstated, the fact that companies can, and do, unilaterally pull the plug of something that we own is troubling.
We’re not alone in our concern: a recent Fast Company article featuring companies involved in the consumer IoT business fleshes out industry concerns around the life-span of connected devices. With many products’ sophistication and complexity rising beyond the comprehension of average consumers, trust has never been more important.
Here at Uniform, we’ve developed many prototypes for connected products over the past 5 years. We think of APIs as just another material, and we love consuming RESTful interfaces as much as we love turning wood. The above cases made us quite concerned, so we decided to take a step back and pose a big bold question:
Can we trust connected devices?
This is a critical question for everyone involved, users and businesses alike. With unexpected functions, complex updates and a reliance on external platforms we don't control, we know we can’t trust the functionality of connected objects the way we can with, say, a fork. Or a book. Or a coffee press. But until recently, we probably have trusted them to (at the very least) continue to exist. Was that a mistake?
We all have decisions to make when it comes to connected objects. Users will increasingly face decisions over whether to upgrade their home or to keep the dumb yet trustworthy old stuff. The future will be about striking a balance between the desirable functionality of connected devices and our inability to count on their longevity. They’re a gamble. If we (although reluctantly) accept that our new phone will be pretty much useless in two years time, what about other, much less used devices? Do we need to adjust our expectations so that when we buy a smart thing (whether a fork, kettle or light bulb) we no longer expect it will last as long as its cheaper ancestor? Or should we - as makers, designers, companies - hold ourselves to a higher standard?
Our collective trust in IoT products will inevitably drop as the many unpredictable factors that could render devices useless increase. What are these factors? Companies acquired by bigger companies are killing the original products (Revolv). Companies fail (BERG’s Little Printer). Sometimes, they simply discontinue the product (Sony Aibo), often with no public explanation. These are only a few examples, yet in all these cases, users are powerless - simply left to acknowledge their loss and move on.
On the other side are businesses, who will inevitably realise that contributing to the growing flood of short-lived connected gadgets is not sustainable and won’t pay in the long term. Many celebrated connected products are already failing, and from the current scenario, it’s not hard to imagine there will be a death valley at the other side of an inflated expectations mountain. Especially now that some analysts are noticing that we are already saturated with stuff, the need to design something with clear longevity has never been so economically and environmentally relevant. New products will need to be pretty convincing for people to allow them through their homes’ doorway. Which leads us to the real question:
How can we design connected devices that we (users and businesses) can trust?
This is an important value to us, both as makers and as a company. Here are some features we believe a sustainable, trustful connected product should have.
The product should be able to outlive the company that produced it. Users should not be too heavily affected by things that are impossible to predict, such as a company no longer being able to support a costly infrastructure, or deciding a venture is no longer profitable, or any other reason for discontinuance.
We can build this resilience by creating products that are not completely reliant on external cloud services. Protonet, funded by Y Combinator, received extremely positive responses in its crowdfunding campaign for a home automation hub whose voice recognition software still worked offline and connected directly with smart home products (such as lamps, speakers and cameras) thus bypassing the need for an external cloud service.
Supermechanical, a consumer IoT company, is another business sensitive to the matter. Its first product, a sensor hub for the smart home, had quite a few followers, but was not a great commercial success. Even if they don’t sell the product anymore, the software was designed in a way that “the servers it relies on are still running five years later”, so people can still use it. One of the reasons why a small IoT startup should try do the same is the value of trust as commodity: customers will not come back for future products if they were betrayed or let down previously. Interestingly, the Supermechanical product that immediately followed is a food thermometer that doesn’t need the Internet and connects via bluetooth to a smartphone app; in a new iteration of the same product, a physical device connects to the thermometer, successfully avoiding even the need for a smartphone.
But being strategic in the use of cloud services doesn’t translate to eliminating the use of APIs altogether. Being able to take advantage of the power of an online service from a tiny device is a crucial feature of connected products (AI in a lamp, anyone?) - but a device should fail gracefully, and still be useful without the Internet.
We should be able to fix it. Maybe not ourselves, but there should be somebody, somewhere that can fix it. Or, even better, fixability should be a design requirement.
This can be tricky when it comes to connected devices, where unmaintained software exposes them to security vulnerabilities, but it’s not impossible. BERG’s Little Printer and Ninja Blocks, for example, decided to open source their software when they were no longer able to maintain it. I think this is an example of good practice and values that should be encouraged and widely adopted.
On the other side, facing “felony charges and up to 5 years in prison” (as Cory Doctorow points out in his article about the Revolv case) is obviously hard to swallow. Making device repair difficult already sucks, but making it a crime, especially after you’ve already been prevented from using your own device, seems absurd.
3. Useful (rather than cool)
Inventing new things is great, but invention should go alongside thinking about people’s real needs and what might improve their life. Let’s consider a case. I personally don’t think we can identify a reliable and long lasting demographic in the quantified self movement. Yes, tracking fitness data is an effective way to reinforce positive behaviours, and smart wristbands are undoubtedly one of the main players in the connected products market, but assuming somebody who cares about counting daily steps also must be as happy to track calories in everything they eat or drink doesn’t seem wise.
The most popular connected products are the ones that introduce progressive improvements in mundane things: thermostats, light bulbs and wall plugs to name a few. They haven’t looked to revolutionise them. The same should be considered for target audiences. Rather than trying to change everyone’s life, there are many smaller demographics and groups we can design for, such as parenting and elderly care, or divisions across gender or culture. We’re nowhere close to running out of areas that connected object design can improve and make an impact upon.
We’ll make sure to keep those three ‘rules’ in mind in our future work. We’d love to discuss these thoughts with you, or any you might want to add. Feel free to hit us on Twitter and Facebook.