...
The design of EZ-FIX allows housing managers the ability to quickly process and assign jobs to the house mechanics (mechanics in this context refer to anyone employed by the facility staff for repair related purposes). EZ-FIX was designed to allow users (house managers) to easily filter and view information about repair requests, known by our system as jobs. As seen in the image above, a user is able to filter jobs by clicking in the left-most column, view a listing of jobs in the middle column, and view specific information about a selected job in the right-most column.
During initial user testing of our computer prototype (both the heuristic evaluation and in-class demo) we received feedback that the color choice should be re-examined. Some people felt that the red of the buttons signaled importance or error. As it is true that red is usually used to signal error or importance, we felt that the application had a general red look and feel; there is enough red on the page (logo, all buttons, shadow, etc) that the red does not pop out to the user and look as if it requires attention.
...
One major design decision that was influenced by the heuristic evaluation is the stucture structure of the middle panel. Initially the jobs listed in the middle panel were grouped into three different categories: unassigned, assigned, and completed. This allowed the user to quickly discern the status of a repair job and find unassigned and assigned jobs quickly and efficiently. We found this to be an issue during the heuristic evaluation, though. It became a problem trying to keep a consistent layout with a varying number of jobs in each section; listing all jobs in a group didn't work well, fixed heights of each group didn't work well, and finally hiding empty groups (zero jobs) didn't work well. For this reason, we pivoted and build the middle panel to list all jobs and provided labels to allow the user to discern job status. Every job is listed and has a colored label used to indicate the status of a job (green = assigned, blue = unassigned, orange = completed). Job assignment is indicated with a picture of the mechanic responsible for the job if it has been assigned or completed, otherwise the picture is default which . This allows for quick scanning of mechanic's jobs.
There are different events that trigger a job to be moved to the top of the job listing. Creating an update on a job moves the job to the top, while assigning a job or marking it complete does not. Typically an update on a job happens by someone else (the mechanic) and indicates some form of status change (need for materials, etc). Assignment of a job is done soley solely by the house manager and since he is making the change, it's not important that the job be moved to the top for more attention.
...
Another design stemming from the heuristic evaluation was the consistency of the right panel. Initially the design had action buttons (mark complete, assign, submit update) on both the left and right sides of the panel. Additionally, these buttons were not all the same style -- two were red while the mark complete button was default and looked very out of place. The purpose of this was originally to not attract as much attention but it seemed as if this back fired backfired as most users noted this as a major area for improvement. As seen in the screen shot above the right panel was improved to be more consistent and streamlined. The mark complete button took on the custom styling, the assignment widget was improved to be more streamlined with more safty safety (unassignmentun-assignment), and the submit button for updates was moved to the right side in order to maintain consistency.
The location and contact information of a job is smaller than the description. This was done to offer a squint differentiation and visually differentiate the information. When a house manager looks at the details, he is interested in the details. While it's important that he knows the location, it's not the biggest concern when assigning a mechanic to the job. Ideally the manager can quickly scan the job, assign it and move on. The granular location data (floor, room number, etc) is more imporant important for the mechanic responding to the job. The house manager can quicky quickly scan the information and that's what's important.
The assignment and un-assignment of jobs is an integral part of our application. It's important that this feature is very simple, yet gets the job done. Assignment is easy, choose a mechanic and click assign. The more interesting case is how to un-assign a job or re-assign it to someone else. Ultimately we went with a simple assign and un-assign. If a job is not assigned, it can be assigned by choosing a worker and clickign clicking "assign". If a job is assigned, it can be un-assigned by clicking "un-assign". We considered a re-assignment option but this ultimately looked and felt overly complicated. In the case a user actually needs to re-assign a job, they can simply un-assign and re-assign the job.
...
The clean separation of concerns of our front end code allowed changes and new features to be quickly built. The typical flow is: a user makes an update to an existing model instance (stars a job, adds a label, creates an update, etc), the client side code calls the appropriate mutator method on the object, the mutuator mutator method takes care of persisting the change by updating Firebase, finally the view renders the updated instance. The simplicity of this flow allows for additional features to be very easily implemented by simply adding the corresponding model methods and view changes.
...
EZ-FIX is designed for housing managers, as such it is ideal to do user testing on them. Unfortunately, the semester wrapping up and Bexley hall closing has consumed resources and we were only able to do user testing on one house manager. This specific house manager was part of our initial need finding and was familiar with the problem we were trying to solve. In addition to the one house manager, we were able to test one professional staff and two student desk workers. The professional staff is close to our target user population because she is responsible for contacting various services (elevator and plumbing repair) for jobs within McCormick Hall and cares more about the overview of the facility status. Finally, student desk workers were chose and the closest alternative because they are sometimes faced with repair requests and are well informed of the building status. We noticed that the users had different technical abilities. Some users were familiar with google mail Google Mail while others were not. While this didn't affect the user's ability to test our system, it did have an effect on the learnablity of learnability of various features (starring for example).
Users were briefed by being told of the problem -- that house manager have a difficult time organizing and prioritizing repair requests and the primary method for doing so it by making mental notes. They were told that they are acting as the house manager of McCormick hall and were not given a demo of the application. They were asked to speak aloud and especially note things they find confusing or visually unappealing so that we could get a better sense of the problems that they experience. A demo was not given because we felt that showing users how to perform different tasks would prevent us from finding learnability issueslearnability issues.
Users were asked to perform the following set of tasks, one after another. In certain cases they would hit other areas of the application that were not being explicitly asked for. For example, some users would create a label for "important" jobs, while others would use the star to signify importance. The database was dumped and reloaded before each user session as an effort to control user testing.
...
Using an iterative design process allowed us to build a little; get some feedback; make changes, improve, and build more; get more feedback; and so on. It gave us the opportunity to work with users and make smaller changes along the way instead of needing to make larger changes and redo large parts of the implementation process as might be necessary if using the waterfall model. Using an iterative design process forced us to think about the user at all times, and this resulted in a highly usable interface.
Paper-protoyping prototyping was useful to us for several reasons. Users didn’t have much time with the prototype so the best feedback this type of user testing gave us was on learnability, a huge part of usability. Giving users specific tasks to complete allowed us to gain insight into the user’s understanding of the system before getting to know it well (i.e., how they expect the system to behave). Also, we didn’t need to worry about the exact shape or color of particular features; we could focus on size and location of individual features as well as the overall layout of our interface. Additionally, it was exciting to see users successfully complete tasks during the paper-prototype user testing sessions, and this motivated us to actually include those relevant features in our implementation. On the other hand, seeing users struggle with certain tasks motivated us to find good solutions to those problems.
...
If we were to do this project again, there are a couple things we could do differently. One, we would have thought more about how to incorporate categories like job type (e.g., plumbing) and dorm name (e.g., McCormick) into our design during the paper-prototype stage. We focused more on getting the general layout of our interface figured out before including this extra feature, and it turns out we didn’t implement filtering by job type or dorm name until much later in the process (during the final implementation), so our only chance to test this filtering feature was during the final user testingstests. It was a little stressful when we tried to incorporate this filtering feature toward the end of the implementation process. So much of the design had effectively been made concrete at this point and there weren’t many options for how to incorporate the filtering or many locations for where to include the filtering elements (we were a little unsure where to include the dropdown for adding a label to a job). If we had thought about this major feature of our design earlier perhaps we could have better incorporated it into our design and we could have gotten more user feedback. A second thing we would have done differently would be to conduct more user testing along the way of individuals in our user population (i.e., MIT dorm house managers) instead of just students. Unfortunately we didn’t have easy access to house managers, but if we had, it might have been nice to get feedback from them more often.
...
The focus of building this application was to fit our users core needs; allow them to get done what they need to get done. In this process, we avoided feature pollution and considered adding new features only as soon as we completely fleshed out the current ones. Moving forward, there are a few features we would like to incorporate that will help improve safety, efficiency, and learnablitylearnability. Adding in these features would bring the application to a very complete, production-ready level. While the application is really a minimum viable product, there are enhancements we would have liked to add given more time and resources.
...
More information could be included in the job creation dialog. It might be the case that the house manager knows who he would like to assign a job to during creation and he should have the freedom to do so. This could be used as a source of learnablity as learnability as well -- it could ask if the job is important with a star next to it. This would allow a user to learn the fact that star means important opposed to applying their own meaning to the star Just a note: this would only work if it were done early on, before the manager builds his own meaning for stars, etc.
Another small improvment improvement would be the addition of an "Active" tab. It's reasonable to assume the house manager is more concerned with "unassigned" and "assigned" jobs than with "completed" jobs. For this reason, a filter that shows only "unassigned" and "assigned" jobs would be added. More need - finding and user testing would be done to asses the valididy of validity of this assumption.
Finally, it would be nice to alter the update widget to be more inclusive of job activity and perhaps change it to an activity widget. It's probable the house manager would like to know when he assigned a job, when (and maybe why) he re-assigned a job, etc. More need - finding and user testing would lead us to implementing this to accomodate the accommodate the house manager's needs but it seems as if this would eventually be implemented given more time.