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 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
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.
...
- 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.
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: Critical
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
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.
...
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.