case study

Outlook add-in

Outlook
add-in

Outlook
add-in

My role

We were a small team of three designers reporting directly to the Head of UX/CPO. I did these UXR pieces with a team mate, and worked hand-in-hand with a PM & Engineering to deliver designs for this whole product.

We were a small team of three designers reporting directly to the Head of UX/CPO. I did these UXR pieces with a team mate, and worked hand-in-hand with a PM & Engineering to deliver designs for this whole product.

identifying an opportunity

Discovery

Discovery

Sometimes realisations come in unexpected places. While doing research for our desktop app's booking system – for completely different things – we uncovered complications that exist outside that system.

Sometimes realisations come in unexpected places. While doing research for our desktop app's booking system – for completely different things – we uncovered complications that exist outside that system.

Here's a typical practice a team mate of mine and I did. Moderated sessions with paid participants, sourced & screened via a recruitment agency.

Here's a typical practice a team mate of mine and I did. Moderated sessions with paid participants, sourced & screened via a recruitment agency.

1hr per participant

1hr per participant

  • 20min: Contextual overview

  • 20min: Contextual overview

  • e.g. "What’s your job role, and how do you handle your spacial needs for it?"

  • e.g. "What’s your job role, and how do you handle your spacial needs for it?"

  • 30min: Test prototype flows or a stable demo build. Single task flows, A/B task flows or free-form exploration, depending on our needs.

  • 30min: Test prototype flows or a stable demo build. Single task flows, A/B task flows or free-form exploration, depending on our needs.

  • 10min: Discuss the product-fit with their job role needs.

  • 10min: Discuss the product-fit with their job role needs.

  • After every set of 6 sessions: Affinity grouping to identify commonalities in experience needs, pain points & shortcomings in our solutions.

  • After every set of 6 sessions: Affinity grouping to identify commonalities in experience needs, pain points & shortcomings in our solutions.

One of our affinity grouping exercises that led to these new findings.

Problem Space

While analysing findings we realised how much work users need to do outside of our booking system to communicate details with their colleagues.

While analysing findings we realised how much work users need to do outside of our booking system to communicate details with their colleagues.

The need for a meeting room typically arises through conversations in Outlook or Teams. The user would then go to our booking system, book a suitable room, then go back to Outlook or Teams to relay information and handle invitations themselves. Afterwards, the user would end up with one appointment in Outlook (including their meeting attendees) and one room booking in our own system, for that very same meeting.

The need for a meeting room typically arises through conversations in Outlook or Teams. The user would then go to our booking system, book a suitable room, then go back to Outlook or Teams to relay information and handle invitations themselves. Afterwards, the user would end up with one appointment in Outlook (including their meeting attendees) and one room booking in our own system, for that very same meeting.

Bringing it to life

Goal

Goal

Why have to go to our bookings app to book a room, when we can bring our booking experience to where you already are? Sometimes you don’t need more features across more touch points, you just need the right capability in the right place.

Why have to go to our bookings app to book a room, when we can bring our booking experience to where you already are? Sometimes you don’t need more features across more touch points, you just need the right capability in the right place.

The engineering team and our CPO had serendipitously already been eye-balling MS365 integrations. Once we realised we could bring some of our booking solutions directly into Outlook via an add-in, our CPO set forth a new product concept for us to execute.

The engineering team and our CPO had serendipitously already been eye-balling MS365 integrations. Once we realised we could bring some of our booking solutions directly into Outlook via an add-in, our CPO set forth a new product concept for us to execute.

Design

Core requirements

Core requirements

  • Book a multi-occupancy space (e.g. a meeting room), directly inside the Outlook calendar event window.

  • Book a multi-occupancy space (e.g. a meeting room), directly inside the Outlook calendar event window.

  • Book a multi-occupancy space (e.g. a meeting room), directly inside the Outlook calendar event window.

  • Search for spaces across any office building globally, on any floor, and with any space attributes.

  • Search for spaces across any office building globally, on any floor, and with any space attributes.

  • Search for spaces across any office building globally, on any floor, and with any space attributes.

  • Support multi-space bookings for single events.

  • Support multi-space bookings for single events.

  • Make events a Teams meeting to support remote joiners.

  • Make events a Teams meeting to support remote joiners.

How an Add-in opens

Our Add-in

Sample screens (not a flow)

Sample screens (not a flow)

Technical limitations

Compromise

Compromise

An unexpected finding was how limited communication between an Outlook add-in and it's calendar event is.

An unexpected finding was how limited communication between an Outlook add-in and it's calendar event is.

There’s only a small amount of data we can pull (which can only happen when the add-in opens), and there’s only a small amount of data we can push (which can only happen when the user does “submit & close” in the calendar event). Mid-flow calls can pull & push to our own APIs, just not the user’s Outlook account. This limited quite a few feature concepts we were keen on, like managing attendees and their office presence, for example.

There’s only a small amount of data we can pull (which can only happen when the add-in opens), and there’s only a small amount of data we can push (which can only happen when the user does “submit & close” in the calendar event). Mid-flow calls can pull & push to our own APIs, just not the user’s Outlook account. This limited quite a few feature concepts we were keen on, like managing attendees and their office presence, for example.

Interesting UX wins

Despite the technical limitations above, we could still bring our core booking journeys directly into Outlook, and cut out a lot of complexity that happens for our users before & after the act of making a meeting/booking.

Despite the technical limitations above, we could still bring our core booking journeys directly into Outlook, and cut out a lot of complexity that happens for our users before & after the act of making a meeting/booking.

  • When the add-in opens, we can see how many attendees there are in the meeting, and who they are. We already know the user’s default building and floor. So we can assume the capacity and location requirements from those, and automatically run an availability search with those parameters.

  • When the add-in opens, we can see how many attendees there are in the meeting, and who they are. We already know the user’s default building and floor. So we can assume the capacity and location requirements from those, and automatically run an availability search with those parameters.

  • When a booking is made, we can automatically send calendar invitations to all attendees, and create calendar events for those who accepted, without the booker having to relay any information for it.

  • When a booking is made, we can automatically send calendar invitations to all attendees, and create calendar events for those who accepted, without the booker having to relay any information for it.

  • Alternative times: After some moderated usability testing, we found out that a common unhappy-path use case was not finding a suitable space for the agreed time. It was generally felt that changing the meeting's time is preferable to booking an unsuitable space. We included a small feature called "See alternative times" to surface availabilities with suitable spaces at other times in the chosen day.

  • Alternative times: After some moderated usability testing, we found out that a common unhappy-path use case was not finding a suitable space for the agreed time. It was generally felt that changing the meeting's time is preferable to booking an unsuitable space. We included a small feature called "See alternative times" to surface availabilities with suitable spaces at other times in the chosen day.

It doesn't have to be big to be great

Outcome

Outcome

This was not at all our biggest product, but certainly a popular one.

This was not at all our biggest product, but certainly a popular one.

I don’t have any concrete numbers for this unfortunately, but I do know it was a resounding success. Adoption/sales was very high across our clients, and we received a lot of great feedback from them (via our PMs and Sales teams).

I don’t have any concrete numbers for this unfortunately, but I do know it was a resounding success. Adoption/sales was very high across our clients, and we received a lot of great feedback from them (via our PMs and Sales teams).

© 2024 Richard Gouw

© 2024 Richard Gouw