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.
"Big Lender but Big Pincher" 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. The current systems that he employ are what he considers "just one layer over a simple database," and he wants an "actual simple system to lend and collect money." 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 also wants the application to be able to let her track users that are not registered as PennyPincher users, since she often lends out money to her grandparents who do not use the internet. Overall, Sally 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"
- 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
- In general, most systems involve the user directly interacting with the database with almost no layers of abstraction in between.
Requirements of Desired Solution
- Super simple user-interface - Should not take more than a few seconds to input a debt or payment of debt
- An actual "system" instead of just an interface for a database.
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 the following 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 transactionsHow often used?
- Depending on the user, but should be used fairly infrequently as users usually only incur debt with friends
2. Adding 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
Preconditions:
- The two exchanging parties must have an established connection.
Postconditions:
- A transaction will be sent from one party to another.
- 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
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
- "Nudging" people to pay back their debt through discreet, yet effective notifications when the statement period is closing.
Postconditions:
- 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.
- Connections with people who do not use the application - users can use the app to "offline" track debt with a friend/family member that isn't technologically savvy (yes, people like that exist!)
These ideas that we have mentioned definitely add another dimension to the Penny Pincher application, providing users with features that are far beyond just the pure actions of saving and retrieving data. Our ultimate goal is to provide users with an interactive, immersive system to debt tracking and repayment - one that is simple, easy-to-use, and effective.
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.