My talk from UX Scotland 2016. This tells the story of a connected device I created for my family. While UX designers are often taught not to design for themselves, through the process I learned a number of lessons about prototyping that are transferrable to other Internet of Things (IoT) projects. During the prototyping phase I also gained first-hand insight into the relationship between Service Design and IoT and the value that Service Design has to offer to connected devices.

1. TINK ER
TAYLER
SOLDER
PI
@stuarttayler1

2. TINK ER
TAYLER
SOLDER
PI
This talk is about a side-
project, rather than a big
commercial project. But I
think there are some useful
learnings.

3. TINK ER
TAYLER
SOLDER
PI
That’s me. I work for
cxpartners as a user
experience consultant
(which explains the
post-its).

4. TINK ER
TAYLER
SOLDER
PI
A soldering iron…

5. TINK ER
TAYLER
SOLDER
PI
And a Raspberry Pi.

6. 1. PROJECT
2. PROCESS
3. IoT & SERVICE DESIGN

7. 1. PROJECT
2. PROCESS
3. IoT & SERVICE DESIGN

8. THE USER NEED
Even though this was a side
project, I still started with a
user need.

9. THE (NICHE) USER NEED
When my son was born,
my wife was at home more
and wanted music around
the flat.

10. We bought a small
Bluetooth speaker.

11. PLAYING MUSIC
MY WIFE:
1. Make sure speaker is on
2. Click button on speaker to make it discoverable
3. Go to home screen
4. Find and open Settings
5. Click on Bluetooth
6. Click on ‘Bose Mini Soundlink’ in ‘My Devices’
7. Wait for Bluetooth to pair
8. Open Spotify
9. Find some music
10. Play music
However, my wife needed
to perform a complex
sequence of interactions
with the speaker’s buttons
and the phone’s settings to
connect over Bluetooth.

12. OPPORTUNITY
AN EASY WAY TO SEND
MUSIC TO MY FAMILY

13. OPPORTUNITY
A ‘FRICTIONLESS’ WAY
TO PLAY MUSIC AT HOME

14. MUSIC MAIL

15. See this video at:
https://vimeo.com/
132147559

16. HOW IT WORKS

17. RASPBERRY PI
At the core of the device is
a Raspberry Pi — a credit-
card sized computer.

18. HOW IT WORKS

19. 1. PROJECT
2. PROCESS
3. IoT & SERVICE DESIGN

20. DURRELL BISHOP – MARBLE ANSWER MACHINE
Design inspiration.

21. My initial idea.

22. Sketches for simplifying the
device.

23. BUILDING THE
PROTOTYPE

24. The first big step was
getting a simple button
to work.

25. The code was written
in Javascript using Node.js.

26. THE VALUE OF
PROTOTYPING
At this point, it would be
good to talk a little about
the nature of prototyping
and why we do it.

28. GILL WILDMAN & NICK DURRANT
1. BACKTALK
2. FEEDBACK
3. TANGIBLE STRATEGY
Gill Wildman and Nick
Durrant describe three
forms of value obtained
through prototyping.

29. GILL WILDMAN & NICK DURRANT
1. BACKTALK
2. FEEDBACK
3. TANGIBLE STRATEGY
I’m interested in the first
one. It’s where you’re
building in order to learn.

30. DESIGN DECISIONS
BECOME CLEARER.
THINGS GET RESOLVED
IN REAL TIME.

31. Huarache Lights by Hot Chip
The Salmon Dance by The Chemical Brothers
Mountains by Prince
Monkey Man by The Maytals
Hold On! I’m A Comin’ by Sam & Dave
Rock the Casbah by The Clash
For example, when you add
new tracks to a Spotify
playlist they are added at
the end.

32. Huarache Lights by Hot Chip
The Salmon Dance by The Chemical Brothers
Mountains by Prince
Monkey Man by The Maytals
Hold On! I’m A Comin’ by Sam & Dave
Rock the Casbah by The Clash
But I had to make a
decision – should it be
chronological or reverse
chronological (like
Instagram)?

33. NOTIFICATIONS
Another example. If
multiple new tracks are
added, do the lights go out
as soon as the first new
track is played? or after they
have all been played?

34. BUILD TO LEARN
These are design decisions
that aren’t easy to foresee
by just thinking about the
problem. But when you’re
making a prototype, they
become patently obvious.

35. Carrying on with the
process…
The working device before
building a housing.

36. Designing the housing
in SketchUp.

39. Exploding the model onto a
2D plane so that it could be
sent to get laser cut.

40. Building the buttons by
glueing layers of plywood.

42. The first layer inside the box
– the Raspberry Pi.

43. The proto-board with
components soldered to it.

44. The amplifier and speakers.

47. The finished box.

48. Once I got the device
playing music, it occurred
to me that it would be
interesting if I could receive
some feedback at work,
showing me what was
playing. I built the email
notification and website,
again using Node.js.

49. PROTOTYPE
RESEARCH

50. When the device was ready,
I took it home so that my
family could start using it.

52. I left a stack of post-its
ready for my wife to take
notes about what she did
and didn’t like.
Unfortunately child care got
in the way of taking notes.

53. The first day I left the box at
home and went to work
was our wedding
anniversary. I sent our first-
dance song. When I got the
email saying she was
playing it, there was a
strong emotive feeling of
being connected.

54. Whenever I received an
email, I knew that my wife
or son had started to
interact with the device. I
could look on the website
too to see what was
happening. It also meant I
knew when it wasn’t being
used, so I could then
explore why:

55. 2 USERS

56. HARRIET
• Enjoys someone else choosing music.
• Radio does a similar job, but this is more tailored.
• Eliminates faffing.
• It’s nice to say ”new music from daddy”.
• Mental model understood.
• Wants to delete some songs.

57. FERGUS
• Plays music independently.
• Changes mood.
• Too short to see light!
• Confused by button functions…

58. PLAYS MUSIC PLAYS MUSIC
There was some confusion
between the two buttons –
although they had different
functions, they both
played music.

59. FIXES AND UPDATES
Through the realtime
updates, I discovered and
fixed a number of bugs.
I also made some bigger
updates, a few of which I’d
like to talk about.

60. TRACK CONTROL
The blue wheel that controls tracks was too sensitive — it
skipped through multiple tracks unless you were careful
enough to move it in small increments. Once I discovered
this, I updated the code so that no matter how much you
moved the wheel it would only skip one track, making it
much more usable.

61. PAUSE LAG
The lag that happened when pressing pause meant you
would end up pressing it twice.
I hacked it by cutting the volume as soon as the button was
pressed to make it feel more responsive.

62. CONTROL THE CODE
TO CONTROL THE
INTERACTIONS
This wasn’t bug-fixing. It was changing the behaviour of the
device, the ‘feel’ of it. But there were no hardware changes,
it was achieved just by updating the code. The behaviour
was crafted by being in control of the code.

63. CHANGES
OVER TIME
A particularly interesting
thing that I observed was
how behaviours change
over time.

64. At the beginning changing
tracks was a novelty, but
this wore off.

65. EARLIER
• Wanted to find a specific song.
LATER
• Wanted tracks to be shuffled.
EVEN LATER
• Linear playing is ok, if regularly updated
Behaviours and needs
changed over time.

66. NEXT STEPS

67. A toy my son has. It has a
button you press to start
playing a song. You press
the same button to play a
new song. A very simple
interaction.

68. PAUSE / OFF
VOLUME
Short press:
PLAY
/ PLAY NEW
/ SKIP NEXT
Long press
SHUFFLE
This is how I thought I
might update the device,
using that same interaction.

69. HARD
TO
UPDATE
TO
UPDATE
EASY-ISH
Before redesigning the
housing, I thought it might
be a good idea to update a
few things first.

70. I added a shuffle mode. It
works really well - you get
to hear older songs.
However there is no
indication of state.

71. You need some visibility of
whether shuffle is on or off.

72. UPDATE CODE TO
HELP YOU MAKE
HARDWARE DECISIONS
I wouldn’t have learned
about the hardware
changes needed, without
updating the software first.

73. 1. PROJECT
2. PROCESS
3. IoT & SERVICE DESIGN

74. In my last job, I worked on
the website for Turkcell
(Turkey’s leading mobile
operator).

75. I also worked on a
Connected Home project
for them.

76. ISTANBUL, 2013.
When we speaker to
customers, they didn’t care
about the ‘tech’ of
connected homes. But
they were interested in
looking after their family
and property.

77. So the service we created
was centred around a
security system that linked
all the sensors together.

78. We also created a bunch of preset ‘rules’ that linked the
devices. These were grouped under categories like ‘keep my
environment safe’ or ‘keep things secure’.
It was the service, rather than the devices that provided
most of the value.

79. The same is true for Music Mail. The emotional connection
created isn’t really due to the physical device, it’s a result of
the messaging and feedback service behind it.

80. THE SERVICE MAKES
THE DIFFERENCE
These examples showed
that the Internet of Things
isn’t about the things, it’s
about the underlying
service.

81. Paul Weichselbaum
Havard Business Review
“Our interaction with devices is profoundly changing
– they are becoming more like interconnected
services than products.”
I saw this same idea
expressed in other places.

82. It’s most clearly articulated
in this book.

83. SERVICE AVATARS
In it, Mike Kuniavsky
introduces the idea of
Service Avatars.

84. MIKE KUNIAVSKY:
“When information produces most of the value for
users, the hardware and software […] takes a
secondary role.
The tool becomes an avatar of the service.”

85. The classic example of a
Service Avatar he gives is an
iPod with iTunes as the
service behind it.

86. Another, more extreme,
example is Amazon’s Dash
Button. It’s the thinnest slice
of their service that you can
probably imagine.

87. WHAT CAN WE LEARN
FROM SERVICE DESIGN?
So if Service Design and IoT
are related, what can we
learn?

88. CONSIDER HOW
THE SERVICE CAN
CREATE VALUE
The first thing is simply
considering the service.

89. TOM ARMITAGE:
“What are the things that are
only possible when the service,
and the object, and the data,
and the network are joined
together?”
Tom Armitage (who has
also written about Service
Avatars) poses an excellent
question.

90. LISTEN ALONG
So what would I change about Music Mail in order to focus
on the service? A progress bar? A listen along button to feel
more connected to my family.

91. A physical ‘like’ button? The
ability to send a voice
message back?

92. A physical ‘like’ button? The
ability to send a voice
message back?

93. This reminds
me of…
The ability to send a voice
message to my family?

94. I’d like to apply this to
another project I’ve been
working on. An internet-
connected piggy bank.

95. This is how the idea would
work: A parent and child
would go and open a
children's savings account.

96. CHILD
SAVINGS
ACCOUNT
19122010
CHILD
SAVINGS
ACCOUNT
19122010
This account essentially lives in the cloud. It’s intangible.
The pig provides an interface with the account. It looks like
a Service Avatar!

97. The pig stays in the child’s
bedroom.

98. Parents can then send
pocket money to children
using a dedicated service.

99. When they do, the pigs ears
spin around.
See this video at:
https://vimeo.com/
170875909

100. This acts as a notification.

102. You earned 50p!
When the child shakes the
pig, the pig says how much
money has been earned
and how much their savings
are worth.

103. Happy Birthday!
love Granny
But what’s only possible
when the service, object,
data, and the network are
joined?
Maybe the child could
exchange messages with
Grandparents.

104. Thank you Granny!
But what’s only possible
when the service, object,
data, and the network are
joined?
Maybe the child could
exchange messages with
Grandparents.

105. How much have I
saved this month?
Maybe the child can speak
to the pig and ask it
questions?

106. How much more
do I need to save
for a remote
controlled car?
Maybe the child can speak
to the pig and ask it
questions?

107. IT’S ABOUT TIME
The second thing we can
learn from Service Design is
the importance of
time-based interactions.

108. This is highlighted in Lucy
Kimbell’s book.

109. LUCY KIMBELL:
“SERVICE RESTS ON THE
IDEA OF VALUE-IN-USE
OVER TIME,
NOT VALUE-IN-EXCHANGE
IN A TRANSACTION”

110. LUCY KIMBELL:
“SERVICE RESTS ON THE
IDEA OF VALUE-IN-USE
OVER TIME,
NOT VALUE-IN-EXCHANGE
IN A TRANSACTION”

111. Time is also discussed in a
book by my old bosses.

112. POLAINE, REASON & LØVLIE:
“FOR SERVICE DESIGNERS,
THE OBJECTS OF DESIGN
ARE EXPERIENCES
OVER TIME.”
Here, they are discussing
the difference between
Service and UX design.

113. HOW DO YOU ENSURE
PEOPLE WILL GET
VALUE-IN-USE OVER
TIME?
So how do you design
for time?

114. EXPERIENCE
PROTOTYPING
I believe one answer is
by using Experience
Prototyping.

115. MAYPOLE PROJECT
This was a project by Ideo and Nokia. They wanted to
explore picture messaging (back in the 90s). The prototype
required a power pack and transceiver unit that children had
to carry around in a backpack, yet the experience was so
compelling that they forgot about that inconvenience.

116. Marion Buchenau, Jane Fulton Suri
By the term “Experience Prototype” we mean to
emphasize the experiential aspect of whatever
representations are needed to successfully (re)live
or convey an experience with a product, space
or system.

117. MUSIC MAIL
Music Mail could be
considered an experience
prototype.

118. CAN WE TURN THIS
INTO AN EXPERIENCE
PROTOTYPE?
What about the pig?
At the moment I’ve really just been prototyping the
interfaces and interactions - the web UI, the notification
mechanism, interactions with the device.
HOWEVER, it’s not a prototype of the actual experience of
saving real money or even spending money.
For that you’d need to link the pig to an real account.

119. PRETEND
ACCOUNT
(Database)
API
The way I built the pig was
to build a fake bank
account using a database.
So that the pig could ‘speak’
to that fake account, I
created an API.

120. A few weeks ago I got a
Mondo card. The great
thing about it is it has an
API of it’s own. This meant I
could link my API to it’s API.
Suddenly the pig is linked to
a real account!

121. A few weeks ago I got a
Mondo card. The great
thing about it is it has an
API of it’s own. This meant I
could link my API to it’s API.
Suddenly the pig is linked to
a real account!

122. RESEARCHING
TIME-BASED
EXPERIENCES
So that’s prototyping time-
based experiences, what
about researching them?

123. DIARY STUDIES
Traditionally, diary studies
are used for longitudinal
studies. At cxpartners,
we use an app called
Native Eye.
However, diary studies
usually rely on recall.

124. PREDICTION
ACTUAL
EXPERIENCE RECALL
IN-THE-MOMENT
RESEARCH
Studies have shown how emotions about an experience vary depending
on when you speak to them about it.
Humans have exceptionally weak skills on predicting feelings about future
experiences.
Other studies talk about the ‘rosy retrospection effect’.
As my colleague James Lang says, you need to get as close to the
‘moment-of-truth’ – the actual experience – as possible.

125. When I was getting feedback from Music Mail and then
following up with SMS, I was doing ‘in-the-moment’
research. This actually has a name: ‘Experience Sampling’.
It’s the technique Mihaly Csikszentmihalyi used when doing
research for ‘Flow’, except he used a pager.

126. EXPERIENCE
SAMPLING
When I was getting feedback from Music Mail and then
following up with SMS, I was doing ‘in-the-moment’
research. This actually has a name: ‘Experience Sampling’.
It’s the technique Mihaly Csikszentmihalyi used when doing
research for ‘Flow’, except he used a pager.

127. But what about the piggy
bank?
If This Then That is a service
that allows you to connect
other services together.

128. I can use IFTTT to connect my API with Slack so that I can
record events, like a new pocket money donation. This then
allows you to do experience sampling, by following up with
a text, call, etc.

129. DESIGN IN FEEDBACK
SO YOU CAN SAMPLE
EXPERIENCES CLOSER
TO THE ‘MOMENTS OF
TRUTH’
APIs are really helpful for
doing this kind of research.
It’s worth understanding
how they work.

130. THINGS
I’VE LEARNT:
In conclusion…

131. BUILD TO LEARN

132. CONTROL INTERACTIONS
THROUGH CODE

133. CONSIDER HOW THE
SERVICE CAN ADD VALUE

134. USE EXPERIENCE
PROTOTYPING TO
HELP YOU CREATE
VALUE-IN-USE OVER TIME

135. DESIGN IN FEEDBACK
TO CAPTURE
MOMENTS OF TRUTH

136. DESIGN PROTOTYPES
FOR ITERATIONS AND
CONTINUOUS
IMPROVEMENT

137. THANKS!
FEEDBACK WELCOME:
stuart.tayler@cxpartners.co.uk
@stuarttayler1