Design Is in the Details
A case study for designing digital assistants
It’s raining, and I just missed my bus—there’s no way I’m going to be at work for the 9am meeting I scheduled. I pick up my phone and say, “Hey Google, reschedule my next meeting to 10am.” That should give me enough time…
Recently, the G Suite team announced new Google Assistant capabilities that let users dial in to a meeting, email attendees, and cancel or reschedule. I had the privilege of working on these productivity features, where the Assistant does some heavy lifting (so the user doesn’t have to). The team, consisting of representatives from product, engineering, conversation design, and interaction design, spent hours on every design detail to ensure we were alleviating real pain points—and not creating new ones. I’ll walk through some of the decisions and insights we made along the way, so you can apply them to designing a new Action or voice experience on your own.
Reduce the burden of choice
We designed the reschedule meeting feature to help people manage busy schedules — whether they’re running 10 minutes late or just realized they’re double-booked.
Here’s what the experience sounds like:
User: Hey Google, reschedule my weekly team meeting.
Assistant: That’s Weekly Team Check-in currently at 8am, right?
User: Right.
Assistant: Sure, everyone is available tomorrow at 10am. Does that work?
User: Yes.
Boom.
The Assistant checks all attendees’ calendars and returns a list of possible meeting times, taking into consideration work hours, weekends, and other parameters. The Assistant is able to propose multiple times, but we offer just one to start. If the user had replied “no” instead, the exchange would go something like this:
User: No.
Assistant: OK, how about tomorrow at 4:30pm, Friday at 3pm, or Monday at 10:30am?
We made the decision to offer just one choice to alleviate the burden of listening to multiple options and then having to decide. Offering one choice may seem simple but it’s actually quite complicated. Personally, it’s what I’m most excited about—the Assistant being assistive!
Design and engineering worked very closely to determine how many time slots could and should be returned from the backend, in addition to the rank or order of the list. In doing so, we offer what the Assistant believes is the highest-ranked option from the list first, and fall back to the other choices if needed. As trust increases with use, we expect more users will say “yes” at the first proposal and move on quickly.
Put people in control
We also understand that people sometimes want to drive the conversation with their Assistant, so we’re careful not to back them into something they may not want. If after hearing a few time slots they still want something specific, we let them stray from the exact dialog to ask, “What about next week?” Or, “Look for a time on Tuesday.”
We try to offer context and detail without getting in the way. Here’s an example:
User: Reschedule Project Purple Listening Session to 4pm.
Assistant: That’s Project Purple Listening Session currently at 11am, right?
User: Yes.
Assistant: Ashley Irvine isn’t available at 4pm, but everyone is available at 3pm. So which do you prefer: 3pm, 4pm, or do you want to look for another time?
User: 3pm.
Spending time on user research up front helped us identify these use cases. Another early learning was that people with busy calendars often don’t remember the name of their meetings. In talking to people, we were able to identify the different ways they might refer to a meeting. Turns out, people often remember standing weekly meetings by the time of the meeting or the people attending, but not necessarily the name of the meeting. They might say something like, “I have a weekly team meeting Mondays at 11.” We spent time making sure we could support natural questions like, “What’s next on my calendar?” and “When’s my meeting with Pete?” as well as ambiguous meeting names.
Dive into the details
We want our dialogs to be quick and efficient, but we also want to be sure the Assistant is acting on the right meeting. We started out by always asking a confirmation question, as in “That’s Monthly Update at 4pm, right?” However, every dialog turn takes time, and in some situations it felt like the confirmation made the dialog feel too heavy and long. To address this, the team worked on differentiating when an explicit or implicit confirmation of the meeting name would make sense.
We went through all the different ways to start rescheduling a meeting and were able to identify some cases where we could skip the confirmation. If a user asks, “What’s next on my calendar?” hears the next meeting, and then says “reschedule it,” the Assistant has the context of the meeting from a previous dialog turn and can implicitly confirm by saying, “OK, Monthly Update. Everyone is available tomorrow at 10am…” By understanding and documenting all the paths through the dialog, we were able to make the dialog more efficient in some cases.
Takeaways
A few things to keep in mind if you’re designing for voice experiences:
- Talk to the people who will use your product. Do user research to find real pain points for people, and design assistive experiences to address them.
- Be thorough. Think about all the ways users might start the experience and what they might ask for along the way.
- Collaborate. Work closely with engineering to figure out dependencies and requirements for the backend.
- Go deep. Spend time on the details!
Wondering if I ever made that meeting? The next bus arrived in plenty of time for my 10am and it turns out my colleagues were thankful I had rescheduled; they had been stuck in rainy traffic too!
