Understanding Users
We talked to around eight employees at Amazon who would be the heaviest users of this tool- program managers, executive assistants, and managers. Because this was happening during the pandemic, we conducted interviews and focus group sessions remotely. We learned that many of them were skeptical of meeting suggestion tools because they often had to make educated guesses on what meetings to prioritize based on intuition and their knowledge of their team’s priorities. They often were creating meetings with high urgency and they needed to quick-create meetings but also go deep and complex when they needed it.
Ideation
We then researched existing paradigms for meeting and event creation to understand the various mental models for meeting creation and created wireframes based on these mental models to decide which followed our users’ needs and requirements the most.
The Calendar was the most common interaction model but, while it was easy and familiar, we felt that it was too redundant with Outlook, which would go against Amazon’s goal of replacing Outlook for meeting creation. We needed a core differentiator before introducing the calendar.
The Meeting Manager would allow users to see a list of their meetings first and foremost and would arguably be the fastest model for finding a meeting. A top-level navigation could also allow us to introduce more views over time, like a Calendar view.
Resource Surfer is similar to the meeting manager but the meetings panel takes up more real estate on the desktop and a filter panel appears on the side. Showing more meeting detail will also allow users to quickly view the status of meetings, rooms, and people, which would be conducive to faster and more accurate meeting creation. .
We also explored the Wizard, which was user-friendly for new users but may get in the way of more expert users.
Finally, we explored a model called the Meeting Maker, where users can “quick-create” a meeting. This may not allow the users a lot of customizability at the start but we can give them this capability later and provide a more complex meeting creation feature alongside the quick meeting creation to accommodate a wide variety of needs.
Based on this rationale from a users’ need perspective, we decided to use the Resource Surfer and Meeting Manager to narrow down our directions.
Refinement
We also used elements from the other directions when we felt that it would help simplify complex meeting creation- for example, the Stepper and Zoomer are Wizard-lite in that they walk users through the steps while still making it easy for them to jump between the different steps. This would also allow users to view and search for rooms and people with more robust filtering.
So we went with the Stepper. As we did this, we began exploring how we might combine Amazon’s design system and Amazon Meetings’ design elements to these screens.
Finally, we decided on a visual design with the Amazon team. In the end result you see here, which are screenshots of the actual shipped product, Amazon employees have the choice of quickly creating a meeting or creating a more complex meeting with the Stepper. With the quick meeting creation tool, they’re able to receive smart suggestions based on their inputs. When they decide to go through the complex meeting creation tool, they have access to more complex input fields and a deeper view of their colleagues’ schedules but they can still choose to receive smart meeting suggestions in a calendar or list view. They’re also able to book rooms and see their schedule in the familiar Calendar view.
Conclusion
The final design was largely praised with Peter Skillman, the UX manager, saying that it was easily one of the best designed internal tools at Amazon. Another UX manager said that it created a new bar for the quality of UX of all MeetEx products. We were also told that it received much positive feedback from users, as well as a 9% uptick in adoption.
While the redesign was successful, if I had more time I would explore ways to reduce the number and the appearance of identical-looking input fields, which is overwhelming at first glance. We might do this through the use of groupings and progressive disclosure.
I would also explore the onboarding process more, as the first thing users are forced to do when they try to create a meeting is discern whether they need to create a “simple” meeting, “standard meeting,” or a “room invite.” The differences should be made clearer at the outset.
This was the first time I worked on a product for users at this scale and completely remotely. We had to move quickly while relying heavily on stakeholder focus groups for direction and we supplemented this with casual test sessions with personal friends who worked at Amazon. This taught me to roll with the punches and try to get feedback however I could.
