Bill Share Design Process


To start this phase each group member on their own brainstormed and came up with their own rough prototypes for their vision of the application. Afterwards the group met to discuss their ideas. Each team member gave a short presentation of their ideas and the features that they included in their sketches. Afterwards we held a group brainstorming session discussing the differences between each of the prototypes and whether we liked or disliked these. A number of features had to be discussed including how to handle user “groups” as well as the placement of information on the home screen. After the first discussion a rough prototype was created as a hybrid of all of our designs. We then used this design as a tool to see what features were most important in order to come up with our final design.

This phase was an excellent tool for designing the interface to our product. It allowed each of us to see what our other team members had in mind and what they viewed as the most vital. It was a necessary and valuable chance to work together before the implementation begins.


On the home page, the user has the option to either sign in/register, or create a "quick split". A quick split allows the user to split a single bill without requiring an account.

If the user clicks on "quick split", they are first prompted to enter how many people in total are splitting the bill. The user is then presented with that number of entries. For example, if the user enters that three people are splitting the bill, then three different rows will appear, one for each person. The user can edit the names of the people (otherwise it defaults to "Person 1", "Person 2", etc). The user enters how much each person contributed to the bill. For example, Person 1 may have bought some groceries worth $30, so they enter that amount. Person 2 may have bought some gas worth $12, so the user enters that as well. After clicking "Split it!", they are presented with a breakdown of who owes who how much.

If the user wishes to register for the site, they are presented with the typical sign-up fields. There is an optional "Invite Code". If another user has invited them to join a group, then entering this code will automatically register the user for the group.

If a user is registered and logs in, they are presented with the home page. The main content of the home page is the facebook-like "news feed," which shows recent activity in all the user's groups. On the left sidebar, the user can add a new bill, or navigate to their current groups. The user can also create or join a new group. On the right sidebar, reminders of upcoming bill due dates are displayed, as well as an overview of the user's overall financial situation. It shows the totals of how much the user owes and is owed in all the groups they are a part of.

The group pages also contain a "news feed" that is specific to the group. That is, recent activity in the group is displayed here. The left sidebar contains all the members of the group, and how much they owe/are owed by the current user. The user can also add a bill from this page, which will be posted to the group.

On the Add a Bill page, the user is presented with a few fields to fill out. First, they enter a title for the bill, and the amount the bill is for. The "Date Paid/Due" field will default to the current date, meaning the user has paid the bill. If they enter a date in the future, then this bill will not have been paid yet, but will be set up as a reminder. We haven't yet decided how a user will say that they've actually paid the bill yet, but it will show up on their "Reminders" sidebar. Finally, the user selects who the bill is shared with. They can start typing names of groups/people, or they can select them from the sidebar next to the field. Bills are automatically split evenly between the number of people added. If the user wants to make an adjustment to the amount each person owes, they can do so manually.

Final prototype - Revision 2:






Final prototype - Revision 1:


Rough prototype by each group member:





Description of Evaluation Phase
Initially, we came up with different designs in an attempt to make our low-fidelity prototype as versatile as possible. When we gathered, we each did a task centered walk through presentation to the team. This step allowed each of us to see new ideas we didn't think of during the brainstorming and new features we were missing.
We also gathered a couple of users and tried to see the difficulties/suggestions they had while going through the Low-fidelity prototypes.
After that phase, we tried to combine the most useful features without clobbering the system in order to come up with a “final” prototype. Note that final refers to a consensus here, and is in no way, a commitment to a particular design.
We then refined the “final” prototype with the graphical features that should make it appealing while keeping all the good interface design principles in mind.

What We Learned:
The steps we went through during the evaluation phase taught us the importance of brainstorming. We realized that having people come up with different ideas and trying to make the best of it leads to a very diversified and out of the box end-product.
We also realized that sometimes, there are discrepancies in what the user thinks is a natural task flow versus what the designer think.
Finally, we realized that the key to a good system design is compromise. To get most of the keys to a good system design right, we have to give up certain graphic features to favor interface simplicity.