...
Screenshots: (1) Welcome screen; (2) Registration; (3) Log in; (4) Home page; (5) Create/modify budget; (6) Enter income/expenses; (7) View budget as summary list; (8) View budget summary details; (9) View budget as graph; (10) View budget history; (11) View budgets shared with you; (12) Share budget
Walk-Through of our Scenario for Design 1:
Luke logs into the moneymaker app and is greeted by screen 1. He selects register, and is lead to screen 2. He enters his email (skywalker@imperial.edu) and creates a password, then selects register. He is lead to screen 4, where he selects “create/modify budget”. He is then lead to screen 5. In the budget per month box he enters $300. Under the “food” category he enters $175, under clothing he enters $75, and he adds a new category that he calls “recreation” and assigns $50. He selects “Save Budget”, which returns him to Screen 4. On Screen 4, he selects “Share Your Budget”, which leads him to Screen 12 - he enters his father’s email iamyourfather@deathstar.com and hits share (Vader ignores this email for a while). Luke quits his app. Periodically throughout the month he adds his new expenses by signing onto the app (which brings him from Screens 1->3->4), clicking on “enter income/expense”, and adding the expense in screen 6 by clicking Expense, selecting the appropriate category, entering the amount, leaving the “Recurring” setting as “Once”, and clicking “Add to Budget”.
When Luke spends too much money at the Cantina, he logs into his MoneyManager app (Screens 1->3->4) and selects “Create/Modify Budget”, which leads him to Screen 5. He re-allocates his budget, allocating “Recreation” $70, “Clothing” $55, and “Food” $175. He then asks his father to give him more money. Vader decides to finally check out his son’s budget before making his decision, so he creates an account (Screens 1->2, which lead him to 4). He then selects View Shared Budgets, and clicks on “Luke’s Budget”, which leads him to screen 7. From screen 7 he navigates around by clicking in a variety of places - he clicks on “Food”, which brings him to Screen 8 where he views a detailed list of his son’s spending (he then clicks “Return to Main List” to go back to screen 7.) He clicks on “Graph”, which shows him Screen 9, a more visual view of how much Luke has spent and has left in each of his categories. Finally, he clicks on History, which shows him how much his son has spent in the different categories in history (since his son has only used the app for one month, this graph would only have a single point for each category and would thus not be very interesting.) Vader decides to give his son an extra $50 this month, and tells him so. Luke logs into his MoneyManager app (Screens 1->3->4) and selects “Enter Income/Expense”, where he changes adds $50 as a one time income and credits it to his food category.
Analysis of Design 1:
This interface is very learnable, which is particularly good for the parents who might be viewing their children’s budgets. All of the basic options are located on the home screen, so it’s easy to see all the functionalities of the app (in screen 4). All of the screens are maximized for view. There’s little clutter, and the very basic amount of information is displayed before you expand for more detail (in the case of going from screen 7 to screen 8) which means that beginning users wouldn’t be overwhelmed. Most of the things in the UI that are meant to be clicked on are clearly clickable and are consistent with other UIs, which again means good learnability.
This UI involves a lot of screen navigation (the path to view another person’s shared budget alone requires you to go from screen 4 to screen 11 to screen 7 to screen 8, which is particularly non-ideal because it’s the path that’s going to be used the most by parents who may not be very experienced using mobile apps). This makes the UI inefficient; the experienced students also have to go through a long process to enter expenses, which is something they’ll likely be doing often, and they can only enter one expense at a time which slows down the process even further. Thus, although the interface is very learnable (good for our new app user group of parents), it’s not efficient which is bad for our experienced student users.
This design also has a few safety problems. There’s no way to back track and edit (or delete) an expense - although there’s a confirmation message when you enter an expense, this still allows for poor error correction for something that someone might want to be correctable (although lack of correctable has its advantages for protecting against students who might try to fiddle with their expenses after the fact). One major problem in this model is that the distinction your budget and a recurring income is not particularly clear so a user could get confused about what to enter where - the ability to enter income was intended to allow students to keep track of their savings, but in other iterations we decided that this made the model too confusing and that we should focus on budget. We intend to ask users which they value during user testing.
The design prioritizes learnability over safety (poor error correction) and efficiency (lengthy navigation), which makes it better for parents who don't know how to use apps and don't mind extra navigation if it's easy to follow, but not as good for students who want to do things quickly.
Design 2
Screenshots: (1a) Welcome and login; (1b) Welcome and registration; (2) View budgets / home; (3) Create/modify budget income; (4) Enter new income/expenses; (5) Edit old income/expenses; (5a) Edit individual expense popup; (6) View budget for current month; (7) View budget history; (8) Share budget
...
Screenshots: (1a) Welcome and login; (1b) Welcome and registration; (2a) Home screen for users without a budget; (2b) Home screen for users with a budget; (3) Create/modify budget categories; (4) Enter expenses; (5) View summary of budget; (6) View expenses for specific category; (6a) Edit individual expense; (7) View budget history; (8) Share budget