The document discusses the challenges and failure modes associated with connected products, particularly in the Internet of Things (IoT) sphere. It outlines various ways products can fail, including device, network, business, and user issues, and emphasizes the need for designers to consider these failures during development. Suggestions for mitigating failures include ensuring product value outweighs risks, designing for lost connectivity, and defaulting to safe states in case of issues.

1. Design for
failure
Claire Rowland / @clurr
Designing for the Internet of Things,
September 2016
geek.com

2. •Product/UX strategy consultant
•Specialising in IoT, particularly
connected home/energy
management
•Lead author of Designing Connected
Products
Me…

3. FAILThe internet loves a
Who Wants to be a Millionaire, image via ranker.com

4. IoT: a rich source of new fails

5. 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?

6. 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?

7. 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

8. Worst of both worlds!
Hardware
Physical
breakage
Software
Always in
beta!

9. In what ways can connected
products fail?

10. 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’ issues
knowyourmeme.com

11. Device issues

12. 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.”
TheVerge review of kuvee.com

13. Hardware
•Electronics can fail
•Mechanical actuators can break
•There are more things not to work
Wikipedia

14. Sensor failures and glitches
engadget.com theatlantic.com

15. 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)

16. Network/service issues

17. Network
•Lost connectivity
•Moving out of range
•Interference
•Impact depends on system
architecture
Argh, the microwaves!

18. 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

19. Online service
outages
“We are experiencing some
minor difficulties with a 3rd
party server.”
petnet.com

20. 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

21. Business issues

22. •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

23. User issues

24. 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

25. …recklessness,
or deliberate
subversion
latimes.com

26. Real world context issues

27. Failure to
respond to
changes in
circumstances
thenextweb.com

28. Failure to suit user’s context
Daniel Raffell on medium.com
gizmodo.com

29. 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

30. What can we do to mitigate
possible failures?

31. 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

32. Product value must outweigh
potential risks

33. smartbe.co

34. 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

35. Architect the system to tolerate
lost connectivity

36. 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

37. 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

38. Never be worse than the
unconnected equivalent

39. 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

40. Default to a safe state

41. http://medicalfuturist.com/living-with-an-artificial-pancreas/
Default to a safe state
If it’s not possible to
retain basic
functionality in event
of failure, always
default to a safe state

42. “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

43. Keep the user informed

44. Be clear: did the user just press the button
or was the action actually executed?
Images: lowes.com

45. 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

46. 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

47. Minimise the risk of user errors
and allow for recovery

48. 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

49. Really understand the context of
use

50. Will your bright idea
break in the real world?
nest.com

51. •User research and testing in context is vital
•Regulations are boring but important
Marcus Mark Ramos via channelnewsasia.com

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

53. 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

54. If something does go wrong, be
helpful and sensitive

55. 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”

56. Sensitive
response?
https://www.tesla.com/blog/tragic-loss
Our cars are really safe
We’re sorry someone died

57. In summary…

58. 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

59. Create products
that prevent and
mitigate real
world failures
jpl.nasa.gov
up.com
phyn.com
And also:

60. 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.

61. “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 ofThings, 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