...
When Luke spends too much money at the local cantina, he logs into his MoneyManager app (screens 1a->2b) and selects “View Your Budget”, which leads him to screen 5. He then selects “Edit”, which takes him to screen 3. 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 1a->1b->2a). He then selects “Luke’s Budget”, which leads him to screen 5. Within screen 5, Vader can expand a particular category to see detailed expenses in that category (he can then also collapse that category to simplify the view). From screen 5, Vader navigates over to view the history of Luke's expenses by clicking on “History”, which leads to screen 9 (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. Since this is a one-time income and Luke should not count on this extra money in his monthly budget, Luke does not adjust his budget.
Analysis of Design 3
This design incorporates much of the efficiency from Design 2, with some added features. The UI emphasizes adding new expenses as a separate task, as tracking expenses is most important to the student user and it should thus be distinct and easy to find. The home screen for the returning user features entering expenses and viewing budgets (included shared budgets) - this feature emphasizes what both our student and parent user groups value the most, so increases the efficiency of the UI. The user can again edit all previous expenses and can change both who can see his budget and whose budgets he can see, which makes the UI much more safe. This UI also incorporates cancel options for many of the editing tasks, which makes the design more safe. Learnability is somewhat increased in this design over Design 2 (with the very notable exceptions of sharing and editing a budget); important features have very clearly labeled buttons and textfields.
Some features of the interface, such as the share feature, may be less learnable. The share feature is accessible only from the main “view” budget screen (Screens 5, 6, 7, 8), so it is not apparent that this feature exists when the user first enters the app in Screen 2. The path to edit your budget (which you do after entering the view mode) is not obviously clear and is thus not very learnable - we made this decision because a user will likely not edit his budget often, but it still could be improved. Screens 5 and 6 present something of an efficiency problem for returning users because they display a large amount of data to scroll through - the user's desire for this data is not yet clear to us.
This UI removes the idea of income or recurring expenses. We’re not yet sure how important tracking rollover budget is for users, or if they would want to be able to set up recurring expenses like the rent or enter rent each month as they write their check. We think that perhaps the ability to setup recurring expenses and income make the user less careful with how he tracks his budget. For example, if you track your net balance instead of how closely you’re sticking to your month budget, you might overspend but not really see that it’s a problem, or if you enter rent as a recurring expense you lose the act of physically entering it in each month, which naturally reminds you that you’re losing that money. The idea of keeping a rolling “balance” and recurring expenses are definitely two features we believe need to be explored in user testing.
To summarize: this design is designed to emphasize the tasks that we believe both of our user groups value most - entering expenses (students) and viewing someone else's budget (parents). In an effort to design the UI to emphasize those features, we made some interesting design decisions that increased the learnability and efficiency of the UI in some places and decreased it in others. Overall, this design is the most safe of our three designs, but extensive user testing is needed to see if the decisions we made about which parts of the tasks are important were the correct decisions.