đ An IoT Piggy Bank you can talk to
Last year I wrote a blog post about an internet connected piggy bank that I made. Kids could shake the pig and it would tell them how much money was in an online bank account.
It gave me the idea that it would be nice if children could talk back to the pig and ask it questions. And so I set to work on a new version. This article explains what Pig eBank 2 does, Iâll share a few learnings from prototyping a voice-controlled device and Iâll consider how it relates to the idea of open banking. Thereâs also some technical details at the end.
What Pig eBank 2 does
The Pig sits at home providing a physical and interactive link to a childâs online bank account. Hereâs an overview of some of things it can do:
Alerts
Much like Pig eBank 1, when there is a transaction â for example, if the child receives pocket money â the pig alerts the child using lights and by pointing its ears up.
In the video above, the pig is connected to a dummy account, with parents using a prototype app. But I also connected the Pig to my Monzo account. As well as providing real transactional events, the data this provides means that it can then be queried, as Iâll explain next.
Ask questions
Version 1 of the Pig provided the same information whenever it was shaken (saving, spending and balance). Version 2 makes the conversation two-sided. You can ask it questions like:
âHow much money do I have?â
âHow much have I spent this week?â
âHow much did I save last month?â
Natural language understanding means you donât have to use those exact phrases, so you might say âWhatâs my balanceâ or âHow much have I savedâ. Being able to query finances in your own language means you can get the information you care about, in a more human way. This hopefully makes finances much more accessible for children.
Set goals and track them
The new Pig allows you to set a savings goal:
âI want to save for a bikeâ.
You can then track that goal:
âHow much more do I need to save?â.
The pig verbally tells you how youâre progressing and you also get feedback through lights and the rotation of the pigs ears.
In fact the ears donât just indicate progress when you ask the pig. Whenever it is inactive the rotation of the ears provides a glanceable overview of how close to your goal you are.
In Enchanted Objects David Rose discusses âglanceabilityâ and how the brain can process information before you fully pay attention to it. This is something cognitive scientists call pre-attentive processing. He argues that because glanceable objects are âdelightfully non-distractingâ they are more likely to be viewed instinctively throughout the day and this can lead to behaviour change. He provides examples from energy monitoring, but perhaps a glanceable view of finances might encourage children to save?
A few learnings
1. The value of a dedicated device
Using a dedicated device as a service channel provides a number of advantages that arenât possible with something like Amazon Echo. You can:
- Include custom functionality â like alerts.
- Create more personality through form, light and mechanical movement.
- Provide glanceable information (as discussed above).
- Remind people about your service to encourage interaction. This is related to Donald Normanâs idea of âinformation in the worldâ in The Design of Everyday Things. If your service is hidden inside an echo people have to remember themselves that they can access it â the knowledge is âin their headâ instead.
- Enable a potentially more natural interaction: There is a specific physical representation of the service and it becomes anthropomorphised. Conversing with it then feels less anonymous than speaking to a generic black cylinder.
As it becomes cheaper to embed voice processing into products, maybe weâll start to see the Internet of Conversational Things!
2. Design for mistakes
Designing for voice (rather than screens) means you have to focus much more on errors â people can say anything and they can also be misheard.
There are a few strategies to deal with this. I used a mixture of enabling undo (if there is a change to the system), doing nothing (for queries), and upfront confirmation (if there is high chance of being misheard). If using confirmations, I tried to group them together so they didnât get annoying.
I used api.ai to handle the logic around errors, but to help me figure out how these strategies should work, I had to crack open omnigraffle and map out the flows. This also helped me to check all errors had been catered for.
3. Communicate state
A voice system by itself doesnât provide any feedback on whatâs happening (aside from when itâs talking): is it listening? is it thinking? has it finished talking? This makes it hard to converse with and is even more apparent if it takes a while for the cloud services to respond.
Amazon Echo and Google Home have a set of additional noises and light patterns to provide cues as to whatâs happening. I developed my own set of cues using light and also the movement of the ears.
Voice is great at uncovering user needs
Once I had finished my prototype I tested it out with my 4 yr old son (younger than my target users). He tried out the things I showed him it could do, but then he said âHow much do I need to save to go camping?â. It surprised me. I hadnât considered that when setting a savings goal, kids might not have an idea of what something costs and I definitely didnât consider that the goal might not be a single specific thing with a fixed cost, but an activity made up of multiple, variable costs.
Designing in this functionality is an interesting challenge, and Iâm thinking of ways to at least handle it gracefully even if a proper answer canât be provided. However, the story illustrates an interesting characteristic of voice interfaces. They donât offer users clear boundaries as to what they can do â thereâs a lack of affordances. This means users can ask for what they really want, rather than being limited by the buttons on a screen.
So voice interfaces may provide a fast-track to understanding customer needs. But someone needs to listen to these requests and the technology needs to log what customers are asking for, so that this can be analysed and acted upon.
A note on open banking
The Pig is connected to a real banking service â Monzo, using their API. PSD2 will enable third parties to use similar âOpenâ APIs to build applications and services around all financial institutions. This means the Pig could in theory be connected to any bank account in the future.
I think this hints at a different kind of opportunity for what PSD2 can enable. Rather than omniscient dashboards that aggregate your financial world, maybe we will see very niche banking services?
It is unlikely that anyone is going to set up a bank just to create a service helping children save money, but instead they could âpiggy-backâ (sorry!) on existing banking infrastructure. In this scenario banking becomes simplified and focussed for key audiences and use cases. What other niche audiences and needs are there that small, specific and simple banking services could be created for?
Thanks for reading
As with the previous article, it would be great to hear your thoughts, questions, suggestions. You can find me here or on Twitter @stuarttayler1.
Post script: the tech stuff
Hardware
The heart of the device is a Raspberry Pi Zero W. The sound input comes from a USB mic and itâs output using and Adafruit amp connected to a small speaker.
The Pi talks to an Adafruit Trinket over I2C. The trinket controls some Adafruit NeoPixels and a servo motor. It also listens to the button presses.
Services
I used a variety of services to enable the conversational interaction:
- Google Cloud Speech API to recognise speech.
- Api.ai to process the speech and handle most of the logic.
- Amazon Polly for speech synthesis.
There is a Node.js app running on the Pi which calls the various services above, handles additional logic and also manages calling the Monzo API. I also have a Node.js app running in the cloud which listens to API calls from the Pig, handles events and manages a user database.