...
Team members: Stephanie Chang, Qian Long, Isabella Lubin
Designs
The following table shows screenshots from our app:
| | | |
| | | |
| | | |
|
|
|
|
...
Screen 7) During paper prototyping, many users expressed the wish to add multiple expenses at one time, so we added this feature to our final design. After saving all expenses, users are returned to the budget summary page. Although one heuristic evaluator thought that it would be better to reset the expense form to one blank expense, we decided that users might become confused, think that we simply reset their form without saving their expenses, and try reentering all of their expenses. By redirecting the user and showing a toast message (pop up text) indicating they have saved their expenses, they will be able to see that their expenses have been saved.
Screen 13) Since the screens for viewing your budget and for viewing someone else’s budget look very similar (especially since our implementation of viewing someone else’s budget was shallow and the data shown remained the same), we added a brief popup/alerts (toast messages) informing the user to whose budget is currently being viewed. This message fades away after a few seconds, but when viewing someone else’s budget, their name also shows up in a header at the top of the screen, and persists until the user returns home.
Implementation
Details
We implemented the application with a model-view-controller design that naturally comes in the Android framework. The views are the xml files that defined the widgets and layouts of each of the screens of our app. The controller is made up of listeners in the Activity class that takes in user input and modifies the database and views based on it. The model consisted of two classes: Category and Expense. We stored all the the data locally on the phone in the built-in SQLite database to store user data in tables. We had two tables in our database, one for categories and one for expenses. The controller takes user inputs and modifies the database based on the input and also puts in the data to display in the views.
...
- In the Share screen, clicking “share” doesn’t actually share your budget with the email address you entered.
- In the Chart screen, the pie chart is static.
- When viewing budgets shared with you, the data doesn’t actually change to the other person’s data.
Evaluation
User Testing Procedure
When conducting the user tests, the administrator of our group first gave a briefing of our app (see briefing section below). Then the administrator gave the users the tasks one by one. The designated observer observed the users as they performed the tasks, asking them to think out loud. The observer took notes on what they did and what they said. Afterwards, we asked them for their comments on what they liked and what confused them.
...
Usability Problem | Potential Solutions |
|---|---|
1. “Save” button in expenses was confusing for two of the three users at first. They did not realize that you could save many expenses at once and tried to save each expense sequentially (although caught on quickly) | Change the text of the button to “Save all” to increase learnability (what’s really interesting here is that this wasn’t a problem in paper prototyping, because users seemed to notice the “add another category” and deduce that the save button was for saving all the categories. We should have done a better job of understanding the root of the confusion, rather than just doing the easy fix). |
2. Toast messages that appeared when switching to viewing other’s mode and viewing your own did not provide enough feedback. 2 users said they did not notice it at all, the other instead noticed the text at the top of the screen. | Make the header text saying whose budget the user is viewing (user’s or other’s) more apparent, though this would give a large and potentially irritating header to the screen. Could also flash a popup window as soon as the user started viewing someone else’s budget, rather than a toast message, which would be clearer (as it would be both larger and with a different color background). |
3. The icon that lets users edit their budget total is not extremely noticeable. One user wanted to change his total, but had trouble figuring out how to change it. | Make the icon bigger. |
4. Category picker text is too small. | Increase the text size (a reasonably easy fix). |
5. When viewing someone else’s budget, the header in the category page still says “select row to edit”. This was confusing to the user because you shouldn’t be able to edit someone else’s budget. The icons are disabled, but that text makes it confusing. | Remove that instruction when viewing someone’s budget. |
6. Pressing back more than two or three times (depending on the screen) brings user back to login screen, which was confusing. | This is a minor implementation bug that can (and should) be fixed in the next design iteration. |
7. The Expenses tab was hard to find for 1 user (although the other two did not have difficulty). | We could try a different grouping of the tabs, maybe putting expenses in the 2nd layer, and use A/B testing to try to determine which is better. We can also try different icon designs for the Expenses tab to see if that would be more learnable. |
8. One user thought you could edit an expense from both the summary screen and the edit screen | Change the label of “edit” to more explicitly state that it was an edit budget tab, not an edit expense tab. |
Reflection
The iterative design process was an incredibly interesting and unusual experience. As much as the instructors tried to impress on us how important it was to consider our user population and design the app for their use, each round of design and testing revealed new problems that users ran into with our design. We became so familiar with what the app was designed to do and how to navigate it that we had increasing difficulty separating ourselves from the model and understanding what user needs were as we went further and further into the design process. We became very attached to a particular style of the app fairly early on, and playing around with different prototypes in the paper prototyping and design stages could have resulted in a more innovative app.
...