...
INSERT PIC OF FIRST PAGE SEEN AFTER SIGN-IN
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.
INSERT AD BILL PIC HERE
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 coupons. 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. The bills are arranged in a table, ordered by date due.
INSERT PIC OF BILLS PAGE
Any bill that has not been paid can be edited by the user. This page looks very similar to the page for adding a bill, except for the fact the the existing bill's information is pre-loaded into the text box fields. In this way, the user can exactly see the bill state at any time, and can change any aspect of the bill.
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. 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.
There is another page of the site, dedicated to presenting information on all of the users in a particular household. This household page allows a user to add or pay a bill within that particular household.
HOUSEHOLD PAGE
Every page of the site presents the same header. This header is used for navigation. There are tabs for each of the pages on the site, which gives the user access to all of the site's features in one place. A user can look at the header and see all of the possible ways that they can interact with their bills.
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.
Implementation
For the frontend, Housebill uses HTML5 with CSS, as well as jQuery. The database used is MySQL, and the backend functionality is written in Ruby on Rails.
...
Describe how you found your users and how representative they are of your target user population (but don't identify your users by name).
User 1: College senior. Currently lives in a dorm, but plans to move to an off-campus apartment with a group of friends in the fall.
Briefing
HouseBill is a bill organization system for people living in a group setting. It lets everyone within a household see how much they owe, and when it is due. This makes paying bills more transparent, because you can see exactly where your money is going, and you can plan accordingly. It also allows the everyone to help handle the "treasury" duties of the household so the entire responsibility does not fall upon one person.
...
List the usability problems you found, and discuss how you might solve them.
User 1:
Generally had no problem with performing the tasks, but did not find the purpose of the timeline intuitive; thought that it should have been incorporated into the View Bills page. Misinterpreted the function of the "Pay All Bills" button when attempting to pay bills due in the next two weeks. Wanted more information from the calendar (such as number of bills or amount of money due on a certain day). Had a lot of suggestions for desired features:
...
Reflection
Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.
...
Our inexperience also led to another blunder of being overly ambitious with our prototypes. While our prototypes showed the opportunity of what we could do with the idea at hand, the prototypes that we made, especially the paper prototype, were not realistic with our abilities and the time given. During our paper prototyping, we created many superflous features that were not necessarily needed for critical operation. This then lead to an expectation of having those features on the final product of our site. Instead of focusing on developing the critical aspects of the site while computer prototyping, we put more effort into trying to prototype all of the features. This resulted in weaker features all around and many of the features that we tried to prototype were not ready for GR4 and/or GR5, which made it seem like wasted effort. If we could redo the project, we would have created more realistic prototypes with basic features and then enhanced the site from basic usability.
This would mean implementing the bare bones functionality, and having users test that. From our experience, having a focus group test the interface with the bare functionality gives us a good idea of what the users want as an interface. This would cut down on the number of revisions that we have to make during our redesign phases.
As we mentioned in our Implementation section, we had numerous issues resulting from our decision to use Scripts. When we realized that it was going to limit us and undermine our development progress, we should have used another host service that would give us the freedom we needed to develop more easily. However, this choice would have been a more expensive option.