Design for failure

Claire Rowland / @clurr

Designing for the Internet of Things, September 2016

geek.com

•Product/UX strategy consultant

•Specialising in IoT, particularly connected home/energy management

•Lead author of Designing Connected Products

Me…

FAILThe internet loves a

Who Wants to be a Millionaire, image via ranker.com

IoT: a rich source of new fails

3 questions for today

• Why is failure an issue for connected products?

• In what ways can connected products fail?

• What can designers and product developers do to mitigate this?

3 questions for today

• Why is failure an issue for connected products?

• In what ways can connected products fail?

• What can designers and product owners do to mitigate this?

Why is failure an issue for connected products?

We’re putting computing power, machine learning, sensing, actuation and connectivity into ever more objects and systems in the physical world

autonomoustractor.com

grenzebach.com sjm.com august.com

Worst of both worlds!

Hardware

Physical breakage

Software

Always in beta!

In what ways can connected products fail?

3 questions for today

• Why is failure an issue for connected products?

• In what ways can connected products fail?

• What can designers and product owners do to mitigate this?

• Device issues

• Network/service issues

• Business issues

• User issues

• ‘Real world’ issuesknowyourmeme.com

Device issues

Power

•Batteries run out, mains power fails

•All electrical devices can lose power, connected or not

•But new classes of things now need power, when their ancestors did not

•So more things can stop working

“The battery died. I need to charge my wine bottle.” The Verge review of kuvee.com

Hardware

•Electronics can fail

•Mechanical actuators can break

•There are more things not to work

Wikipedia

Sensor failures and glitches

engadget.com theatlantic.com

Onboard software/firmware

•May crash

•May have bugs

•Will need updating, which may cause unintended consequences

•At a certain point older hardware may not support software/firmware updates

•Do you support multiple hardware versions, or do you cut those users loose?

via @internetofshit, Richard Fortune (@iamkey)

Network/service issues

Network

•Lost connectivity

•Moving out of range

•Interference

•Impact depends on system architecture

Argh, the microwaves!

Inappropriate delays for context of use

•Devices can be slow to join the network

•Messages passing between devices/cloud services are subject to latency

•Battery powered devices may only check into the network intermittently

……………………………………………..

“Oh never mind”

[ding dong]

Nicolas Calderone via macsources.com

Online service outages

“We are experiencing some minor difficulties with a 3rd party server.”

petnet.com

Interoperability fails

•3rd party changes hardware, APIs or product features that your product uses

•At best the two stop working together, at worst your product could fail outright as a result

•Getting support with these problems can be tough: who is actually responsible? Google Product Forums

Business issues

•Products which were once one-off purchases now require ongoing services to keep running

•It has to be in someone’s ongoing financial interest to keep them running

•It often isn’t

Business failure, M&A, sunsetting

arlogilbert.com

User issues

User error…

•People do things by accident… like unplugging hubs or turning off switches

•They forget things, e.g. leaving them on

•Or miscalculate, such as getting medication dosages wrong

patientsafetyauthority.org

…recklessness, or deliberate subversion

latimes.com

Real world context issues

Failure to respond to changes in circumstances

thenextweb.com

Failure to suit user’s context

Daniel Raffell on medium.com

gizmodo.com

Remote controls/automation rules applied in inappropriate circumstances

Shropshire Insurance

•A remote user cannot see that an action was inappropriate

•Automation rules that were originally appropriate are ported over to a new context when the device is repurposed, and are now actively dangerous

What can we do to mitigate possible failures?

Claude Dennis and Linda Narkiewicz via simplonpc.co.uk

Constructive pessimism (Murphy’s law)

“It is found that anything that can go wrong at sea generally does go wrong sooner or later, so it is not to be wondered that owners prefer the safe to the scientific ....

“Sufficient stress can hardly be laid on the advantages of simplicity. The human factor cannot be safely neglected in planning machinery.

“If attention is to be obtained, the engine must be such that the engineer will be disposed to attend to it.” Holt, Alfred. "Review of the Progress of Steam Shipping during the last Quarter of a Century," 1878

Product value must outweigh potential risks

smartbe.co

If the value of your product is marginal, but the impact of it going wrong is catastrophic, it’s time to think again

+ -Hands-free strolling

Stroller runs away into traffic

Architect the system to tolerate lost connectivity

Design for intermittent connectivity

•Connect when convenient

•Buffer data for later transmission

•It’s sometimes possible to use analytics to estimate the readings you would have got

brita.com

Things that need to work locally should not rely on the cloud

Capable devices should be able to work independently

Hubs enable local control of devices if connectivity is lost

Distributed/‘fog’ computing systems may soon enable local programs to run without a hub

ecobee.com smartthings.com plumlife.com

Never be worse than the unconnected equivalent

If your product is replacing a non-connected product, ensure yours works at least as well as that if connectivity is lost

Den Automation

Never be worse than the unconnected equivalent

Default to a safe state

http://medicalfuturist.com/living-with-an-artificial-pancreas/

Default to a safe stateIf it’s not possible to retain basic functionality in event of failure, always default to a safe state

“The user can't reset it without removing the battery, and he can't remove the battery without unlocking the lock”Anthony Rose, via http://www.tomsguide.com/us/bluetooth-lock-hacks-defcon2016,news-23129.html

There must always be a manual override

thequicklock.com

Keep the user informed

Be clear: did the user just press the button or was the action actually executed?

Images: lowes.com

Beware unknown real-world context when reporting the status of a device

You know the lock is engaged.

But is the door locked closed or locked open?

kwikset.com

Help users overcome problems

It’s hard to strike the right balance between being informative about errors, and not confusing users with technical information

But very general error messages help no-one

Skybell, via macsources.com

Minimise the risk of user errors and allow for recovery

Minimise risk and impact of user error You can’t control for reckless behaviour but you can try to mitigate the damage that can be done

Consider context, require confirmation

Remember you can often reverse a command to a connected device, but not necessarily the consequences

“There’s an iron plugged in to me. Are you sure you want to turn me on?”

geotogether.com

Really understand the context of use

Will your bright idea break in the real world?

nest.com

•User research and testing in context is vital

•Regulations are boring but important

Marcus Mark Ramos via channelnewsasia.com

Make it worth someone’s while to keep the service running

Mitigating business failure

In the event that you can't support your product anymore, try to make sure it’s at least worth someone else’s time

e.g. Source code and money in escrow

variety.com

If something does go wrong, be helpful and sensitive

Who is responsible?

In systems of interoperating products, diagnosing what the problem is and which component is causing it can be very hard

Who does the user call?

Try to be aware of likely issues with interoperating products

“You need to talk to your ISP”

“Your WiFi is misconfigured”

“That’s a Google problem”

“That’s a Samsung problem”

Sensitive response?

https://www.tesla.com/blog/tragic-loss

Our cars are really safe

We’re sorry someone died

In summary…

Suggested design principles

•Product value must outweigh potential risks•Architect the system to tolerate lost connectivity•Never be worse than the unconnected equivalent•Default to a safe state•Keep the user informed•Minimise the risk and impact of user errors•Really understand the context of use•Make it worth someone’s while to keep the service running•If something does go wrong, be helpful and sensitive

Create products that prevent and mitigate real world failures

jpl.nasa.gov

up.com

phyn.com

And also:

Thank you! Claire Rowland @clurr / claire@clairerowland.com

Hat tips for references and crowdsourced examples to Stacey Higginbotham’s IoT Podcast, @internetofshit, @badiotday, Fabien Marry, Alastair Somerville, Bryan Rieger, Stephanie Rieger, Chris Holgate ,Rob Whiting, Simon Frost, Valkyrie Savage, Toby Jaffey, Ben Hardill, Julian Bleecker, Nik Martelaro, Scott Minneman, Leah Buechley, Carla Diana, Tom Igoe, Vadim Kravtchenko, Tod E Kurt, Liz Goodman, Josh Bloom, Scott Smith.

“This is more than a UX book; it covers all of the critical design and technology issues around making great connected products.”

David Rose. Author: Enchanted Objects

“As a grizzled veteran of several campaigns within the matter-battle of the Internet of Things, I was pleasantly surprised to find the number of times this book made me pause, think, and rethink my own work (and that of others). A very valuable addition to the canon of design thinking in this emerging area.”

Matt Jones. Google

“Whether you’re an IoT pro or just getting started designing connected products, this comprehensive book has something for everyone, from examinations of different network protocols all the way up to value propositions and considerations for hardware, software, and services. This book takes a clear-eyed look at IoT from all angles.”

Dan Saffer. Mayfield Robotics