Prototyping

Code 3 Emergency Response App

Problem: We were directed to individually select a type of application we were familiar with but had significant usability issues, and develop an interactive prototype of a similar application fixing those problems.

Approach: As a volunteer firefighter, I had extensive experience with one particular emergency response and staffing management application, so I selected this as my app type. The assignment was to produce a prototype for a single platform (mobile/tablet/desktop), but I could see clear distinctions in use and function between all three platforms, so I chose to create an adaptive design accounting for functions across all three platforms. This application was required to relay a large amount of information as clearly and quickly as possible, so I made use of color and clear visual icons for rapid recognition.

Results: I used Proto.io to create the prototypes. Unfortunately, the Proto.io account used for the prototype is closed, so I cannot provide an interactive example. However, I can provide screenshots from the fully interactive screens, along with some explanation of functionality in the prototype.

Mobile

The mobile platform would be used primarily for individual responders to manage their own availability, report responses, and use GPS guidance to scene or station. The following interactions were usable on the above screen:

• Fully working expandable menu in upper left corner

• Swipe left or right on incident type to view additional incidents, indicated by arrows and faded icons to either side

• Tap arrows on left or right of incident type to view additional incidents

• Tap "Respond to Station" to go to a linked Responding screen with updated response status

• Tap "Respond to Scene" with effects as above

• Tap "Set Unavailable" to change green "Available" at top to red "Unavailable" status, change button to green "Set Available", gray out and disable response buttons, and move name from Available list to Unavailable list

Tablet

The tablet platform would be used primarily in emergency vehicles such as fire engines or ambulances. It would be used as a constant GPS map and incident alert and response system, as well as reporting unit availability. The following interactions were usable on the above screen:

• Gear in upper right corner opened a Settings page

• Tap arrows on left or right of incident type to view additional incidents, indicated by arrows and faded icons to either side

• Tap "Respond" to change button to red "Cancel Response," gray out and disable "Set Unavailable" button, and change status at top to blue "Responding"

• Tap "Set Unavailable" to change button to green "Set Available" button, gray out and disable "Respond" button, and change status at top to red "Unavailable"

Desktop

The desktop platform would be used primarily in a station setting, or for administrative functions for the full system. It would display personnel and unit status on screens inside the station, and allow supervisors such as a chief or duty officer to manage personnel, send messages as alerts, and more. The following interactions were usable on the above screen:

• Incident History button opened interactive page to view previous incidents

• Messaging button opened page to manage messaging, including selecting or defining user groups

• Schedule button opened page to manage personnel shift schedules, with a graphical calendar clearly showing staffing coverage based on user-defined minimum staffing needs

• Settings button opened menu page with various settings such as administrative, personnel management, managing additional displays, account management, and more

• Lock Display button removed all menu buttons, and changed to Unlock Display, requiring a password to unlock

• Incident display automatically scrolled left on a 10-second timer in a loop to show each active incident for a total of 30 seconds, to accommodate more incidents with non-interactive station displays

Lessons Learned: This project gave me the greatest freedom to explore the capabilities of interactive prototyping platforms. I was also able to learn specific capabilities of some platforms, such as Proto.io's ability to actually run a working mobile prototype on a mobile phone, allowing true mobile interaction. I also was able to explore Axure RP, Adobe XD, and Sketch to varying degrees. I've grown to appreciate the power interactive prototyping provides, and love setting up even small details such as responsive buttons to make the prototype feel as close as possible to an authentic application.

I also developed appreciation for the time requirements that may be necessary to add all of the additional detail, and developed an understanding of how to balance available time with detail included, adding the most important details for the prototype first, and filling out smaller details if time permits.

Finally, this also allowed me to more deeply explore variance in not only design, but function, between platforms and use cases, and account for interactions between all three platforms, such as easing agency account registration on first run using an agency-specific code defined in the desktop version by an administrator.