Humanics (Swap & Withdraw)
Humanics is a workforce management solution for nurses and nurse supervisors. The product has 2 parts: a desktop web app and a mobile app (iOS/Android).
The desktop web app is used by nurse supervisors to create and manage the schedules of nursing staff in a hospital unit. The mobile app (iOS/Android) is used by nursing staff on their personal phones to view their hospital work schedule and submit their schedule preferences.
Note: Confidential content - Do not share
Role
As the Principal UI/UX designer, my goal for this project was to improve the swap experience and design a new withdraw experience. I also made sure all iOS visual and interaction designs followed Apple's human interface guidelines.
What is Swap & Withdraw?
Nursing staff may need to swap one or more of their shifts with another staff member for various reasons but mostly personal ones. This is called initiating a shift swap. The customer success team and design research came to understand that staff were not discovering the swap button.
They also came across a second problem that nurses were facing… in some cases the recipient of a swap had not responded and the initiator wanted to withdraw the pending swap and initiate a new swap but they were unable to.
Stakeholders & Partners
The primary team consisted of the following folks:
- – Head of Design
- – Head of Engineering
- – 1 Business Development Partner
- – 1 Design Researcher
- – 1 Nursing Domain Expert
- – 1 Design Product Manager
- – 1 Engineering Product Manager
- – 1 iOS Engineer
- – 1 Android engineer
- – 1 Back-end Engineer
- – 1 QA Engineer
Previous Home for Swap
As I mentioned above, nursing staff did not discover the swap button and my hypothesis was, it was undiscoverable because it was hidden below the fold.
I Will Lift You Up
I sketched out a few possibilities for where the swap button could go in relation to the primary details for a shift.
I then explored a few high fidelity concepts to improve discoverability without making the button overbearing or imposing.
Other Locations: I explored other locations in the app.
- 1. The one on the left (below) is the calendar card for the shift in the calendar view. This was a bit much as it felt like we were inviting staff to swap their shifts — swapping isn't really encouraged unless it is absolutely necessary.
- 2. The one on the right (below) is the Now screen. The Now screen is like an inbox of cards that have data that nurses may want to know about and act on. I explored a button on the card for an upcoming shift. Again, this was giving the action too much importance.
New Home for Swap
The best place for it is in the shift detail view in the header area. I decided to use the available space more efficiently in the header part of the view and moved some of the data around to find a new home for the button above the fold.
Swap Pending
The Withdraw action is basically the bookend action for a Swap. However, there is a state in-between — swap pending. When a swap is initiated a few things happen, it goes into a pending state while the initiator waits for the recipient to accept the swap request and a push notification is sent to the recipient. It also generates a swap pending card on the Now screen for the initiator and a swap request card on the Now screen of the recipient.
Pending & Withdraw Exploration
I explored a few different variations with the placement of the withdraw button. The amber colored glyph was being used on the calendar when a swap was pending. I decided to repeat that glyph in the shift detail view for continuity.
Shift Detail and Swap Detail Views (Final UI)
Since Withdraw is the bookend for Swap, it made sense for this button to take the place of Swap. I chose to place the pending glyph on the left of the button so I could morph the Swap button to pending. It may not work as well if I place it on the right.
The Withdraw button's location in the Shift Swap Request screen didn't require a lot of exploration and was fairly straightforward. I changed the title from "Your schedule preview" to "Proposed swap" so the placement of the button would make sense to the right of it, and less words are better when we localize in the future.
Thinking About Notifications
Some of the details that don't seem to be given much thought during the design process are notifications on the mobile platform. In my case… how many system level notifications should be pushed during the entire process of a shift swap transaction to the recipient and initiator?
Every app on a mobile platform is vying for the user's attention. When designing an app, one should be judicious about the number of notifications pushed to the user or there's a high risk of having your app be too noisy which can result in the user either deleting the app or turning of all notifications for your app. The former is obvious that you want to avoid, but the latter is also fairly detrimental to the success of an app.
In this scenario of initiating a swap and withdrawing it, the following cases were candidates I considered for push notifications:
- – Should the initiator know that the swap was successfully sent and is pending acceptance?
- – Should the recipient know that they received a swap request?
- – Should the initiator know when a swap was accepted?
- – Should the recipient know that a swap was withdrawn?
There is a fine line between providing too many or too few notifications — discovering that line is where the design opportunity lies.
Hand-off & Deliverables
I took this project as the opportunity to learn the entire shift swap workflow between the initiator, recipient, and supervisor. Based on my learnings I provided an updated interaction flow doc and uploaded the final mocks to Zeplin.
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.
For the Future
I want to talk about metrics. Shift swapping isn't a common or essential workflow so the metrics need to be analyzed accordingly. That being said, there was a 64% increase in usage of the swap feature. As always, I will be circling back with Customer Success to find out more. I will be watching App Store reviews and Twitter for feedback regarding this enhancement.
I talked about system push notification earlier; they were out of scope for this project so I saved my questions for later. I also wanted to focus on the motion design to provide some fun and delight. I worked with the Product Manager and Head of Design to add it to the product roadmap so I could tackle it across the entire app experience holistically at another time. I did the same with notifications, but I prioritized notifications over motion design.
Challenges & Conclusion
I have omitted a few details just to be concise and convey just enough of my story and journey. This project was not that complicated in itself but understanding the entire shift swap workflow was overwhelming but important. However, that learning helped me achieve the goals I had set for myself effectively in the given timeframe.
We are establishing a usage baseline for the withdraw option. This also is not part of a day-to-day workflow, so I am analyzing usage accordingly.
