Match the real world (L)

Recognition, not recall (S)

Bad: There does not exist a "Paid By" field, which means it is impossible to determine who paid for what. This is an issue with matching the real world as it is expected that an expense would be accompanied by who paid for it. The input for "Paid By" would also be expected to be a selection, instead it is an input field. Moreover, the headers for the input fields do not map naturally onto the headers in the spreadsheet. Users would be expecting the column headers to match the field headers in order for them to identify where they inputted what.

User control & freedom (S)

Flexibility & efficiency (E)

Bad: There does not exist a way to remove expenses or undo the adding of an expense. This means if a user adds an incorrect expense there is no way to remove it or undo. In the above image, I added a few expenses after the incorrect expense. Even if the database was not updated until an action, for instance pressing a save button, was taken, the interface would be extremely inefficient. This is because the user would have to reload the page, removing everything they have entered and restarting from scratch. And even if there was a deletion mechanism, there is no editing mechanism which continues to be a huge inefficiency.

Consistency & standards (L)

Help & documentation (L)

Bad: The headers of the form are misleading. "Description" is actually referring to "Expense name" and "Paid By" is actually referring to "Who paid what". These misleading names can cause users to input the wrong information or be confused as to what they should enter. Additionally, the "Paid By" field, as interperted by users as a field indicating who paid, would be inconsistent with the "Paid For" field which uses radio buttons. Moreover, the owes message has no currency which makes it a bit confusing, especially since values may be inputted in 1 of 3 currencies.

Error prevention (S)

Bad: We are able to add negative valued expenses. This can lead to several errors, namely we are able to get a person to owing a negative amount. While users may never input negative numbers, it is better to avoid accidently pressing the negative sign and have it be permenant, as there is no way to undo the adding of an expense. Moreover, there is no limit on how much a user could have paid. Again this might cause computation errors on accidental entries of numbers which are too big (no one will pay $1000000000000).