Desktop Scheduling Product
Active911 is a software company whose flagship app helps emergency first responders get to the scene with the information they need.
I started working for the company as their first and only design hire, and my first task was to create the company's second product.
Existing scheduling softwares do not accommodate the various shift rotations and needs of emergency first responders.
I was tasked to create a desktop scheduling software that filled those needs, focusing on customizable shift rotations for firefighters.
Sole Product Designer
Market Research, Customer Interviews, User Flows, Wireframes, Low Fidelity Prototyping, User Testing, High Fidelity User Interface and Interaction Design
Sketch, InVision, OneNote
Two months from research to delivery
I began by interviewing 6 chiefs of staff, mostly in the fire industry, to figure out their current process, what's working, what's not working, and what's missing.
Next I trialled 4 scheduling softwares and spoke to Active911 employees who had done previous research to find the market fit. After all this I had an understanding of the market and what people were looking for.
CUSTOMER INTERVIEW KEY FINDINGS
Current state: Pen + paper and Excel
Reason: Softwares have a high price and lack of fire-specific accommodations
Ideal state: Being able to specify a custom template then fill it in with personnel
Reason: Wide variety of scheduling patterns between departments, but usually the same template for every schedule
Three distinct scenarios:
1. Paid departments may have the same people on the same rotating shifts
2. Volunteer departments may receive availability calendars and create schedules based on submissions
3. Combination departments have paid people on a set schedule and accept volunteers whenever they're available
STATE OF THE ART KEY FINDINGS:
Most products don't easily allow for irregular patterns of rotating shifts
Most products have too many options, making them complicated and unintuitive
DEFINE ACCEPTANCE CRITERIA
My product manager and I worked together to define the acceptance criteria once we compared our individual findings.
We defined what the requirements should be for both the MVP and the future state of the product. I like to use the Must, Should, Could method to separate out the different states.
Allow creation of multiple schedules
Create custom-rotating shifts within a schedule
Have the option to use common firefighter shift templates
Be able to create positions and users
Add users to shifts
Users can claim their own shifts
Users can request shifts for admins to approve or deny
Positions can be restricted based on qualifications
Choose any length of shift to rotate
COULD (FUTURE STATE)
Send mass emails to get shifts filled
Send email notifications when assignments have changed
Print a schedule
Show a detailed history of changes on shifts
Do all this in an app version
Once we defined what the product needed to do, we dove into the main problems that needed to be solved:
"How might we arrange all the components in a logical and understandable way?"
"How might we provide a fully customizable shift rotation mechanism that is simple and intuitive?"
First, I had to figure out how each element was going to relate to one another.
After spending hours trying to hash it all out on pen a paper and nothing was working, I finally had a breakthrough once I used physical objects to figure out schedules, shifts, positions, and users would fit together.
Next, I used different example scenarios from my initial research to come up with how a user would create a schedule.
The schedule creation was the main flow for this product, so it's the first thing I worked on. After that came the calendar view, navigation, and creating/editing/deleting components.
Overview Scenario 1:
Department in an urban area on a California schedule (24h on duty, 24h off duty, 24h on duty, 96h off duty) with 12 full time employees and 23 volunteers. Department relies on volunteers to fill the gaps when full timers are out.
Overview Scenario 2:
Department in a rural area on an ABC schedule (24h on duty, 48h off duty) with 3 full time officers and 18 volunteers. Department relied on volunteers every day to respond to calls.
Specific Scenario 1:
Each of the A, B, and C shifts require one duty officer, one driver, one medic, and at least three firefighters. Only qualified personnel can fill those roles.
Specific Scenario 2:
There is a weekday shift, a weeknight shift, a weekend day shift, and a weekend night shift. There are assigned duty officers for the night shift, but the rest of the positions rely on volunteers. The weekday shifts are occupied by full-time paid personnel and the weekend day shift relies on volunteers.
DESIGN AND PROTOTYPE
After the user flow was approved by the team I moved on to sketches and wireframes
During this stage I checked in with my product manager almost daily, presented to the developers and QA engineers twice a week, and checked in with users at all the major breakthrough points.
WIREFRAMES READY FOR TESTING
Once I refined the flow and wireframes, I created a prototype with InVision and the Craft plugin to user test with 4 of the same chiefs of staff.
Overall, it was well received, with some areas for improvement. The terms and flow made sense to everyone, but it soon became apparent that the mechanism for creating the schedule was incomplete. It left gaps in the schedule and it was not as customizable as they would have liked.
I needed to make the mechanism for creating the rotating schedules more customizable.
In the initial wireframes, users were only able to select the shift length and the number of shifts. This didn't allow for users to rearrange the actual shifts.
INITIAL SCHEDULE CREATION MECHANISM
The first breakthrough came in a brainstorming meeting with my product manager and the head of engineering.
If I added an option to customize the number of days before the sequence of shifts rotated, it allowed the space for admins to customize how the shifts would be arranged within those days.
I realized that dragging shifts into the days would truly allow for complete customization.
There are many ways a user could determine the order of the shifts, but I thought that an interactive element like a drag and drop would be the most straight-forward and intuitive way.
It took dozens of iterations to get from the beginning to the final mechanism.
By experimenting with different ideas in Sketch and getting feedback from my team, I was able to finalize the design for the MVP. We decided the simplest path forward for now would be for the shifts to only be 24h long, and we can do another update in the near future with customizable times.
All actions and navigation comes from the 'Manage' sidebar
Use the arrows to navigate through weeks, click "Today" to be brought back to the current week
Clicking on a shift on the calendar shows a modal with that shift's details
ONE-OFF SHIFT CREATION
The product was launched 3 months later to a Beta group of 100+ agencies as Active911's second product.
Overall the concept was well-received, but the adoption rate was lower than expected. Upon doing more interviews with beta testers, we found that the lack of features prevented agencies from being able to fully use the product.
Users were having a hard time:
decentralizing work by admins, since non-admin users were unable to interact with it
getting shifts filled at the last minute
using the schedule to historical records and payroll
creating schedules with 8h or 12h shifts
After spending weeks of addressing these issues and fixing bugs, we still weren't seeing the adoption rate we expected, so we ramped up our interviews in an attempt to uncover the root issues.
We discovered that because users were accustomed to using the Active911 flagship app without an account, they expected the same behavior from this new scheduling software.
Once we validated the problem through more interviews and surveys, we decided we needed to build the app sooner than later with a clear and easy path to create an account.
Since releasing the app and making continual iterations to the desktop version, the product has been moved out of Beta and we now have paying customers.
Our team has grown to 5 people, and we are releasing updates every 2-3 weeks based directly on user feedback gathered through interviews, surveys, and social media.