High Fidelity Prototype Presentation Red Team

Requirements

Summary We are building an application that will assist Service Writers at the Gene Harvey Chevrolet car dealership with preparing Repair Orders. This system is being designed to replace the outdated system currently being employed there.

Why the need for an upgrade?  The current system is DOS based and runs in an emulator  Vehicle histories are unavailable from within the Repair Order creation screen  There are places within the program where actions cannot be cancelled  The current system contains fields within it's screens that are not required  Employees must memorize service codes  There is no way to look up codes

How will we meet these requirements?  The new system will be a native Windows application  The Service Writer will be able to open multiple windows from the root menu  Improved navigation over the current system  They will be able to cancel any action  The system will be streamlined to only require the information which the Service Writers require  Codes will be made available through the new interface

 The new system  The old system A Comparison

Design Development

Design Artifacts  Flow charts  Wireframes  Low fidelity prototype

Flow Chart  The finalized version of our flowchart

Wireframes  This is an example of the wireframes that were drawn up after the flowchart was finalized

Low Fidelity Prototype  From the wireframes a low fidelity prototype was produced to present to the customer for feedback  Once we had gotten feedback from the customer, we were able to refine our design

Design Highlights  Streamlined Windows application  Multiple windows supported  Data-entry trimmed to necessary information  System supports cancelling of actions and editing  Additional information can be provided to the user (codes) ‏  Function keys and tabbing to encourage use of the keyboard

Meeting Design Principles  Proximity and Alignment Principles  Related items are logically grouped, aligned and separated from other information visually  For example, information on the RO screen is grouped by customer and vehicle  The tab order for fields and buttons flows in a top to bottom, left to right sequence  Simplicity Principle  All fields are clearly marked with the same labels as the previous system

Meeting Design Principles continued  Contrast Principle  Primary action buttons like Search and Save are set apart from other buttons  Repetition Principle  Search screens all follow a similar format  Regularization Technique  The program is designed to resemble common Windows applications

Meeting Design Principles continued  Fitt's Law  On the root screen, the action buttons dominate the page  Tolerance Principle  The user is able to visit previous screens, edit information and cancel actions

Usability Test Plan

What will be tested?  How quickly a user can enter an RO  Draw a direct comparison between the current and new system  Improved navigation  Tests the ability to navigate through the system, edit information and cancel actions  Function keys and tab layout  Function keys and tabbing will allow the users to perform actions without having to use the mouse  Users will be able to open multiple windows, such as the RO creation screen and the vehicle screen

Results Analysis  Result from time comparison will let us know if our new system is comparable to the current system  Comparing the navigation between the two systems will tell us if the user thinks our design is an improvement and is less frustrating  Testing the tab order will also tell us about the ease/difficulty of navigation

Results Analysis continued  Testing the cancelling and editing functions validates that the user can back out of any action  Testing the function keys will tell us if the user has trouble locating and using them  If they use the mouse at any time, we can inquire as to why they preferred the mouse over the function keys and tabbing

Obtaining Participants  Gene Harvey currently employs four service writers  We plan on testing the system with at least two of their service writers  We will coordinate times when we can meet and perform the tests with the selected users

Demonstration