Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • User establishes a connection with another user and can now add transactions
    How often used? 
  • Depending on the user, but should be used fairly infrequently as users usually only incur debt with friends

...

  • Set the amount that another user owes them
  • Input the name of the transaction (what it was for) 
  • Send the transactionApprove transaction 

Preconditions:

  • The two exchanging parties must have an established connection.

...

  • A transaction will be sent from one party to another.
  • Approval message will be displayed to the person who owes money
  • Upon approval, net balance between the two parties will be updated
  • The receiving party will have a discreet UI notification that their debt has increased for the debt sender. 

How often used? 

  • This task will be performed very frequently as its the core of PennyPincher

...

  • Inform all users involved when a statement period is closed and settlement payment is due.

...

Depth Analysis

Current Solutions are Databases 

Current systems that attempt to solve the problems we are trying to solve fail because they are simple layers over a database, if not just the database itself. Paper/pencil is an obvious of a database itself and using Excel is basically forcing the user to interact directly with a "database" (in this case a spreadsheet).  Other solutions may include some sort of money management applications that are not geared towards multi-user debt tracking (such as mint.com), but some users might try to use these applications to track how much money they are owed - not the most ideal solution. 

PennyPincher is a system

The whole idea behind PennyPincher is to replace all the current solutions with a solution that is tailored to the task of debt tracking. Therefore, as designers, we have the freedom to add any features that we think would help users solve their debt tracking issues. Some of the ideas that we have had on GR1 or have been recently are:

  • A "payment schedule" where groups of users can set when debts have to be paid off.
  • Payment disputes - users can dispute a particular debt that has been placed on them.
  • Group formation - users can place themselves in different groups simultaneously 
  •  

TA Feedback.

While I think you're going in a good direction, note that this project is barely a stretch - try to push yourselves to do something interesting with the UI to make a case for it being an interesting UI challenge. Make sure it isn't just a layer over a database.

...