Brief
Update the existing Coach Availability system to include two additional elements. Minimize impact to coaches and their students.
Detail
On the dashboard, a coach may choose which times they wish to make themselves available by setting their Availability. They are presented with a schedule block with every hour of each day. In the original version, a coach could only choose to be available or not - 'yes' or 'no'.
Conversations with our coaches lead to the design of a system wherein they could make additional selections. They suggested that in addition to being 'generally available', they would like to also have the choice to specify time blocks only be for 'new students' or 'returning students'.
Further, we realized the potential for scaling this system so we should keep this in mind for future versions.
Impact
The availability that each coach sets on this page is directly tied to a students ability to schedule a lesson with them. Further, coaching provides the primary revenue for the company. This system needs to work, period.
Challenges
A simple 'yes' or 'no' choice was very simple to communicate, even on mobile. The user clicked a blank block and that block became green. Having two additional elements added complexity and raised the question how the user should make the selection.
For instance, it was suggested that the 'toggle' become three-way so that availability options 'cycled' with each click. This could work with some extra communication but I didn't like the idea of an invisible interface.
Results
The changes launched without a hitch, the new system blending seamlessly into the old. Coaches were immediately able to update their schedules to specify their availability and feedback was overwhelmingly positive. Still, UX is never truly finished, and we immediately had ideas on how to further improve and iterate on the application.
Planning the Interactions
Below is an abridged, presentation-friendly view of the annotated document that I shared with the development team. That document provided a living source for the definition of each block state and the color/font treatment that went along with each as well as a sample flow.
Certainly you don't want to see the full document. Right?
Prototype - Mobile
As I mentioned, the original mobile view of this web app was just a scrunched up version of the desktop app. The calendar was so small that a finger could barely touch just one hour block. Since our clients make heavy use of the dashboard on their mobile phones, I wanted to make this a more pleasant experience.
Below is the interaction storyboard I created to illustrate what I wanted for mobile: A more app-like experience. Instead of being shown the entire week at once, a user would see one day at a time. Visual cues would direct them to scroll up/down and left/right, though this interaction scheme is typical of an application such as this - very little guidance was required.
Final Rendering
Below is the dev/staging rendering of the desktop and mobile applications. A talented team of developers makes it look easy, don't they?
