Scenario
Sally Smith is a recent college graduate working in New York City at BigName design firm. Since she is only a starting analyst, she lives on a tight budget, especially with the high New York city tax and cost of living. Sally current lives in a Manhattan apartment with three roommates. Not only is Sally living with these three people, but she happens to be best friends with them as well. This makes life really great for Sally because she has a nice group to go out with on the weekends. However, as time has passed, Sally and her roommates have noticed that they have a lot of debts to resolve all the time.
From housing bills and utility bills to bar taps, taxi fares, and movie tickets, Sally and her roommates constantly struggle to figure out how much each person owes another in total. Between her and her roommates, they find themselves either not remembering an amount of debt, disputing an amount of debt, or disputing a debt completely. One of Sally's roommates, Samantha, had once tried to take up the task of keeping track of everyone's debt with a personal finance application on her iPhone, but this task proved to not only be too cumbersome for Samantha, but she found it impossible to track all of the roommates down at once to settle debts since they all have different schedules (and don't want to settle debts when they're going out!). With her busy schedule, Sally would really love to be able to have a system that allows her and her roommates to keep track of their mutual debt, dispute any debts that are questionable, and review all of their transactions at the end of the month when they pay their bills. Notably, Sally would like to be able to easily add new transactions (when she foots the dinner bill for a group of friends), easily view all transactions posted, and also flag a bad post if she wants to dispute an faulty transaction.
Designs
For these designs, we decided that we would all create our own personal designs without consulting each other. That way, we can use our creativity to the fullest without any outside influences. Below are the three unique designs.
Design #1 Storyboard
This design borrows emphasizes consistency throughout the application and simplicity.
Imagine that Sally has just opened up the PennyPincher website...
FIGURE 1
Figure 1 displays the home screen of the application for Sally Smith. In this screen, she can see a list of all of the people she has a PennyPincher connection with. Each row itself is a link to a screen displaying all debts for that particular person (Figure 2). On each row, three main user interface devices are shown. On the very left, there is a checkbox used for selecting the user when Sally wants to delete a connection with that particular user. To the right, there is, on some rows, a button with a label representing the number of disputes that particular user has with Sally. Next to the disputes button, there is a convenient "add" button that will bring Sally to the pop-up add screen (Figure 3). On the very right, there is a value of how much money that Sally owes or is owed by that particular person. (Negative sign (-) means Sally owes the person, and positive sign (+) means that the person owes Sally).
Imagine that Sally has pressed the row with "Roommate #1"
FIGURE 2
Figure 2 displays a screen displaying all of the debts between Sally and Roommate #1. The layout of Figure 2 is consistent with Figure 1, with the difference being listing debts instead of people. Just like before, checkboxes are on the very left of each row to perform row selection for the "delete", "nudge", and "dispute" functions located at the bottom of the screen. On the right side of some debts, there is a dispute flag, indicating a dispute on the debt. On the right side, the amount of debt is once again shown, using the same (+/-) system to indicate the direction of the debt.
Imagine that Sally presses the Add button on the bottom left of Figure 2.
FIGURE 3
Figure 3 displays the add debt pop-up screen. The idea behind that idea of an add "pop-up" is that users can add a transaction from home page (Figure 1) as well as a user's page (Figure 2). This duplication may seem ineffective, but since "add" is such a commonly used function, users would appreciate not having to go back to a certain screen to "add." The add pop-up itself is pretty simple, with three main fields: name, date, and amount. The user can simply click on the field to bring up a suitable keyboard (on touchscreen phones) or simply click the field to gain focus to type. At the bottom, there is a simple add button to submit the debt. After this is done, the pop-up simply disappears.
Imagine that Sally is on Figure 2 (the page displaying all of Roommate 1's mutual debts), selects two items (checkboxes on the left are checked), and presses the dispute button on the bottom right corner. This would send a dispute in the system to Roommate 1.
'
FIGURE 4
FIGURE 5
FIGURE 6
So now, imagine that you are Roommate 1 and you are looking at the Penny Pincher application. On your home screen (Figure 4), you see that Sally Smith has disputed 2 items based on the red button next to her name. You can simply tap that button which will bring you to Figure 5. On this page, you see the items that Sally has disputed. Here, you have the option of settling the dispute (button at the bottom). This will lead to Figure 6.
Imagine that Roommate 1 has pressed the "Settle Dispute" button.
Figure 6 shows the "settle dispute" pop-up menu. In this pop-up menu, there is a "new amount" field that is defaulted to $0.00. This default has been chosen to make it easy for users to accept disputes (clearing the debt). This type of menu also makes it easy for the two users to agree on a new amount of the debt if they choose so. if the new amount is set to $0.00, the debt will be automatically deleted on both of the user's accounts.
Analysis: Dimensions of Usability
PROS
Learnability:
- Simple, table style interface.
- No “settings” menu to complicate things
- Large, easy to hit buttons (on touch screen phones)
- Consistent, clean layout
Efficiency:
- 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).
Safety:
- 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
Learnability:
- 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:
- 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:
- 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
Note: For some reason, the image link does not work. However, you can right click and click "view image" to get a larger view.
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.
Clicking on the transaction button will lead to a page where new transactions can be added. In this example, Eunice would like to add a transaction where she paid for dinner for a group of friends (with Adam W and Madeline J). Although she would have been fine to split the bill evenly, Madeline insisted that she pay a larger portion since she ordered a more exotic dish and have Adam and Eunice split the difference. After selecting the people involved in the transaction, specifying custom payments, and adding a quick description, Eunice posts the transaction.
Clicking on the summary button will load a new page that shows a list of compiled transactions. This can be filtered by transaction period, and further by date posted, by counterparty (who the transaction was with), by amount, by transaction type, etc. Clicking on the information icon will lead to a transactions description page.
With the transactions description page, details about the transaction are shown. Eunice sees that this transaction is faulty and decides to dispute it by clicking on the Dispute button. This leads to a new page that where she can add a quick memo/message about the dispute before submission. When the dispute is posted, the counterparty (Matt M in this case) will be notified for settlement.
Analysis: Dimensions of Usability
PROS
Learnability: This design is similar to many existing applications on the market. There is a clearly defined menu bar at the top for easy navigation to feature pages; the summary page lists transactions in similar style to some online banking mobile-based displays.
Efficiency: A common action that users will encounter will be to add a new transaction. The current design places the add transaction button to the top left of the screen for easy navigation on every page! Additionally, the interface allows for posting group transactions (ie. posting a single transaction for multiple people that are sharing a bill instead of having to post a new transaction for each person; efficiency derived here is of factor n)
Safety: When there are faulty transactions, users have the ability to post a dispute for mistaken transactions. (Although not shown here in this design, the original poster of a transaction should have the ability to cancel it).
CONS
Learnability: While there are many features here that are commonly found in some well-known applications, it may be unclear what a transaction implies (as in, who is allowed to make a transaction and type of transaction). Since our implementation involves only one-way directional transaction relation, this may be difficult to learn or understand for users.
Further handling of disputes: Ease of tracking, settling, and following-up with disputes is currently unknown. This design provides an option to "settle" a dispute, such that the transaction will be effectively canceled. However it is a bit uncertain how to handle the case that a dispute is settled by an agreement on a new transaction amount.
Complex transactions: Consider the case where at a dinner, a group of 4 decide to evenly split a $100 dinner bill. However, some people are short on cash while others have extra on hand. So one person pays $50, another $40, and two of them $5 each. If in the end this should be equaled out such that all pay only $25 for the dinner, how would that happen? The solution to this is currently unknown.
Design #3 Storyboard
From the home screen, the Sally can click a button to add new transactions. This will take her to the “Add a Transaction” page. On this page, she can select a user from a dropdown list of know users or search for a new user by clicking on the “New User” button. A text box allows her to enter the amount of money the selected user owes. Clicking the “Submit” button records the transaction for Sally and the selected user, and brings Sally back to the home page. Clicking the “Cancel” button brings Sally back to the home page. The home page will also have a “Pending Transactions” button with a number displayed next to it. Clicking this button leads Sally to a page that shows any new transactions where other users claimed that she owes them some sum of money. Sally can dispute claims on this page by clicking any of the dispute buttons next to the individual claims. Clicking the “Done” button brings her back to the home page.
From the home page, Sally can view all current transactions she has with other users. If Sally wants to view all transactions, including past transactions, she can click on the “View All” button. Clicking this button leads her to the “All Transactions” page. This page shows two lists. The list closer to the top of the page shows current transactions she has with other users. The list below the current transactions list shows past transactions she’s had with users. The past transactions list does not include the amount of money because these transactions should have all totaled out to $0.00 since these are closed and settled transactions. In both lists of transactions, you can click the button corresponding to each user to view all transaction history with that particular user. This leads you to a different page, which displays a list of dates and money amounts for every past transaction Sally has had with that user.
Suppose Sally wants to dispute a transaction with Bob, she can do so by viewing the details of her transaction with him. This will lead to a page that shows the total that she owes Bob, or however much Bob owes her. This also shows a list of dates and money amounts for every past transaction she has had with Bob. Next to each transaction where Bob claimed that Sally owes him money, Sally can click the “Dispute” button if she disagrees with that transaction. The “Done” button brings the user back to the home page.
Analysis: Dimensions of Usability
PROS
Learnability:
- The buttons are clearly labeled and accessible from the home page.
- All pages have buttons to easily return to the home page.
- The dates for transactions are listed so that the user can recall certain transactions.
- There are only five distinct pages that the user will see, making it simple for the user. The main page is the home page, and from this page the user can get to any of the other four.
Efficiency:
- There are no dialog boxes that pop up to confirm if a user wants to dispute or settle a transaction.
- The list of current transactions on the home screen shows that total amount of all transactions with another person. The user can choose to view more details by just clicking a button.
- The home page shows the total amount across all transactions that the user owes other people or that other people owe the user.
- Past users that the user has had transactions with are listed in a drop down menu so that it is easier for the user to add a new transaction with them.
Safety:
- All pages have buttons to easily return to the home page.
- The user can view the details of every transaction to double check for correctness.
- The user can dispute transactions that the claimer may have claimed incorrectly.
CONS
Learnability:
- The user may need to learn to understand that any negative amounts of money listed in their transactions with another particular user show that that person owes them money.
- The user will need to learn that the little buttons with arrows next to each transaction lead to the transaction details with that person.
- The user may need to learn what it means to dispute a transaction or how to settle a transaction.
Efficiency:
- The user still needs to click on a couple of buttons to view all details of transactions that they have had with another person.
- There are no group transactions. Transactions must be entered one user at a time.
Safety:
- There are no dialog boxes that pop up to confirm if a user wants to dispute or settle a transaction.
- There is no button to cancel transactions.
Distinctions in Design:
Design #1: What makes Design #1 unique is its emphasis on simplicity and usability. Design #1 is much less complex than the other two designs because it constantly keeps in mind that this website will be mostly accessed by people on their phones with limited screen real estate. Therefore, Design #1 does its best to emulate a native application on a phone without actually being a native app. These features can be easily observed by the simple, row-layout of debts and people, as well as the large buttons on the bottom that are perfect for fingers to press. The pop-up “ add-debt” feature also aims to allow users to add a debt without having to go to a new page, which can be particularly cumbersome if they are running off of 3G internet.
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 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.