Versions Compared

Key

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

...

One of the main tasks that a user will perform on the site is adding new bills. Because of this, we try to make this action straightforward, helping the user along as much as possible. For instance, when a user inputs the total amount for a bill, that amount is automatically subdivided up amongst all of the selected users. Similarly, a calendar pops up when the user wants to select the due date for the bill. This makes the selection process a simple point-and-click, instead of using drop-down menus or another selection scheme.

We also changed some of our features due to user confusion during paper prototyping. For example, the interface to allow users to set the portion of each bill paid by each member of the household was originally a slider, but users had trouble working with it, so we switched to a series of text boxes. The calendar was added to the homepage to draw users' attention to it, since otherwise they often did not notice that the calendar was there.

Final:   Before:  Image Added

A user can see all of their bills on a single page. We took an idea from the way that groupon lets users organize their groupons. In particular, users can see bills that have already been paid, and those that are yet to be paid. This gives us a high degree of error correction, in case a user accidentally marks a bill as paid. This means that bills are never actually deleted, and gives the user a full record of their payments.

...

Bills are displayed as due on a certain day. We took this design approach, instead of listing out all of the bills due on a certain calendar day, so that the user would not be overwhelmed with information on a single screen. When the user clicks on a calendar day that says it has bills due, the user is brought to a page that displays all of the bills due on the selected day. It is on this screen that we give the user all of the information about the bills for the day.

 

We had intended to include a profile page with personal account information about the user, but we cut this after paper prototyping because no one seemed to find it useful. However, we did keep the display indicating how much money the user owes, putting it on the homepage instead.

Design Changes

We evolved our final design significantly from our original idea. A lot of our original idea, as presented by GR1, centered around the household, and we envisioned presenting bills to the user that pertained to the household they were part of. This meant that a user would see the bills for a the entire household, including ones that they were not personally responsible for. The rationale for this was that a user could be part of more than one household. This could be, for instance, a summer house and a college dorm. Our user testing, however, showed us that very few users actually have more than one household. Because of this discovery, we changed our application to center around the bills for a single user, instead of those for a household. This changed some of our tasks. For instance, we do not have a household graph of expenses. Instead, we present all of the user's bills to them.

...