Published research suggested that many Gmail users still felt overloaded by email, and that people who expected folders found the label system confusing.

Our team began with a hypothesis: Gmail’s organization and time zone features might be making it harder for professionals to stay productive and communicate globally. We focused on professionals because email carries much of their work, and more of that work now crosses time zones.

The research lead and I mapped what we already knew about users, their context, and the system, and where their expectations broke down. That map set what the study needed to observe.

We needed to see where people struggled while they worked. We turned each part of the hypothesis into a scenario that a participant would perform in a prepared inbox.

The four scenarios covered managing high email volume, organizing information and files, protecting important email, and scheduling across time zones. Each goal could be reached in many ways, so we chose specific features to make success measurable. Together they broke into nine steps: bulk selection, archive, filters, labels, search, spam, starred and important, tabs, and scheduled send.

For each step we set the same success criteria: time to complete, number of errors, and how easy the participant found it.

Each session ran over Zoom on a dedicated Google test account. We reset the account to the same starting state before every session, so each participant began with the same inbox and the same emails. Participants used remote control to operate it on the moderator’s screen, and the note taker could follow the cursor as well as the voice.

Each session had a moderator and a note taker. The research lead and I split the sessions as moderators, working from the same script. In my sessions, I introduced each task, responded when something unexpected happened, and asked follow-up questions when a participant hesitated. Teammates took notes, recording what participants said, what they did, and how they reacted at each step.

Every note was tagged with its step and the participant’s reaction. That let us compare the same step across sessions. Creating labels drew satisfaction in one session and surprise or impatience in others.

The research lead and I synthesized 71 data points across three rounds of affinity mapping. Teammates had recorded them in two colors: 44 described what participants did, and 27 captured what they said or how they reacted. The distinction let us see where observed behavior aligned with what participants said and where it did not.

In the second round, we grouped related notes into ten clusters. Six pointed to a specific feature, such as archive, labels, or scheduled send. Four described behavior that appeared across features: hesitating, succeeding by chance, finding features unintuitive, and feeling satisfied. One of the six, about switching between Gmail and Drive, rested on a single note, so it did not carry into the final round. The other nine drew on notes from several sessions.

In the third round, four broader insights remained, no longer tied to individual features. We counted successes as evidence alongside failures. A participant who skipped the filter and found an email by searching told us as much as one who could not finish a task.

After synthesis, the team turned the findings into design directions. Each one named a breakdown we had observed and the change it called for. Our UX design lead then explored those directions within Gmail’s existing interface.

The evidence was not equally strong across every direction, and the explorations did not always address the full finding. Some breakdowns recurred across sessions and gave us stronger grounds for a design direction. Others appeared only once or extended beyond what the study directly supported. We kept those distinctions visible, so each exploration shows both the strength of its evidence and what it actually addresses.

Each of our four goals could be reached through many Gmail features. To make success measurable, we chose a few features for each goal and named them in the tasks. That let us see whether participants knew each feature, used it, and could use it. It could not show whether they would think of that feature at all when facing the goal alone. Even when a task named the filter, a participant searched instead. Next time, I would pair feature-named tasks with goal-based ones, such as gathering every email about a quarterly budget in one place.

We set success criteria before testing: time, errors, and ease. Synthesis showed that finishing a step and reaching its intended outcome could differ. A participant who deleted an email in place of moving it to spam finished the step and missed the outcome. I would define the intended outcome of each step in advance, and record the path a participant took separately from the result.

Our final insights mixed behavior and feeling. “Satisfaction with the familiar features” records how participants felt. Written as behavior, such as participants returning to features they already trusted, it would have pointed the design team more directly toward what to change. I would write insights as observable behavior and note how many sessions supported each one at the time.

The study left me with three questions to ask before any test begins: what each task will reveal, what counts as success, and what the team will be able to act on.