Screen Shot 2021-04-11 at 12.01.24 PM.pn
Active911 Logo.png

Desktop Scheduling Product

Active911

CONTEXT

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.

PROBLEM

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.

ROLE

Sole Product Designer

SKILLS USED

Market Research, Customer Interviews, User Flows, Wireframes, Low Fidelity Prototyping, User Testing, High Fidelity User Interface and Interaction Design

TOOLS USED

Sketch, InVision, OneNote

TIMEFRAME

Two months from research to delivery

RESEARCH

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.

MUST (MVP)

  • 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

SHOULD (UPDATES)

  • 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?"

IDEATE

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.  

VISUALIZATION
Screen Shot 2021-04-11 at 9.00.44 PM.png

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.

SCENARIOS

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.

DIGITAL NOTEPAD
Brain Dump.png
DIGITAL SKETCHES
Image 4-11-21 at 5.53 PM.jpg
Screen Shot 2021-04-11 at 5.07.47 PM.png
USER FLOW
Image 4-12-21 at 2.38 PM (1).jpg

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.

SKETCHES
Screen Shot 2021-04-11 at 6.01.50 PM.png
INITIAL WIREFRAMES
Screen Shot 2021-04-11 at 6.21.09 PM.png
Screen Shot 2021-04-11 at 6.21.26 PM.png
WIREFRAMES READY FOR TESTING
Image 4-12-21 at 5.42 PM.jpg

USER 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.

NEXT STEPS

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
Screen Shot 2021-11-07 at 10.06.13 AM.png
Screen Shot 2021-11-06 at 9.20.45 PM.png

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.

Schedule 1_2x.png
Schedule 2_2x.png
Schedule 3_2x.png

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. 

Schedule 4_2x.png
FINAL MECHANISM
Screen Shot 2021-11-11 at 5.52.22 PM.png

ITERATIONS OVERVIEW

Screen Shot 2021-03-01 at 8.50.05 AM.png

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.

FINAL DESIGNS

SCHEDULE CREATION

CALENDAR VIEW

Screen Shot 2021-04-11 at 9.26.54 PM.png

1

2

3

1

All actions and navigation comes from the 'Manage' sidebar

2

Use the arrows to navigate through weeks, click "Today" to be brought back to the current week

3

Clicking on a shift on the calendar shows a modal with that shift's details​

ONE-OFF SHIFT CREATION

Screen Shot 2021-11-11 at 9.43.11 PM.png

POSITION CREATION

Screen Shot 2021-04-11 at 10.47.03 PM.pn

OUTCOME

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.

UPDATE

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.