Project Overview
Elastic Path’s Ecommerce software is referred to as a “headless commerce” solution. But what does that mean exactly? And how to you express that in a meaningful way?
That’s why I was asked to work on a tight three week project in order to map out a unique commerce journey with a fairly new touchpoint at the time: voice commerce. The goal was to create a custom demo with voice and an interface in order to demonstrate how users could shop anywhere, anytime for the 2017 Adobe Summit.
To simulate a driving voice assistant, we chose an Amazon Echo (second generation) and a Google Pixel Slate tablet to represent the dashboard UI.
Challenges
- Short time to deliver final narrative
- Experimenting on new technology (room for error)
- Chances that it would not capture interest (unusual use-case)
Brainstorming the Concept
As a first step, my colleague in PreSales and I rented several cars in order to test their current navigation systems. We wanted to come up with a use case that would demonstrate how users could complete a checkout from their vehicle using voice.
Looking at the existing technology embedded inside of a Prius, a Ford and a Mercedes, we determined that we’d actually keep the UI fairly standard, rather that imitate a more iOS styled UI, such as one in a Model 3 Tesla.
After looking at those screens, we came back to the office, and over the course of an intensive brainstorming session, started to define what kind of narrative would best illustrate how our software’s transaction system would work in combination with a voice assistant.
Defining the Persona
We determined that our primary persona in this hypothetical scenario would be a man between 30 and 45, with a high technical proficiency, interested in gadgets and protecting the environment.
Building out the Flow
In order to understand how the voice system would interact with the user, and at the same time, display the correct car dashboard UI, I decided to use a vertical flow diagram with elements of event modelling.
While not a true event modelling framework, this diagram was still able to not only communicate the flow, but which events occured simultaneously and how the system would react to the user’s various selections.
As this was a sales demo, the primary goal was to provide a “happy path” for the user to take, but as a Product Designer, my goal was nonetheless to design for “no” scenarios and alternate paths, in case a user wanted to test the flexibility of the system.
Our basic story was this:
- This user would be driving an electric vehicle
- They would be notified that their battery was low, and would be required to visit a charging station
- The system would identify a nearby station and direct the user to that location
- The user would “purchase” a refill
- While they are waiting, they would then be offered a doughnut and coffee
- They would order the food items, then return to the car when it’s fully charged and drive away
(Right Click “open in new tab” to see a larger version of the diagram)
Wireframing Time
A decision we came to in the process was to adapt a commerce checkout flow to a car dashboard UI, and not the other way around. Why? Because we didn’t want to split the user’s attention with too many other tasks or options that would not be commonly used in a vehile.
For example, we scrapped an earlier wireframe that showed numerous product offerings, a section for promotion, a shopping cart, quantity selector, etc. etc. Single icons would be used, and the same text that would be spoken by the virtual assistant was written in the top UI.
Ultimately, I had to go straight from initial wireframes to final mockups, because the narrative continue to evolve. Therefore I broke down the design into components to keep it modular. Sales representatives on the day could then tweak the screen flow to their liking.
Form Factor
In the ideal setup, the Echo Dots and tablet would be embedded in a mock car dashboard, but due to time constraints and the booth size at Adobe Summit, the team had to keep it relatively simple.
I quickly mocked up some concepts in 3D for how everything could be set up. A backup Echo Dot was used as well, in case the first one experienced any issues.
Final UI
After our team decided to stick to more a standard UI (similar to what the Ford Lincoln has), I switched to landscape mode for the UI, such that we could keep the lower part reserved for the standard set of icons used for navigation (music, phone, navigation, apps and settings).
I kept the UI colors simple and high contrast, and made sure to accentuate the buttons so that the user could clearly tell what was selectable.
I chose Sketch as my go-to tool, because I could re-use symbols in my design library. I then used Zeplin to send the developers my final CSS elements for creating the app.
Final Results
Everything came together right before the big show and for those who attended, the demo was a success. It introduced an unconventional commerce touchpoint with modern technology embedded in a vehicle. Reserving a spot to recharge an electric vehicle is still rare, and supercharging stations hadn’t rolled out on a wider scale at this time in Vancouver.
Some key takeaways when working on the UX for a Voice Assistant:
-
- Alexa still had quite a bit of trouble understanding different accents
- Demo-ing a voice assistant is always conjuring Murphy’s Law – in other words, be prepared for things to go wrong and plan ahead
- This scenario worked best when the assistant asked for a simple “Yes” or “No” – more complicated questions resulted in more room for confusion
- The Alexa is an interesting prototyping tool, but when in doubt, I would suggest going even simpler for a demo so that there are less bugs for the developers to work out