Versions Compared

Key

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

...

Because all of our users will have slightly different preferences, we offer them slightly different ways to view their bills. One of our views in the timeline. This lets the user scroll a slider to a desired point in time, for example three weeks from the current day. The interface will then show the user all of the bills that are due within three weeks.

During the paper prototype user testing, our users had a tough time using the timeline view. This was originally supposed to be the only way that users could sort and arrange their bills. However, after the difficulties, we decided to include a more traditional calendar view, in addition to the timeline. Also, we chose to display more limited information on each bill to provide a cleaner interface and eventually allow sorting.

Now:   Before:   Image Added

A different approach is our dedicated calendar view. As opposed to the small calendar on the user page (shown immediately after the user logs in) this calendar gives the user to search for any month in any year, not just the current month.

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.

 

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.

...