Bugs
I don't want to count these as issues since there isn't much insight here, but I still wanted to point out some bugs I came across while playing around with the app:
- It's possible to add an expense without selecting a user, which crashes the whole site
- The "Joint Paid for Me" selection incorrectly computes how much you owe. It says says you only owe 1/4 of the expense amount, instead of 1/2
- My data doesn't actually save to GitHub so it is lost after refreshing the browser
Issue 1
The table lacks some important clarifying information. First of all, it should specify that all the amounts are in USD since the labels (EUR) and (GBP) are likely to make the user think the amounts are actually using that currency. Additionally, payments from the joint account are represented in the table the same way as a payment by both Neo and Trinity. This is a problem because it can be unclear which account paid for an expense, and therefore which account needs the cash back. For example, suppose they pay a joint expense for $100. They may use their joint account to pay for the expense, or they may each chip in half the money from their personal accounts. Both of these entries would look identical in the table but really represent two different scenarios. Both issues with the table deal with Nielsen Heuristic 5: Visibility of System Status.
Issue 2
If I'm Neo and I want to report a payment for Trinity using the joint account, I have one of two long and confusing options, which is not good for a common case:
- Deselect "Joint Paid for Me", select "Both Paid", and then enter the expense amount as if we each chipped in half from our personal accounts. This runs into the same issue as above, and is also dangerous since I may incorrectly divide by two when splitting the money.
- Use the "Expenses tracker for Trinity" instead, select "Joint Paid for Me", and then enter the expense amount since the app thinks I'm Trinity. This is dangerous because all the references to "me" will actually refer to Trinity, which is misleading, and if I also want to enter more expenses after, I may forget to switch back to "Neo".
This is an issue with Nielsen's Heuristic 7: Error Prevention, since there are many ways the user could potentially make an error while entering in a common kind of expense.
Issue 3
The two checkboxes should be moved near each other and should not depend on each other. In other words, I shouldn't have to uncheck one box, then move my cursor all the way down the screen to check another, and then move all the way back to the top to enter in the two amounts. The fact that "Joint Paid for Me" and "Both Paid" are mutually exclusive is a good indication that they should be radio buttons instead. There can be a third option to encompass the case of neither box being checked. The dropdown which only appears when "Joint Paid for Me" is unchecked should also be moved these new radio buttons since they are related and to follow the graphic design principles of proximity and grouping. Above all, the checkboxes are an issue with Neilsen's Heuristic 6: Flexibility and Efficiency, since it feels way slower than it should to enter expenses paid by both people.
Issue 4
Some inputs persist after clicking "Add Expense", while others reset back to the default. Specifically, it seems things below "Additional Info" reset, while everything else stays the same. While there is some attempt at consistency, it's still confusing because changes to one affect the other. For example, when "Both Paid" gets unchecked, it makes the additional expense field disappear. I also think it's confusing for a user to remember which things stay and which things don't because the grouping of date, currency, and both paid is pretty artificial. This makes it likely that a user accidentally puts the wrong date or currency because they may forget to enter the right value again. Thus, I would flag this issue as both Nielsen's Heuristic 8: Recognition not Recall, and Heuristic 2: Consistency and Standards. I think this inconsistency would best be solved by either making everything reset, or making everything stay. For efficiency, I would probably lean toward making everything stay. The one exception would be the expense amount and description, where I would suggest grouping them separately so it's clear they are the only ones that reset.