...
- Deletion and Dispute functions execute immediately, with no easy way to undo the action
- Deletion action is available for debts, so technically, someone could just delete all debts even though he/she has not repaid the lender
- “Disputes” button is on each person’s row in the main screen. This can be accidentally hit when a user tries to just click on a person’s row to see all of their mutual debts.
Learnability:
- Pros
- Simple, table style interface.
- No “settings” menu to complicate things
- Large, easy to hit buttons (on touch screen phones)
- Consistent, clean layout
- Cons
- Multiple row selection can be confusing
- (+/-) labeling for types of debt can be very jarring at first.
- Labels and Buttons are on the same row (“Disputed” label vs “2 disputes” button which can lead to some confusion
Efficiency
- Pros
- Add function is very efficient (you don’t have to click on a person’s name and go to their screen to add a debt – you can do it from the home page.
- Clean layout lends to easy, efficient navigation.
- Multiple row selection is VERY efficient for mass deletion, “nudging”, or “disputing.” (I personally incorporated this because I hate how the iPhone lacks this feature in many places).
- Cons
- Adding an actual debt may be slow, since there are three fields to manually fill out
- No aggregate view of all transactions over some past period of time (for those who like to analyze their past lending/borrowing behavior).
- Adding multiple people quickly will take the user some time since the “add user” button only allows the user to add one person at a time.
- Users cannot add debts for multiple people at once.
- Ex: The user pays for 3 other people at dinner and wants to put down a debt of #bill/4 for each of the three other people at once.
Safety
- Pros
- Most execution functions are located at the bottom screen, decreasing chances that the user will hit one by accident when trying to hit a particular row.
- Deletion of something a user added is possible, thus making faulty added debts easy to remove and fix.
- Cons
- Deletion and Dispute functions execute immediately, with no easy way to undo the action
- Deletion action is available for debts, so technically, someone could just delete all debts even though he/she has not repaid the lender
- “Disputes” button is on each person’s row in the main screen. This can be accidentally hit when a user tries to just click on a person’s row to see all of their mutual debts.
Design #2 Storyboard
Upon logging in, the user will be greeted by the Home Page. At the top, there is a bar with the PennyPincher logo and three menu buttons to be displayed on all pages. A the home page specifically (which can be accessed by clicking on the PennyPincher logo at the top), the user will see a quick overview of the current “what is owed” status from the most recent closed transaction period. Reds (as taken from the term ‘in the red’) shows what the user owes other people, whereas Greens (for ‘in the money’ where green symbolizes as such) shows what other people owe the user. The Reds and Greens can be expanded and contracted as needed and will show the transactions under each with additional granularity.
...
Design #2: The primary difference of Design #2 between the other designs is that it focuses attention on how to tackle specific features to enhance efficiency for add transaction. While the other designs only allow transactions to be posted to a single other counterparty at once, this design handles group-based transactions. Consider, again, the scenario of a group dinner outing with four other people. Instead of having to create 3-4 separate transactions, a single one to split the bill will suffice! Additionally, the ability to individually modify transaction amounts for each given person allows for additional flexibility (if there are uneven splits between a group). However, it lacks the ability to compound transactions based on other users (ie, aggregating all the transactions that I have made with Susie Q) that the other two designs have incorporated.
*Design #3: *The The primary distinction between Design #3 and the other two designs is that Design #3 shows a summary of the user’s transactions with one other user. The user can decide to view the details and history of transactions with that one other user by clicking on a button to view details. This makes it so that the user will not have a lot of information presented to them unless they ask for specific information.