Design
Describe the final design of your interface. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing).
On the first page of our site, we wanted to emphasize that the user has two options: to sign up for an account, or to sign in with an existing username and password. Because of this, we used buttons large enough to pass the squint test, and made them stand out by coloring them green. This first page of the site also has a blurb about Housebill's functionality, which we intended to attract new users, or to remind existing ones of our purpose.
We wanted to make signing up for an account a simple, no-frills task. This meant that the user would have to supply only a minimal amount of information. For instance, joining a household is optional on the signup page, so a user does not have to worry about this feature and can opt to do it at a later time. The goal here The goal here is to have the user exploring the site as soon as possible, which minimizes the likelihood that a user gets frustrated with the signup and decides to devote their time elsewhere.
Once the user is logged into the site, they are offered several different pieces of information, each of which take up their own corner of the screen real estate. In the top left, there is the total amount that the user owes, and the number of overdue bills appears in a large, red font. This will quickly attract the user's attention to any overdue bills, which we expect them to correct promptly. On the right side of the screen, the user sees their bills for the current month. This calendar serves as an overview. There is a larger version of this calendar available on a different tab, if a user wants to explore further than the bills for the current month. Next, there are two very prominent buttons towards the bottom of the screen, allowing the user to add a bill or to pay a bill. We expect these to be very common tasks on our site, and as such made these actions stand out on the page. The buttons are large, which comes from the application of Fitt's Law.
INSERT PIC OF FIRST PAGE SEEN AFTER SIGN-IN
Overall, we wanted to emphasize what we thought were the most important pieces of information to the user, similar to Google's homepage.
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.
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 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 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: 
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.
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.
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: 
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 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.
...
Our users were found in our dorms, living groups, and acquaintances on campus. While all users may not currently be living in a group setting where an application like HouseBill would be needed, users had all at least previously lived in a group setting such as during a summer internship. While all users being in current group settings would have been a better representation, these users still understood the problem and situation.
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.
Scenario Tasks
Part 1
- Create a user account with whatever username and password you want, join the household 'Test House'
- Add a bill: Test Bill, Due: 6/1/2011, Split cost evenly amongst all roommates, Total amount for bill is $100.00
- Log out of the interface
...
- Log into the interface as Username: Demo and Password: demo
- Pay all bills due within two weeks from today
- Edit a bill: Change the due date of the Test Bill to 6/10
Usability Problems
List the usability problems you found, and discuss how you might solve them.
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 group learned many things about development, design, and prototyping throughout this course. We learned about the iterative design process of making an application. One of the main things that we had to deal with was that we are not the users. We realized that you don't know how users will interact with your product until you actually allow them to access it. This comes in the form of prototyping, which provides challenges we were not used to as a developer. It is difficult to design a backend for an ever changing front end implementation.
Another thing we learned was that in design there is not always a right answer. In class, when we viewed Hall of Shame examples, there were often blatant aspects that we as a class could agree made the interface more difficult to use. However, most applications don't have clearly defined lines like this. We frequently encountered user issues where one user might consider an aspect a convenient feature while another user considers it a terrible design flaw. We encountered these decisions even amongst our own team members, such as when we were deciding how to do self populating fields in our add/edit bill interface.
As prototyping was new to all members of our team, we made some 'rookie' mistakes during paper prototyping that resulted in a lost of valuable feedback. Instead of focusing on the interface's usability, our users were distracted with issues in our tasks' wording and navigation blunders. The latter problem occurred as a result of not being able to see the top of the prototype easily from the tester's seat. This provided us only limited feedback as we began computer prototyping. With the technical difficulties we later encountered, getting more initial feedback would have allowed us to avoid some of the issues we encountered and spend more time developing more useful features.
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.
Issues found during user testing included:
- User while editing a bill removed himself from the bill accidentally. Since the bill no longer affected him, he could not access the bill again to re-add himself to the bill
Severity: Major
Solution: Show all bills connected to the household under household so that user has access to bills even if they do not apply to him at the current moment.
- User entered password incorrectly when signing up and then could not log into account.
Severity: Major
Solution: Have a confirm password entry textbox where the user must type in a matching password.
- User accidentally paid a bill and was confused when the bill disappeared.
Severity: Minor
Solution: Have a pop-up that asks if the user is sure of their action. However, the bills are still available to the user under the "Paid Bills" section and they can correct their mistake there.
- User could not understand timeline functionality.
Severity: Major
Solution: Have bills ordered by date so that it is clearer to see that bills are being added by date when the slider moves.
- User thought that slider on timeline was too small, and had trouble clicking on it to drag it
Severity: cosmetic
Solution: make the slider larger and more visible to the user
- User was unable to find all bills due within two weeks
Severity: Minor
Solution: Order bills by date on the view bills page or include the timeline as another part of the view bills page and consolidate the two features
- User tried to click on the number in the Overdue Bills section on the main page to access their overdue bill
Severity: Minor
Solution: Allow clicking on the overdue bills section to take the user to all of the bill that are overdue
Reflection
Our group learned many things about development, design, and prototyping throughout this course. We learned about the iterative design process of making an application. One of the main things that we had to deal with was that we are not the users. We realized that you don't know how users will interact with your product until you actually allow them to access it. This comes in the form of prototyping, which provides challenges we were not used to as a developer. It is difficult to design a backend for an ever changing front end implementation.
Another thing we learned was that in design there is not always a right answer. In class, when we viewed Hall of Shame examples, there were often blatant aspects that we as a class could agree made the interface more difficult to use. However, most applications don't have clearly defined lines like this. We frequently encountered user issues where one user might consider an aspect a convenient feature while another user considers it a terrible design flaw. We encountered these decisions even amongst our own team members, such as when we were deciding how to do self populating fields in our add/edit bill interface.
As prototyping was new to all members of our team, we made some 'rookie' mistakes during paper prototyping that resulted in a lost of valuable feedback. Instead of focusing on the interface's usability, our users were distracted with issues in our tasks' wording and navigation blunders. The latter problem occurred as a result of not being able to see the top of the prototype easily from the tester's seat. This provided us only limited feedback as we began computer prototyping. With the technical difficulties we later encountered, getting more initial feedback would have allowed us to avoid some of the issues we encountered and spend more time developing more useful features.
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.
Overall, our application grew and evolved throughout this term. There were many mistakes that we can say we made while developing, such as choosing the wrong suggestions to take and weighting having more features over developing the current ones to the fullest. That being said, we think developing Housebill gave us insight in what it is like in a startup or business to develop a real product and see the choices that have to be made and made us all wiser individuals.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.