You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 efficacy of that action. Moreover, after receiving users' feedback at the paper prototype phase, we decided to have less input parameters and allow more whitespace, and to change the logic of the interface to make it more intuitive to the user. For example, functions like itemize and split receipt that existed in earlier prototypes were taken out after the users found them confusing, and their benefit to the receipt classification wasn't significant. We also included auto-complete capabilities and keyboard input into the final design. Throughout the design, we emphasized simplicity in use, instead of having fancier or flashier visual cues.

Our final design was very tailored towards an Android phone platform and therefore it relays heavily on the back button. We decided not to implement a back button for most pages, instead relying on the back button from the Android phone. 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.

Following below are screenshots of the final design:

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. Since our visual affordances focused on simplicity, we heavily emphasized functionality, to make sure that our app could perform the necessary tasks that we had originally planned from the paper prototyping.

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 (yeah.. this is Karla...)

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 and Resolutions

  • Task 1 - Add receipt to an existing report
    •  
  • Task 2 - Submit expense report
    •  
  • 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

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. 

  • No labels