AUIs for Google Workspace

We started by brainstorming 10 ideas from mobile or web apps and identifying opportunities for AUI innovations. We analyzed the feasibility for data collection and labeling, the value co-created by the service provider and customers from the following aspects:

We found that a lot of ideas we created had the similar idea of building a stronger recommendation system based on daily use routines. We wonder if we can create something beyond that. Looking through our ideas, we found a connection between Box and Calendar, what if they are both Google products and the data can be shared across apps to increase the accuracy of predictions?

Ada needs to share documents in an email to the clients on her phone during her flight. She’s annoyed by the file attachment process. She has to remember the file names and make sure she addresses them correctly. Otherwise, it might confuse the clients who receive the files.

As soon as she types out “Please review the attached doc ...” a ranked list of suggested files for attaching pops up.

Throughout the day, Ada needs to schedule meetings with multiple teams. She’s pretty frustrated that she has to manually type in the name of meetings and the names/email address of all meeting participants.

The system made an inference on who Ada will most likely be meeting with based on keywords in the event name extracted from past meetings that have the same name.

She needs to check file updates before regular meetings, keep track of so many files, and share the report with her teams and clients after the meetings. She’s frustrated that she wastes a lot of her time navigating through folders or looking for files, especially during a meeting.

The system made an inference on which file Ada will most likely be shared with the email recipients based on keywords extracted from past Gmail history, recipient Gmail profile (address/organization), and files’ recent sharing frequency.

During the process of developing the above Gmail Prototype, we considered 3 design patterns as signifiers for AUI inference:

We agreed to choose the third one because this design pattern provides the clearest signifier that fits with users’ mental model on the functionality. However, it needed more modification at this point in that we want the AUI to provide close-enough inferences, but not one accurate result for users.

We developed 2 AUI options for Google calendar:

It was difficult to make the decision, especially when Gmail has so many user scenarios: we believed that it is important for users not to send the invitation to the wrong people, so options 2 seems a little bit aggressive; on the other hand, we also think option 1 would require more clicks if users do not need to go through this step every time they set up events for the same group of people. These repetitive steps can be tedious especially if they invite a large group of people. After evaluating benefits and risks, we decided to pursue option 2.

1. Smart autofill is not an “individual model”, so autofill for only 6 people in Gmail is way out of the possibility.
2. The fully adaptive UI is probably not plausible because we will never have enough data but taking a top 3 selection should work.

1. We need to consider: how often is an entire folder being shared vs. an individual file being shared?
2. Sending email in google drive is not a frequent use, so probably not getting enough data to make accurate inferences here.

From this project, I learned that a large user base is a challenge but also an opportunity for designers because little tweaks in scenarios can potentially generate more nuanced contextual information that leads to new design opportunities, eg. the scenario change from GDrive file sharing to opening files during meetings.

AI systems are not perfect and may always make inaccurate predictions. Therefore, I learned to consider error recovery and nuances in designing for AUIs: how do we prevent user disappointment from inaccurate suggestions? how can we bring users one step closer to their goals?