MoneyManager - GR3
>> Back to MoneyManager
Team members: Stephanie Chang, Qian Long, Isabella Lubin
Prototype Photos
Briefing
What is MoneyManager?
Answer: MoneyManager is a mobile app that allows students to create a monthly budget and enter their expenses so they can see how well they stick to their budget.
MoneyManager also allows its users to share their budget with other users. This way, they can show their parents that they are being responsible with their money.
Scenario Tasks
Task 1:
Register and create a budget with at least 3 different categories.
Task 2:
Enter several expenses.
Task 3:
Oh no! You make an error on the last expense. Fix it!
Task 4:
Share your budget with your parents.
Task 5 (only added in second prototype iteration):
Your brother Luke shares his budget with you. View a pie chart of his spending.
Observations
First Iteration
Task 1 (Register and create a budget)
All of the users were able to register quickly and without any difficulty. When initially presented with the budget creation page, our first user had trouble figuring out what she should type into each text field. We did not have labels on the fields, and had originally thought of putting default text into the fields, but did not prototype that feature. While the first user had initial learnability difficulties, her entries remained in the text fields (we had trouble erasing input between rounds) and other users were able to quickly grasp the purpose of each field.
Another issue that users ran into was in adding and saving budget categories. Some did not notice the “Add another category” or “Save” buttons and spent a good deal of time looking for a “Save and add another category”-type feature. Others were not sure whether the “Save” button was for an individual category or for the entire screen. Finally, several users pointed out the lack of a “Total Budget” field that would let them quickly view the sum of all their category allocations.
Task 2 (Enter some expenses)
Users generally had no trouble entering expenses in the first prototype iteration, although one user requested the ability to save expenses sequentially.
Task 3 (Edit an expense)
Users had trouble finding the screen to edit the expense. Although the budget summary page had arrows as affordances for viewing individual category details, most users did not notice these. When taken immediately to the category summary pages after entering an expense, or when they finally managed to navigate there, they were able to easily edit and save changes to their expenses.
One user noted that the tops of the budget summary page and the category summary page were identical, and that there could be potential confusion when using the app in real-time.
Task 4 (Share your budget)
Several users had trouble finding this feature. When we asked them to complete this task, users initially tried to view the budgets that had been shared with them by others.
Second Iteration
Task 1 (Register and create a budget)
The registration interface remained the same as the first iteration as no one had any trouble with that task. For creating a budget, we noticed a problem that there was no way to save the total budget field. Also one user said that it was inefficient to save each category individually and would rather save all of the data for all the categories at the end
Task 2 (Enter some expenses)
No changes were made to this task since the first iteration.
Task 3 (Edit an expense)
We added more some text affordances to help users click on the categories in the summary page. One user confused the “edit” label on the actionbar (used for editing budget) for editing an expense.
Task 4 (Share your budget)
Users had no trouble navigating to this feature because a button linked directly from the home screen.
Task 5 (View pie chart of a budget shared with you)
Users had no trouble with this task. This was a new task added in the 2nd iteration after we removed the feature that allowed users to track their budget over multiple months and added the feature to allow users to view a pie chart of their monthly budget and spending.
Prototype Iteration
The first paper prototype we chose to create was the third design we created for our GR2 - a design that we thought was straight-forward and learnable, while still being reasonably efficient and safe. When performing user tests, however, it became apparent that our UI lacked certain key elements, and that other components were confusing for the users. Our second prototype was modified in two main ways: new elements added to make the UI more usable, and existing elements modified to make the UI more learnable. Throughout our user testing, we also experimented with different screen flows (that is, when the user pressed save on a given window, where the user was taken). It became apparent to us as we were user-testing that the flow of screens can greatly contribute or detract from the learnability of our UI, so in our second prototype we tried to ensure that our UI was less screen-flow dependent and that the location for different user tasks would be clear from anywhere in the UI.
Our first round of users had a number of things that they all (or almost all) found confusing about our user interface. First, one of our tasks asked the user to share their budget with their parents. This sharing could be accessed through the “View” page - but a lot of users didn’t think to look there and instead got stuck, thinking that the “View Shared Budgets” clickable list on the home screen would somehow get them to the Sharing page. To make this more clear we changed two things: we changed “View Shared Budgets” to read “View Budgets Shared With You” (a bit wordy, but it did cut down on the confusion in the second prototype iteration), and we added a “Share Your Budget” button to the home page as well.
Based on user feedback, we changed what was originally meant to be a history of spending in different categories over time to be a pie chart showing what percentage of the total budget was being spent in each of the designated categories. We made this modification in response to user comments; one student reported that she would rather see a pie chart showing what percentage of her money she was spending in the different categories rather than when she spent it. Additionally, we tested one mother with the pie chart instead of history in place who said that she didn’t value the history of spending so much as she wanted to know how her child was budgeting out the given money - and if she was given her child a reasonable amount of money per month. A pie chart gives the parent an overall view of how the child is budgeting rather than the detailed view of expenses.
One feature we realized we forgot to include from other designs is the initial input of a total budget. Users didn’t seem to specifically notice the lack of this input, but including this in our second prototype allowed us to give users better feedback about how much of their budget they had designated as they created categories and gave each category an amount which was something that users in the initial round of testing did want. Hand in hand with this total budget area, one of the more important features that users wanted was the ability to save individual categories as they designated them for their budget, so we implemented this as well in the second round of our prototype.
A number of users also had difficulty finding where they should go to edit a previously entered expense on which they made an error. We added more affordances for the users to click on category list items in the summary screen, such as more visible icons with supporting text to make them more clickable in our second prototype to fix this problem. We also added more affordances for users to click on each row of the table in the category detail screen by adding pencil icons (indicating edit) to each of the rows. These additions improved the learnability of our app.
One feature that we experimented with was how users created/edited their budget. In the original prototype, in order to create a budget, users input individual categories along with their respective amounts one by one and then saved everything at the end. However, during user testing, some users were confused by this because they did not know whether or not the data was saving after inputting each category. In our second iteration, we changed the interface for this task so that each category and amount was saved as soon as the user input them. The results of this were also mixed because confirming and saving each individual category took more time for users. This is a tradeoff between efficiency and safety that we will decide on for our final design.