My Role: UX designer
UX designer on this project.
I collaborated with a design systems designer, product manager, UX writer and 2-3 engineers.
Target user:
Organiser of an event , ideal for events where the meeting size is above 3 people.
Problem
Incomplete meeting creation experience
Unfamiliar interface, interactions and mental models
Objective
Business Goals
User goals
Teams upheld Microsoft's vision to empower people and organisations to achieve more. It was built to compliment Outlook and boost productivity by syncing seamlessly with it. Both Outlook and Teams belonged to the O356 suite. Teams was being sold on a freemium pricing plan, which meant that users' expectation model would demand parity between the two products in the same suite, especially for apps like Calendar that carried out the same and/or similar tasks.
Before we redesigned this experience, Teams' Scheduling Assistant was nothing like Outlook's– in functionality, interface or architecture. This was potentially throwing users astray by increasing cognitive dissonance. It also lacked all relevant functionality.
When we decided to solve these core issues, our team was gifted the opportunity to use legacy as a means to learn, align and speed the process of designing Assistant.
Learn from Outlook's framework and derive insights to improve the original architecture of Scheduling Assistant.
Align Teams' architecture with Outlook's to match user's expectations and mental models.
Speed the building process by using Outlook's codebase.
An additional opportunity was to improve Outlook's experience to solve for a pressing time scheduling issue for global, remote teams.
Jobs-to-be-done
Learn, Align & Speed: Feature framework
There are two parts to Assistant's framework: 'Teams specific' and 'derived from Outlook'
Key interfaces, flows and considerations
Below are some sample screens, which were delivered to engineers. This was then shipped to 25 million users across the globe. Many of the components that can be seen in these designs are native to Microsoft Teams' design system. It was imperative for us designers to use these reusable components for consistency and ease of development. A few components however, like the availability pills, were introduced into the design system specifically for this feature. The legend however, maintained that of Outlook's for familiarity and continuity. Another feature that was introduced here was the summary 'Peek' (shown below). It's inspired from other Peek's on Teams, and maintained the specs of all others on the platform. It's an enhancement from Outlook's experience and is aimed at quicker decision making.
Cross-platform feature design: Location picker
Meeting location as a feature that scaled across devices and platforms offered a unique opportunity to customise its functionality to suit the device and thus its use cases.
There were two core scenarios to consider across devices:
Design iterations
I went through a few iterations for this feature.
1. Timezone feature (improvement from Outlook, but rejected later)
Originally, the attendees were segregated by timezones. But, why?
Teams' largest customers are large, global organisation with teams spread across geographies. Scheduling meeting across cities and countries is common. However, finding a common time keeping time zones in mind is a manually intensive process with high cognitive load and time spent.
Proposed a solution through design
The solution automatically separated participants into their respective timezone 'buckets'. But more importantly, it displayed the corresponding time across relevant timezones so that the organiser might choose the most respectful times for all attendees.
However, our technical constraint was that we couldn't detect the location of the attendees. While we tried different approaches like looking at working hours to define timezone or extracting location data from Outlook, we soon realised this wasn't possible.
2. Edge cases (improvement from Outlook)
Through data from Outlook and collaboration with engineers, several edge cases presented themselves. Designing solutions for these were challenging, in part because they threatened to modify the core design. Given that these were edge cases, we created workarounds instead. This journey had a valuable learning embedded in it – accounting for them in the design process is crucial. Else the system can break in the rare chance that they may occur. Some examples below:
3. Overlapping meeting (improvement from Outlook)
Teams' largest customers are large, global organisations with big teams. It isn't uncommon for individuals to have multiple meetings scheduled (either accepted, tentative or optional) at the same time. A calendar needs to represent these conflicts effectively. An assistant needs to follow suite, albeit with reduced levels of granularity.
Initially, our solution was optimised for 2 overlapping meetings (the average as we learnt through data). However, this solution would breed errors while coding. We therefore came up with a new design solution entirely to deal with overlapping meetings, without limiting our solution to 2 overlapping meetings. Our new solution would:
This, in addition to handling any edge case that cropped up, would also provide users with the opportunity to have any offline conversation to resolve conflict issues if needed. It provided them with information clearly and contextually.
Consumer and team impact
Personal Growth
I was trusted to be the primary owner of this feature. To ensure I carry learnings from this experience and others with me, I documented key takeaways in this article.