Design

The final design of the TrackIt interface has a similar look and feel to the computer prototype from GR4. Many of the storyboards and screenshots from GR4 are still applicable to the final design. 

One key decision we made was to have the start screen be the screen where the user takes a picture of the receipt. While that had an impact on learnability, as some users found it hard to navigate from the start screen to "show statistics" or "manage reports", entering a receipt is the most common action done using the interface, and therefore we prioritized the efficiency of that action. Moreover, after receiving users' feedback at the paper prototype phase, we opted for fewer input parameters and allow more whitespace, and changed the logic of the interface to make the interface more intuitive.  For example, functions like 'itemize' and 'split receipt' that existed in earlier prototypes were taken out after users found them confusing. We also included auto-complete capabilities and keyboard input in the final design. Throughout the design phase we emphasized simplicity over flashier visual cues.

Our final design was very tailored towards an Android platform and therefore it relys heavily on the 'back' button. We decided not to visualize a back button for most pages, instead relying on the back button on the standard Android phone interface. This design decision cannot be made for an iOS implementation and has also caused some learnability difficulties for users who are used to other phone platforms.

Implementation

As discussed below, the TrackIt interface is implemented using the Android platform. Based on the style of Android programming, the views and functionality are separated into their own files. Each screen in our interface occupies its own file, and we made use of some custom classes to handle distinct database and process capabilities. We relied on Android 2.3 (platform level 9) for the final version of our interface and consistently tested the app on this version. For the back end, we took advantage on Android's native support for SQLite and did not have to install a third-party database system on top of our app or use text files to store relevant information. Our visual affordances focused on simplicity and functionality rather than complexity.

In some cases we ran into implementation challenges, as the standard Android widgets and menus did not always match the ones we designed in the paper prototyping phase. As a result, parts of the interface, such as the date and time picker and the drop-down menu appears different on the application than in the paper prototype.

Due to the Android version we used to implement the application, we need an emulator to run the application, and cannot load it on a real Android device. On the emulator, the application takes a long time to load and runs slowly and this might have an affect on the application's perceived efficacy.

Evaluation

Our application targets young professionals who are either self-employed or working for a company and travel for business often. We choose three of our friends that we felt best fit this description. We wanted our users to have sufficient experience in submitting expense reports, but no prior user interface design knowledge. 

Our three users for the final tests were:

1. 28-year old female, working for retail computer manufacture

2. 29-year old male, business school student and entrepreneur 

3. 27-year old male, working for a large consulting company 

Since the users we picked already have some prior knowledge about expense reports and receipt management systems, we choose not to use a demo and simply repeat the process we used for the paper prototyping assignment. We used a facilitator and one or two observers. 

Briefing

Below is the briefing text given to each user during the testing phase (it is the exact same one as used for the paper prototype testing):

Dear test subject!
Thank you for participating in the prototyping testing session for TrackIt.
TrackIt is a receipt management tool that allows you to create expense reports, scan and classify receipts, add receipts to expense reports, and submit expense reports to your boss.
In this test, you will create and edit expense reports and help us test the usability of our interface.

Thanks!

Our UI group – Bryan, Eddie and Liron.

Tasks

Below are the 4 tasks that were handed to the users through the use of index cards (these are also the exact same as used for the paper prototype testing):

• Task 1 - Add receipt to an existing report
  • You are in the middle of your business trip to Rio de Janeiro. Last night you took a client to “Rio Scenarium” and paid for drinks.
  • This morning you want to add your receipt to your expense report of the Rio trip.
  • Scan (take a picture), classify and add your receipt to your Rio expense report. Then save and close the report.
• Task 2 - Submit expense report
  • Your last trip to Toronto, Canada, is over, and now you wish to submit your expense report to your boss.
  • Find your old “RIM Toronto” report and submit it.
• Task 3 - Edit amount on old receipt
  • You just realized you classified the wrong amount on your last purchase trip to Toronto.
  • Find the old purchase and edit the amount.
• Task 4 - Show statistics
  • Find how much you spent on food on business trips to RIM locations this year. Generate a report and send it to yourself

Usability Problems Found

• Task 1 - Add receipt to an existing report
  • The user was confused by the task description, since we didn't actually implement the camera functionality - cosmetic; would be resolved were camera functionality implemented
  • The drop-down menu was very clear and the user commented that she liked it 

• • No currency signs; cosmetic - we can fix this one
  • At the end of the task, one of the users submitted the report instead of saving it; major - there shouldn't be confusion about this and we need to make the distinction clearer
• Task 2 - Submit expense report
  •  The user needed to look at the receipt again to recall the amount and date on the receipt and used the photo icon to do so, she was pleased to have that functionality
  • Since the date, vendor and amount were already on the receipt, the user wondered how come the interface doesn't auto populate those fields
  • The user was confused about the difference between report date and receipt date; minor - this would become clear with use and is important to the people who approve these reports
  • The reports did not look like they would be clickable so the user wrongly clicked on "Spending Reports" instead of on one of the reports; minor
  • The user was surprised that there was no submission confirmation after submitting the report; cosmetic - this would be implemented on a full system ( where submission to a home system actually happens)
  • One user wasn't sure how to just look at the reports without submitting a new receipt; minor - we should make the functionality to manage reports easier to recognize
• Task 3 - Edit amount on old receipt
  • For two users, the receipts didn't appear like they would be clickable, so there weren't sure what to do; major - this became a technical limitation, we weren't able to create the behavior that we wanted in these listings.
• Task 4 - Show statistics
  • One user commented the task was very clear and straightforward
  • One user wrongly created a new report instead of looking at the old ones; minor - this mistake can be corrected by the user.
  • The wording is confusing, need to have a clear difference between expense report and statistics reports; minor - should be easier to tell the difference, but can be easily backed out of.

Optional Solutions

• Change the appearance of the list items both for the report list and the receipt list so that it is clear that they can be clicked
• Change "date" wording to "receipt date" and "report date"
• Add "toast" widget to say "report sent to ..." after submitting report to give the user indication that the report was sent
• Implement camera functionality
• Change "spending reports" to "spending statistics"
• Make the "manage reports" button larger

Reflection

During the course of this iterative design process, we learned about opportunities for future improvements when following this process. First, we should have tried as much as possible to familiarize ourselves with the Android platform, as we had to do that while we were working on each iteration of our design. We should have learned from the tutorials and other reference first before even designing the initial prototype. Our lack of knowledge and experience in Android definitely caused longer time to be devoted for bug fixes than was probably necessary. Thus, we could have been more efficient during each iteration had we been more prepared initially for the undertaking of this project.

Second, some of our initial designs where inspired by features in the I-Phone interface, which made their implementation more complicated, and forced us to change some of the design during the implementation. In retrospect, we should have kept the planned implementation in mind even at the design phase, and base more of the design on standard Android menus. 

The iterative design process proved to be very valuable, as it allowed us to see substantial and evident progress in each iteration of our design. Each design, through paper and computer, became more robust and clear, and this gave us a proud feeling, knowing that we have made progress to the initial goal for the project.

From the storyboarding to the final user testing phase, while some featured have changed and the logic of the interface was improved, we have also maintained much of the initial design. We maintained what we had planned out to do from the beginning, and did not deviate much from the initial plan.  If we had to do these assignments again, we probably would have taken greater risks and experimented with more unconventional interfaces, to see if they happen to work better. We could have also taken a more radical approach when relating to the users' feedback and make more significant changed between each UI design iteration. 

Additionally, while we ended up not implementing some of the more advanced featured we originally planned for.  We are happy with our decision to prioritize simplicity over advanced features.