Tinker Tayler Solder Pi
The story of 'Music Mail', a personal project that touches on the intersection of the Internet of Things and Service Design.
This article tells the story of a product I created for my family and I. My aim wasn’t to create the next big hit on Kickstarter, instead it was to solve a very particular and real need of ours. During the process I gained some practical knowledge into how to prototype ‘connected’ devices as well as some first-hand insight into the relationship between the Internet of Things and Service Design.
The Project: Music Mail
Music Mail is a device that allows me to send music to my family at home when I’m not there. When I add songs to a specific Spotify playlist, the device lights up to notify my family that new songs have been sent. Simple controls provide a straightforward way for them to play the music in the playlist.
The user need
When my son was born, my wife was at home more and wanted music around the flat — both for entertainment and so that our son grew up around music.
We bought a small Bluetooth speaker. The actual sound quality was excellent. 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. She then had to navigate through the Spotify app to find music and then finally play it. In addition to this was the task of thinking of something to play.
This long-winded process in addition to dealing with a newborn meant that life at home was still music-less.
At the same time, I would hear music whilst at work and want to share it with my family in a way that didn’t involve Facebook. There was a design opportunity:
An easy way to send music to my family.
- A ‘frictionless’ way to play music at home.
- It may have been a niche need, but for me, it was worth solving.
How it works
Music Mail is made up of two main elements: the physical device and the online service.
At the core of the device is a Raspberry Pi — a credit-card sized computer. The Pi has Node.js installed on it, which means I can write most of the code needed in Javascript. This code uses a library to interact with my Spotify playlist.
Connected to the Raspberry Pi is an amplifier and some speakers. I then have some LEDs, buttons and other controls to make up the user interface.
The service element consists of an application running in the cloud that sends notification emails when music is playing and also serves a website. The website displays what track is playing in real-time using web-sockets.
The Process
Because the Raspberry Pi is a full-blown computer, it can take a while to get things configured and get the basics up and running — the first big step was getting a simple button to work.
After that, progress quickened. Early on, I could take a flexible approach, experimenting with different components.
Design decisions
Whilst making the prototype, I kept facing questions that hadn’t occurred to me before:
- Should new tracks be added to the beginning or end of the playlist? (I decided the beginning so that songs play in reverse chronological order).
- What happens when you reach the end of the playlist — does it loop?
- If so, what if you have unplayed new tracks — does it play them automatically or bypass them?
The LED notification system led to even more questions:
- Does the light go out as soon as you play a new song or after the song has ended?
- What if you have more than one new song — does the light go out as soon as you play the first song or once you have played all of them?
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. It’s one of the key reasons for prototyping something. In The Politics of Prototyping, Gill Wildman and Nick Durrant describe this as backtalk:
In making the prototype […] design decisions become clearer, and elements of problem framing, problem solving, and expression get resolved in real time. You understand what something is, and is not, just be making a version of it
Assembly
When everything was working properly on the breadboard, I started soldering everything together:
To make the housing I used a simple 3D application called SketchUp. A nice feature of this is that you can download models of components, such as the buttons and speakers, to help you arrange everything spatially.
Next, I sent the hardware design to an online laser-cutting service to get it cut from plywood.
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.
At the time, it seemed like a ‘nice-to-have’, non-essential feature. However, it ended up being key to the product’s value.
Testing
When the device was ready enough, I took it home so that my family could start using it. My plan was to learn from the prototype and improve it.
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. However, something else happened that I hadn’t anticipated.
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:
The feedback provided by the emails allowed me to debug things that weren’t working but more importantly, to understand exactly how it was being used.
Findings
During the testing, I could update the behaviours of the device simply by updating code. For instance, 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.
There were some issues related to the hardware that couldn’t be updated as easily: the notification light at the top of the box meant that my son was too little to see when there was a new track.
Overall, the device was a success at home — it eliminated any barriers to putting music on; the mental model for how playlists work was understood; my son played music independently, controlled it easily and responded emotionally to it.
A particularly interesting thing that I observed was how behaviours change over time. At first, the playlist was quite short and therefore learnable — it meant my wife wanted the ability to find a particular song. But over time, the playlist grew — it was no longer learnable, older songs were rarely played and if songs weren’t added regularly it could get repetitive. A new requirement emerged — a shuffle mode.
Out of everything though, the thing that struck me most was the powerful feedback loop created by the system of the device and email/website.
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.
This emotional connection continues each time my family receives new music and every time I get an email saying music is playing.
IoT and Service Design
This emotional connection that Music Mail creates isn’t really due to the physical device, it’s a result of the messaging and feedback service behind it. It showed that the Internet of Things isn’t about the things, it’s about the underlying service.
In the book Smart Things, Mike Kuniavsky discusses what he calls Service Avatars:
When information produces most of the value for users, the hardware and software through which it is experienced takes a secondary role.
Rather than being the centre of attention, it becomes a conduit for delivering information driven services.
The tool becomes an avatar of the service.
The classic example of a Service Avatar he gives is an iPod with iTunes as the service behind it. Another, more extreme, example is Amazon’s Dash Button. Amazon is a huge service made up of sophisticated technical infrastructure, huge inventory, warehouses, logistics and more. The Dash button allows you to buy a single product, it’s the thinnest slice of their service that you can probably imagine.
If these devices are just avatars of the service, it highlights that Service Design becomes very important.
These internet-things could be considered as just one of many service touchpoints. This means we could use tools like Service Blueprints to plan interactions between these touchpoints and orchestrate them over time. This consideration of time as a medium is an aspect of Service Design that’s particularly interesting.
Experiences with websites are often over a relatively short period of time, which means we can build a prototype and do an hour long usability test. Designing for a service that takes place over long periods of time requires a different prototyping approach. We need prototypes that can be lived with and experienced over time.
Experiencing Music Mail over a period of months, meant I gained insight in a way that wouldn’t have been possible with more traditional methods.
Thinking of new ways to simulate these time-based experiences is a challenge that excites me.
Conclusion
Music Mail was a very personal project, but it also led to a number of learnings that other people involved in User Experience may find useful:
- When working with the Internet of Things, don’t think so much about the things, instead, focus on the service.
- Design prototypes of product/service systems so that they can be experienced and tested over longer periods of time.
- Design IoT prototypes so they provide real-time feedback on their usage. Use this feedback as a prompt to probe research participants.
- Design IoT prototypes to allow for device and service behaviours to be updated throughout a research phase.
This project is one I’d like to carry on working on, but in the meantime I’d be interested to hear other people’s thoughts on the project. Or, if you have any questions related to the process, please leave a comment.
Director of Practice