When conducting our heuristic usability evaluations by viewing our prototype through the nine principles of design lens our group discovered our application consistently deviated from six of the nine principles of design, namely,  be consistent, provide feedback, provide clearly marked exits, provide shortcuts, deal with errors in a positive manner, and provide help.  The three principle of design least relevant to our prototype are, simple and natural dialog, speak the user's language, and minimize user's memory load.

​

Be Consistent

As for deviations from the "be consistent" design principle, our prototype has not been optimized for running on varying platforms such as tablets verses smartphones.  Thus, when our prototype is viewed on a tablet buttons and popups sometimes become disproportionately elongated (e.g., Home screen Help sent popup, Nearest Safe Location screen Text box, Add Contact to Group screen top box).  Another common deviation from the "be consistent" design principle is our prototype's Cancel buttons sometimes lack any functionality (e.g.,  Set ICE screen, Edit Group screen, Set Group Permissions).  The layout of our prototype's Save and Cancel pairs are sometimes inconsistent.  That is, sometimes our Save and Cancel pairs are displayed horizontally as buttons (e.g., Set ICE Contact screen, Create a Group screen, Add a Contact to a Group) and sometimes our Save and Cancel pairs are displayed vertically as text (e.g., Customize Your EAS Alert Settings screen, Set Group Permissions, Settings screen).

​

Provide Feedback

As for deviations from the "provide feedback" design principle, our prototype deviated from this principle not only when our Cancel buttons do not work (see Be Consistent above) but also when Save buttons do not make it clear to users that changes have been saved after pressing these Save buttons (e.g., Customize your EAS Alert Settings screen , Set Group Permissions screen, Set PathShadow Permissions screen).

​

Provide Clearly Marked Exits

As for deviations from the "provide clearly marked exits" design principle, our prototype does deviate from this design principle throughout, however, most mobile applications do not include explicit exits because mobile devices contain application exit functionality implemented globally as part of their explicit navigations.  For example, any application can be exited on a mobile device by pressing either the physical Home button or the virtual Home button.  Thus, as designers of a mobile application we offload the provision of clearly marked exits to the operating system vendors.

​

Provide Shortcuts

As for deviations from the "provide shortcuts" design principle, our research did indicate users would appreciate incorporating some of the physical buttons on their mobile device as hardware shortcut buttons.  However, our prototype does not currently enable such hardware to software interfacing.  One solution we are still considering is adding a Home icon to each screen to allow users to easily get back to the Home screen using a single click instead of the two clicks currently needed to navigate using the Menu->Home set of clicks.

​

Deal with Errors in a Positive Manner

As for deviations from the "deal with errors in a positive manner" design principle, this is probably our prototype's least compliant aspect because our prototype does not currently contain any error handling mechanisms.  One of our most glaring instances is our prototype currently allows users to click the "I am Safe" button and receive feedback saying their message was sent even though the user has not yet created any Contact Groups to receive such messages.  Thus, as far as dealing with errors, remedying this shortcoming will rank high on our Phase 5 prototype's functionality.

​

Provide Help

As for deviations from the "provide help" design principle, it is true our prototype does not currently offer any in-app access to help information.  However, providing help is another under utilized design aspect across most modern mobile applications.  Thus, as designers we feel such information Help information would be available on our application's website instead of running the risk of cluttering up our minimalist design interface with novice-oriented Help information that quickly becomes an annoyance to those same users as they gain experience with our application.