4 Issues in 4 Distinct Nielson Heuristic Categories
-
Catastrophic: User cannot edit added expenses (user control and freedom/flexibility and efficiency)
Once an expenses is added to the table, there is no way to edit the expense. This limits users control and freedom because to undo this process. If a user makes a mistake, instead of having a simple and efficient way to edit an expense, they will have to recopy the expense and then changing the values that are wrong and then add the expense and then delete the old expense. This may leave users feeling stuck and frustrated and is definitely not efficient which we can see through a KLM analysis.
One recommendation is to make the table a table of HTML inputs so that the values can be changed after they've been added to the expense log.
-
Major: User may add an expense without filling out all forms (error prevention)
A user can add an expense without anything preventing them from doing so. While this may not exactly be an error (for example, you may not have the exact receipts on hand at the moment of entry but you want to input the expense to remember it), this is not helpful given problem 1 where there is no way to edit the expense. Thus, you wouldn't want to allow a user to input an expense without having the necessary and valid information because otherwise they'd have to reinput the expense and delete the old one.
One recommendation would be to have some sort of feedback, like denoting the empty fields with a red border, a popup, or a div that says to fill out all the information which will show up when you try to add an incomplete expense.
-
Major: It is unclear what the computations done in the table are and it's not efficient to back compute (recognition not recall)
When expenses are added to the expense log, instead of showing the user inputted values in the table, it shows the computed values that are relevant to the balance calculation. For example, if the expense inputted was Joint paying $100 for Neo, the value that would show up in the table is -$50 under Trinity paid. While this may make sense to the developer who understands how the balance is being computed, this is not very clear to people using the app and does not match people's model of expense tracking where what's inputted should be what's logged. It is also hard to figure out from the table what -50 means in terms of who paid, who was paid for, and why it's negative. Trinity and Neo would need to recall what the balance computation is to make sense of it, rather than being able to recognize it from the interface.
One recommendation is to make a separate table that shows the balance computation or just not show it at all, and have the expense log match what is actually inputted by Trinity and Neo.
-
Major: The placeholder label in the amount fields are not visible once text is added (help and documentation/visibility of system status)
The placeholder text in the inputs in the pay breakdown disappear when you start to write in them. This makes it hard for a person filling out the expense form because they'll have to remember what each input is which makes it hard to learn and requires recall as well. I put this under visibility and documentation of system because there is no feedback for when you start typing to know which input is which and it could be cleared up through documentation, meaning labels outside of the input fields.
More Issues
- Minor: Assuming the radio buttons refer to the person/account that is paid for, user can only choose one person as the person being paid for (flexibility & efficiency)
- Minor: It is unclear what the radio button means, especially when self-paid is checked (recognition not recall)
- Minor: The overall balance statement is below the table. (efficiency/discoverability)