User Analysis
"Thrift-ster" User Persona
Mr. Spend Thrift is a recent college graduate and now full-time employee in the "real world." He has always been particular about where his hard-earned cash goes. If given the opportunity, he will always choose the budget option; tap water instead of bottled or soda, fill up on complimentary restaurant bread to buy a smaller-portioned and cheaper-priced entree, redeem 30-cent coupons at grocery stores, and pay exactly 10% for tip. Thus when there comes a time when he must dough out cash for a buddy, Thrift is relentless in making sure that his buddy pays back in a timely manner. Thrift's primary concern is that the app is effective (just as if not even more than himself) in "harassing" his dependents to pay up. With every cent being important in the eyes of Thrift, he would like to see PennyPincher be an accurate and reliable app that is also suitable for harassing those that owe him money. Thrift quotes, "It's not very long that someone has an outstanding balance with me. Could this app harass people for my money as well as I do?" clearly highlighting his monetary priorities.
"John Doe" Heavy Lender/User Persona
John Doe is a regular MIT student who is pretty nitpicky about his money and likes "bills to be split equally to the cent". He really doesn’t mind paying for others, but gets annoyed when multiple people borrow money and then forget to pay it back. He finds that he can manually keep track of how much people owe him and how much he owes others, but finds that it’s simply too cumbersome and slow to be effective when "there's more than like four-ish people". Since John would use this app extensively as he likes to keep a detailed record about his money, he would like a simple user-interface that allows him to input records super efficiently. According to him, "the less complexity and options there are in a program like this, the more I'd want to use it."
Busy and Occasional Lender User Persona
Sally Smith is a small business owner who has been running her bakery in the "real world" for around 15 years. She lends out money to friends and relatives, but since she is so busy managing her bakery, she often forgets who she lends money to when it’s not related to business. She would use this app to help her keep track of who she lends money to, and to keep a record of who pays her back. She hopes that this app would allow her to worry less about the money she lends to her friends and family.
Lessons learned from User Personas
Lessons learned from Mr. Spend Thrift - Thrift-ster User
Current methods of payment "harassment"
- Onamiability
IfeellikeIamgenerallyafairlyamiableperson.
Undertheassumptionthatthereisnothingbetweenus,
thattherehasn'tbeensomecatastrophiceventthat
wouldcauseariftbetweentwodifferentpeople,I =i
Timely, in-person verbal confrontation - Text message or email reminders
Desired methods of payment "harassment"
- Time-triggered (ie. every 2 days) reminders for payment
- Effectiveness: harassment reminders actually reaching the desired individual and not email filtered, etc.
- A different method of issuing reminders beyond email or text
Lessons learned from John Doe - Heavy User
Current Solution for Debt Tracking
- Pencil/Paper - really low-level way of keep tracking, works for only a few people
- Excel-style Spreadsheet - depends on user-implemented functions subject to human error; difficult for multiple people to manage
- iPhone - uses a money managing app meant for one person and attempts to use it for multiple people
Requirements of Desired Solution
- Super simple user-interface - Should not take more than a few seconds to input a debt or payment of debt
- Approvals - When another person places a debt on Shawn, he wants to be able to approve it so that people do not make up claims for money.
Lessons learned from Sally Smith - Busy and Occasional Lender User
Current forms of timely payment
- Payments received from friends and family occur at irregular intervals; idiosyncratic time periods
- Without active monitoring, hard to regulate when re-payments are going to be made
Desired methods of future payments
- A way to regulate payment schedule; fixed time periods
- Create a payment period, similar to that of a monthly credit card statement
- ability to actively manage the frequency of payment settlement (every week, every month, bi-annually, etc)
Task Analysis
The PennyPincher application will attempt to perform three main tasks
- Adding people (people who owe you money or you owe money to)
- Add transaction (Users are allowed to say that another person owes them X amount of dollars)
- View all transactions (like a credit-card bill)
- Disputing transactions (for potentially incorrect charges)
- Discreet payment schedules for fixed payments (also like a credit-card bill)
1. Adding People
Goal: Allow users to register a two-way connection with people that owe them money.
Subtasks:
- Searching for user by username
- Adding user by username
- Removing user
Preconditions:
- User must have an account with PennyPincher
Postconditions:
- 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
2. Adding/Approving a transaction
Goal: Allow users to input an amount that a particular person owes them
Subtasks:
- Set the amount that another user owes them
- Input the name of the transaction (what it was for)
- Send the transaction
- Approve transaction
Preconditions:
- The two exchanging parties must have an established connection.
Postconditions:
- 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
How often used? - This task will be performed very frequently as its the core of PennyPincher
3. Viewing Transactions
Goal: Allow users to have a complete review of all posted transactions. This will emulate what a credit card statement might reflect; providing information about charges applied against a user (other people posting that a user owes) as well as transactions that are credited towards the user (a user claiming that other people owe him/her).
Subtasks:
- Ability to arrange transaction order depending on various parameters including but not limited to:
- type (credit or charge)
- person of transaction origination (who posted the original transaction)
- denomination (the size of the credit or charge)
4. Disputing Transactions
Goal: People make mistakes; when there is a transaction against the user that he/she deems incorrect, it may be disputed. Upon dispute, that transaction will be flagged for in-person or alternative settlement.
Subtasks:
- Flag the transaction that a user wants to dispute
- Flag the complimentary transaction that a user wants to dispute (the transaction as posted on the other person's account)
Preconditions:
- Transaction must have already been successfully posted prior to dispute
Postconditions:
- Disputes should have the ability to be retracted if the transactions are settled.
5. Discreet payment schedule for settlement
Goal: Users want to know when they are going to be paid back. It's simple to remember that you have a monthly credit card bill you pay every month; what settling what you owe other people emulated a similar schedule?
Subtasks:
- Determine fixed time intervals for which to "close" a statement/transaction period and inform users of due payment
- (Potentially) Allow users to dynamically decide the length of the statement/transaction period before closing
Postconditions:
- Inform all users involved when a statement period is closed and settlement payment is due.
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.
Try to think about who your users are more holistically - right now they're sort of points along a 1D continuum. You don't seem to really get a good feel for what the tasks your users use to solve your problems, and instead you describe actions that your app will let users take. Don't forget that the next step is to make three separate designs - you shouldn't already have picked one.
Please don't forget to fix the gibberish under Lessons Learned.
I'd appreciate it if you made these changes, since we'll be working off this document for the whole rest of the project.