Nespresso Wi-Fi Aeroccino UX
Our previous work had a great impact on Nespresso’s connected strategy, they returned to NONOBJECT when they were developing the next product in this system, which was the Aeroccino milk frother.
Role: Project Lead
Contributions: Industrial Design, Hardware UX/MMI
Team: 1 designer
Role: Project Lead
Contributions: Industrial Design, Hardware UX/MMI
Team: 1 designer
Background
Bringing IoT to the Aeroccino
The Aeroccino line of products are accessories meant to accompany Nespresso’s coffee machines to help users make milk-based drinks such as lattes or cappuccinos.
Nespresso wanted to design an Aeroccino that would be sold with the Wi-Fi Prodigio we developed for them.
Nespresso wanted to design an Aeroccino that would be sold with the Wi-Fi Prodigio we developed for them.
User Research
Existing Interface Proved Difficult to Understand
We trawled reviews for the current Aeroccinos and interviewed users for insights.
The MMI ranged from:
• single button, oversimplified and abstract
• to multi-button with cryptic icons
The MMI ranged from:
• single button, oversimplified and abstract
• to multi-button with cryptic icons
Volume indicators also had cryptic icons that represented the types of whisk to use, and “max” and “min” were abstract and inaccurate to a lot of users, resulting in overflowing milk on the countertop.
Problem Definition
Can We Also Automate This?
When we designed the new Prodigio for Nespresso, we focused on reducing complexity in the MMI, giving users the best coffee with the least effort and ambiguity.
Integrating the Aeroccino into this setup threatened to break that seamless UX. From tapping tapping the display on the Prodigio to physical buttons on the Aeroccino, the UX felt misaligned with the Prodigio.
How might we automate milk frothing on the Aeroccino?
How might we automate milk frothing on the Aeroccino?
Translating Prodigio Automation to Frothing Milk
Once we decided to automate as much of the interface as possible, we sought to translate the Prodigio experience to the Aeroccino.
Just like the Prodigio’s ability to read capsules, I experimented with “What if the Aeroccino can read how much milk you add?”
Since different milk-based drinks required different amounts of milk, could we utilise a volume sensor to detect the amount of milk users added as a way to select what drink to make.
Since different milk-based drinks required different amounts of milk, could we utilise a volume sensor to detect the amount of milk users added as a way to select what drink to make.
Pouring to a very specific volume proved to be difficult in our user testing, so we went with ranges to be more forgiving to the user.
Deliver
Hardware UX: User Flows
For coffee, a user makes coffee by placing a capsule on the receiver.
A sensor reads the capsule flavour and displays what it’s making on the Prodigio.
A sensor reads the capsule flavour and displays what it’s making on the Prodigio.
Milk follows the same paradigm.
The user pours milk into the jug and places the jug on the stand.
A sensor detects how much milk was added, and displays what it’s making on the Prodigio.
The user pours milk into the jug and places the jug on the stand.
A sensor detects how much milk was added, and displays what it’s making on the Prodigio.
3 different ranges define how the milk will be frothed.
These diagrams outline the hardware flow for each task.
The consistent paradigm here is automation based on user-input.
Smart fine-tuning occurs in the background; each espresso can be brewed differently (eg. more acidic to balance out the milk) depending on whether it is being consumed alone or within a specific milk-based drink.
The system also is lenient enough to allow the user to input milk or capsule in any order.
The consistent paradigm here is automation based on user-input.
Smart fine-tuning occurs in the background; each espresso can be brewed differently (eg. more acidic to balance out the milk) depending on whether it is being consumed alone or within a specific milk-based drink.
The system also is lenient enough to allow the user to input milk or capsule in any order.
Deliver
Hardware UX: Detailed MMI Timings
I exhaustively detailed all possible permutations and combinations to provide guidance for the firmware and mechanical engineers in their development for both machines.
These diagrams outline what happens if the user starts by frothing milk:
These diagrams outline what happens if the user starts by brewing coffee:
Because the nozzles of the two devices must take turns to dispense, the wireframes above help ensure the system works harmoniously under all circumstances.
The interface is kept extremely simple for our users, and complexity is kept within the firmware.
The interface is kept extremely simple for our users, and complexity is kept within the firmware.
Impact
Learning from a Difficult Project
To be frank, this was the best outcome in a really difficult project.
We developed the Prodigio after confirming with the client that milk-based drinks was not a priority for the product. To shoehorn the Aeroccino into the system after the fact was non-ideal.
Our recommendation to Nespresso when we received the project was that they build a bigger version of the Prodigio with an integrated refrigerated milk tank so that the entire process can remain unified in automation, but as our client, they had the final say on what we built for them.
We developed the Prodigio after confirming with the client that milk-based drinks was not a priority for the product. To shoehorn the Aeroccino into the system after the fact was non-ideal.
Our recommendation to Nespresso when we received the project was that they build a bigger version of the Prodigio with an integrated refrigerated milk tank so that the entire process can remain unified in automation, but as our client, they had the final say on what we built for them.