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).
Implementation
Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.
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.
The database holds information about the Users, Households, and Bills. In addition, there is a table called User_Bills that connects Bills to Users. This last table is necessary because the relationship between Users and Bills is many-to-many.
Currently, the site is hosted on scripts.mit.edu, which uses Apache to serve the HTML pages generated by the backend.
Evaluation
Users were given a briefing and then given each task individually as tasks are completed.
Users
Describe how you found your users and how representative they are of your target user population (but don't identify your users by name).
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
Part 2
- 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 and the iterative design process of making our application. One of the main things was that we aren't the users. We realized that you don't know how users will interact with your product until you allow them to access it in some level 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, most times there were 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 as a result of not being able to see the top of the prototype easily from their seat. This provided us only limited feedback as we began computer prototyping.