App Availability Calendar

Project date: April 2022.

Role: Lead Product Designer.

As Product Design lead, I was responsible for each stage of the design process, right through to implementation.

Overview

This project was for a supply teacher recruitment platform. It aimed to devise a new process for teachers to update their availability on the mobile app, so they could receive better-tailored alerts.

Responsibilities

Conducting stakeholder meetings.
Coordinating meetings with the CTO to discuss development feasibility constraints
Creating user personas and customer journey maps
Coordinating ideation meetings with developers
Conducting design reviews
Devising and conducting usability tests prior to developing.
Collecting and analysing user test data.
Managing the handover of the project and conducting fidelity checkpoints.

Stakeholders

CEO
CTO
Sales team
App Developers

Tools used

FigJam
Figma
Maze

Problem Statement

Teacher users of our mobile app were unable to provide a detailed indication of their availability; because of this, sales staff spent a lot of manual effort ascertaining the availability of teachers, which is costly to the startup. The business was also affected as it missed out on potential opportunities for conversion. Due to lack of personalisation, teachers received untimely alerts for positions which resulted in frustration with the app and (possibly,) the business. The existing product also had poor accessibility, which could have resulted in drop offs and an increased churn rate.

Users & Audience

Our primary user was teachers that used our mobile app. We were particularly interested in helping users who had a lot of external commitments - for example, they had other jobs or had a busy family life - and would benefit the most from more personalised alerts. Our teachers ranged in a few years to decades of experience, so we would need to create something that catered to a variety of screen and text sizes, and that would be accessible for people that had lower vision, or were less technologically proficient.

The secondary user group was our internal employees, particularly the Sales team who had a lot of manual involvement in placing teachers into schools, so we would need to create a solution which benefited them too.

User Empathy

Constraints

Time

Time cost was an important factor as our developers had a lot of important projects to deliver within the time frame. We could not afford to spend too long iterating on this project before it was released.

Traffic

As a startup, we had a relatively small amount of traffic to our website, and less to our app. This restricted us in terms of user testing, as we would not be able to rely on quantitative data to outline a clear solution in terms of usability. To combat this, we would opt for more qualitative forms of testing.

Developers

Being a startup company, we were somewhat constrained by the development resources we had, and had to consider how long the project would take as the time cost was more of a concern to us.

Scope

As we were introducing more variety to the availability states, we would need to introduce a new interface, as well as a new user journey, and would need to devise a new set of availability types for the teacher. While we had a web platform, we chose to scope the project to the mobile app to begin, so we could test the usability of these new states with less risk to the business.

We were improving on our MVP, and so our biggest priority was creating a practical solution that was user-focused, and then planned to develop this post-release using any user feedback we received.

Design Process

Understanding

As we were introducing more variety to the availability states, we would need to introduce a new interface, as well as a new user journey, and would need to devise a new set of availability states for the teacher. I began by coordinating a series of meetings to discuss the project brief with the company’s major stakeholders. At this stage, we set business goals for the project and outlined feasibility constraints. I had discussions with sales staff, who were customer-facing, to understand what issues with the product had been conveyed to them by our customers, as I wanted to advocate for our users. I also wanted to understand where the majority of the sales staff’s manual efforts were being used so I could devise a solution that improved the speed and efficiency of their workflow. I spent some time personally assessing the current user flow, taking screenshots of each screen and annotating potential usability issues, and aligning with verbal feedback we’d already received. we had a web platform, we chose to scope the project to the mobile app to begin, so we could test the usability of these new states with less risk to the business.

Ideating

Being a design team of one, I wanted to encourage our developers to provide insights on the project, so I began by running a short ideation meeting where I encouraged creative and innovative ideas to be shared, regardless of whether they fit within our constraints. We shared ideas about the calendars we had personally used, and the experiences we enjoyed. Since we were working from the MVP, we wanted to explore a range of possible solutions. From this point, I created a moodboard of different calendars, both in general and from our competitors. This would be used as a source of inspiration throughout the project and would allow me to explore different innovative routes.

Diverging and Defining

I then began diverging these ideas in a series of low fidelity sketches and wireframes using FigJam. My first concern was with how the user would interact with the calendar to input their availability. I explored a range of different input methods such as modals, start and end date input fields, click-and-drag selections, and more. I also explored how the user would toggle between their weekly and monthly views. I was keen to employ a method that was similar to other app calendars on the market, since I wanted to devise something that felt familiar and native to the user. I settled on two potential designs which were influenced by popular apps. At this point, I coordinated some Design Review meetings to go over the wireframes and discuss areas for iteration. We decided as a team that we wanted to create two separate views for the month and weekly calendar, as this was native to many other apps such as Google Calendar and Apple Calendar. We also decided that this would be the best option for making the feature accessible on smaller screens.

Testing

I created two high-fidelity prototypes which had slightly different input methods. We planned to test our designs using a platform called Maze, a product research platform that would enable us to embed the prototypes and set our testers challenges to test out the usability of the prototypes. We ran separate tests for the monthly and weekly calendar views and aimed to combine the designs that had the best usability. Our users were asked to complete 3 tasks:

Set their availability on individual dates
Set their availability for a whole period, e.g. a week
Set their availability on the weekly view.

Deciding and Developing

The results of the A/B tests were varied, and we had some difficulty in reaching a decision. We received data on task completion rates, misclick rates, average duration, direct success, and bounce rate, and found that each test scored somewhat evenly in each area. We decided to focus on task completion and direct success as the primary factors; since we were using a testing platform, we had to account for the fact that some users may have bounced due to external factors. We also couldn’t guarantee that users would immediately attempt to complete the goal, and attributed ‘misclicks’ to general curiosity. From this, we settled on our final designs.

The next step was to begin developing the chosen designs. Once these were implemented, we would be able to monitor analytics and qualitative feedback to reaffirm or question whether this was a solution that benefited the user and furthered our business goals.

Testing Process

We had aimed to carry out two sets of tests for this project. Because of the fact we were a startup, we knew that we were constrained in the testing we could carry out. Our teachers were engaged with our platform, so we knew we could get some qualitative and quantitative usability feedback before the implementation began. So, we opted to use a platform called Maze to conduct some A/B tests, which would give us an insight into which of two potential solutions would give a better experience. We also planned to keep an eye on app analytics post-implementation, and would use the advantage we had of having a customer-facing sales team to ascertain verbal feedback from our users.

Project Outcomes

128% increase in usage of the calendar...

... in the month following the implementation of the new journey.

Reduced Sales calls and texts by 60% during morning hours.

The Sales team spent significantly less time chasing teachers that were not available. This also saved the business substantial money as 6p/text charges were dramatically reduced.

Great verbal feedback from our users.

A more personalised, tailored experience for our users.

Reflections & Next Steps

As we learnt that this project had successfully increased engagement with the calendar (what we set out to do) and had also decreased the need for sales staff involvement, we set out to create a similar feature for the web platform. We had been able to reduce risk by implementing this on our mobile app where we had less users, and so were able to confidently move forward with implementing this on our web app. We learnt that spending a lot of our efforts ideating drastically different routes had been a useful task. However, we learnt that attempting to generate quantitative data from usability tests was not always helpful to us.