Humanics (Calendar Sharing)

The customer success team identified a pain point that nursing staff were unable to share their work schedule with family and friends to plan their lives. Staff were frequently sending screenshots of their Humanics calendar to friends and family but this wasn't the ideal experience we wanted to provide. Not only that, the Humanics calendar is designed more specifically to view and manage hospital shifts and less as a typical calendar.

Secondarily the team also identified the need for staff to view their work schedules alongside their personal schedules in their default calendar app of their devices. Staff were bouncing between their default calendar app and Humanics when planning life events, which wasn't a pleasant experience either.

Based on the above discovery I accompanied our design researcher to the hospital to ask a few deeper questions. Based on my research session I boiled down calendar sharing to 2 categories: short term and long term sharing.

My initial design leveraged the calendar sharing capability of iOS (and Android) to keep things simple and straightforward. I based this on what other apps and competitors were doing because I didn't want to invent anything new unless there was a clear need. I looked at apps such as NurseGrid, MyDuty and Deliveries. Based on my research I was a little hesitant with this approach because users had to allow access to their calendar data.

Not only that, my hypothesis was this design wouldn't be as intuitive and may require some planning and technical knowledge on the part of the user when sharing their schedule with friends. My other hypothesis was, it could be straightforward for married staff who already have a shared calendar. When I interviewed staff, my hypothesis was proved right as users did not know how to share a calendar (on iOS or Android)

The screens below are showing the key screens for the initial design. The following descriptions start with the screens below from the left.

• 1. System level app settings with calendar access toggle
• 2. In-app settings showing Calendar Sync option off
• 3. Calendar Sync detail screen in OFF state
• 4. Calendar Sync detail screen in ON state with first calendar selected by default.

I created this interaction flow document for the product manager and the engineering team.

This design approach was less work for me and the engineering team but it wasn't ideal for our users, and so I didn't recommend this approach. It also required access to the user's calendar even though we only needed access to write data (not read) but the user does not know that. I felt it is important to avoid even asking for access when possible. In addition, this approach was not of much value from a product sales perspective. We thus ended up shelving it.

Calendar sharing is complicated and not as simple as it sounds. I am a strong proponent of user data privacy and as much as possible I try to avoid accessing user data even if there is a strong need to do so. I always advise my team and all stakeholders of the same. I also wanted to try my best to protect our users from themselves. What does that mean?

It means … unintentional sharing of personal data. The sharing experience needed to be designed with as much transparency and clarity as possible to guide users down the safest path possible while making the interface and workflow intuitive — I needed to strike a very fine balance.

Nursing staff are intelligent humans but my research suggested they aren't quite tech savvy. The Calendar sharing action doesn't just end when you share it with another human, like when sharing a link or photo. This concept was not very clear to nurses.

When a user shares a calendar, personal data continues to flow to the recipient till the initiator decides to stop sharing. This could potentially lead to stalking and other unexpected social issues which I wanted the team to be cognizant of.

Since privacy was paramount, I worked with the Head of Engineering and came to the agreement that we needed to provide a UI for users to know whom they've shared their calendar with, who still has access to their shared calendar, and to manage access.

Shared calendar access and management is already provided by mobile operating systems. However, during the research phase, I discovered that most staff did not know how to share a calendar from their default calendar apps using their mobile operating systems. This not only was a problem, but the business development team saw it as a feature to tout from the sales perspective because we would be able to control the experience from within Humanics. The advantage we have is our users are more familiar with Humanics than system level calendar settings. I thus decided to design a custom solution for managing shared calendars.

I explored some ideas and flows with the Product Manager and Head of Design before I started creating higher fidelity mockups for review.

I explored a flow for short term calendar sharing which I later shelved for a future release because it was out of scope for this release from an engineering standpoint.

I explored the possibility of using QR codes as the primary method of sharing the calendar URL. This was based on the hypothesis that it would be the safest and quickest. However, QR codes did not resonate with nurses when I got to the design validation stage.

Text messaging was generally preferred so I ended up using the standard mobile OS share sheet.

I explored a number of variations in high fidelity — here are a few.

Exploration 1: This was an early quick exploration in which I experimented with a tabbed interface that didn't quite work.

The following descriptions start with the screens below from the left.

• 1. Sharing modal sheet will be accessed from the glyph in the top right corner of the calendar
• 2. Modal sheet with sharing UI
• 3. Recipient name filled
• 4. QR code presented for recipient
• 5. Calendar subscription UI in settings with a switch to show state

Exploration 2: In this set I explored a flow from Profile/settings instead of the calendar because some stakeholders felt that was more appropriate. Design validation later guided us to provide a flow from both the calendar and settings.

The following descriptions start with the screens below from the left.

• 1. Sharing UI from Profile/settings and Subscription is now named "Device - Add Events"
• 2. Slightly refined sharing UI
• 3. A share button is presented when a recipient's name is filled
• 4. QR code presented for recipient
• 5. Recipient name is added to list to manage calendar access

Exploration 3: In this set I explored a flow from both the Profile and the Calendar.

This is the flow from the Profile. Here I used the standard mobile OS share sheet along with the possibility of capturing the text string of the recipient used in the sharing method — "Mom". However, I was advised that this was not technically possible, which required an extra step. I added that in the final design. (see flow diagrams below)

The following descriptions start with the screens below from the left.

• 1. Sharing UI from Profile
• 2. Slightly refined sharing UI with an explicit share button to call standard OS share sheet
• 3. Standard OS share sheet
• 4. Standard OS messaging UI
• 5. Recipient name is added to list to manage calendar access
• 6. Subscription is part of app Settings and I explored "Device Sync" instead of "Subscribe"

This is the flow from the Calendar.

The following descriptions start with the screens below from the left.

• 1. Calendar view has a More button in the top right corner
• 2. The More button presents the action sheet
• 3. Standard OS share sheet to share calendar with others

Since I wanted to avoid asking the user for calendar access for privacy reasons, the Head of Engineering also agreed this was a good goal to strive for. However, this came with a cost. For instance, the iOS engineer on the team advised me that it would require calendar access to display the state of calendar subscription (ON/OFF) when viewing the in-app settings. I thus designed the calendar subscription as a single action button rather than a stateful button. But this was a small cost to pay for privacy. I also took this opportunity to refresh and improve the Profile view.

Secondly, as I wanted to help users view and manage shared calendar access, there was a technical limitation in iOS which resulted in a flow where users had to provide an identifier first for whom they were sharing with, followed by the actual sharing process. This wasn't ideal but it was something I couldn't avoid. You will see this illustrated in the interaction flow below and the screen below on the left. Overall I felt all of this was a small cost to pay to help users manage shared calendar access.

Lastly, there was also the component of how the calendar data should be presented in the default calendar app. I added emojis to denote day or night shifts. Emoji are quite effective at quickly conveying information at a glance without the need of words. I created a spec doc to clarify the details for both Calendar app and Google Calendar app on iOS. I worked with an Android product designer to clarify any details on the Android side.

I uploaded the final mocks to Zeplin along with associated interaction flow and spec documents.

I used TestFlight to install engineering builds on my device so I could provide feedback to engineering as they were implementing my designs. I worked with the technical product manager and a QA engineer to iron out wrinkles and answer questions from the engineering team. I primarily used Sketch for design and prototyping.