UX design breakdown: Household bill management

This post covers my process for a 4-hour UX design exercise.

Brief

You are the UX designer for an app that allows flatmates in a share-house to manage rent payments, communicate with each other, and allocate expenses between themselves.

Carry out UX work on a screen that allows the user to split a bill between all the members of a share house based on the following user story: 3 flatmates Calho, Asad, and Rosario live in an apartment together, it’s the end of the quarter and they must pay their water, electricity, and gas bills.

The UX should focus only on the process of registering and subsequently splitting the bill/allocating it between the flatmates — there is no need to consider the process of paying or tracking payment status for each flatmate, although you might consider how a flatmate might be notified that they have a share of a bill to pay.

Bonus points for considering how you might deal with tracking payments and payments status for each flat mate on the bill.

Because your company is a start-up and your CEO is cheap (whats new?!), your product owner has asked you, as a separate project, to prepare UI.

You have 4 hours to complete this task.

Your findings should be presented to include:

• an outline of the process you followed to arrive at your final UX
• the final wireframes for the bill splitting/notification process
• your UI layer

Research/analysis — defining objects and states

For the sake of time, I’ll be using my own household to help define the needs of the bill management process.

We are just looking at one section of the app — where we can add and manage a bill. Households tend to share more than just bills, so let’s keep that in mind and call this section ‘expenses’. First up, let’s look at what objects might come under expenses:

• Household expenses (supplies, services, shared groceries, furniture, etc)
• Bills (gas, electricity, water, internet, etc)
• Rent
• Bond

Let’s assume rent and bond would be allocated during the initial setup of the household, so we can ignore them for this exercise. This leaves bills and household expenses as the objects we might see in the expenses section.

Bill properties

Next up we can break down the properties a bill might have:

• Type (gas, electricity, water, internet)
• Due date
• Total cost
• Bill owner (who will pay the bill?)
• Bill split (how much of a share will each housemate owe?)
• Payment status
• Billing period
• Notes/attachments

The bold properties are important so that we can notify flatmates, allocate costs, and update the status of the bill. To keep things simple for now let’s ignore the billing period and notes/attachment properties.

Paying bills in a household & the bill owner

Generally, a bill needs to payed to the billing company in full. That is, each housemate can’t pay their share of the bill to the company individually — shares need to collected and then paid in full.

This requires a bill owner; somebody who is responsible for collecting the payment and then paying the billing company. By default, we can set the bill owner property to be the person who is entering the bill (if they received the bill, they are likely the account owner).

Bill payment status

The payment status of a bill can either be:

• Paid, or
• Unpaid

As a side note; some companies may direct debit — in this case the bill owner may have already paid the bill when it arrives, and they just need to collect shares from their flatmates. To account for this use case, the payment status of a bill should be kept separate from the ‘share collection’ status.

Share collection status

This is a status that helps manage each flatmate paying their share of the bill to the bill owner. Once a bill has been created by the owner, each other flatmate will be required to pay their share to the owner.

• Each flatmate can have a paid/unpaid share status
• The bill as a whole can have a ‘waiting on shares’/‘all shares paid’ status

Workflow

Now that we have defined the properties and states of a bill, we can look at the optimal workflow for the user to go through to create and manage the bill. For this case, let’s say that the Calho is the bill owner (responsible for paying the bill) and that the bill has not yet been paid. First let’s look at an overview of what Calho’s needs are:

1. Calho has received a bill
2. Asad and Rosario pay their share of the bill to Calho
3. Calho pays the bill

Now let’s break that down into steps in our UX workflow:

1. Calho is on ‘expenses’ screen
2. Calho selects option to ‘Add new expense’
3. Calho selects the expense type ‘Electricity bill’
4. Calho enters the due date and total cost
5. Calho saves the bill
6. Asad and Rosario are notified that they have to pay their share of the bill to Calho
7. Asad and Rosario pay their share to Calho and mark their share as ‘paid’
8. Calho is notified that Asad and Rosario have paid their share
9. Calho pays the bill and marks it as ‘paid’

Note on payments: for the sake of keeping this exercise short, the actual sending of payments between flatmates and billing companies will be handled outside the application (eg a bank transfer). Though we will assume that bank details for each flatmate have been collected during the account creation to help facilitate transfers.

Note on step 3: the expense type is required upfront because it defines the properties and the data required for that expense — for example sharing the cost of a grocery trip has different requirements than sharing the cost of a electricity bill.

Note on step 3: could be two steps — first select ‘bill’ or ‘household expense’ and then select the subcategory of each of those. I merged them into one step (showing all expense types together) because there isn’t a huge number of bill and household expense types to warrant the extra step of subcategorisation.

Note on step 4: these are the only two required fields that we can’t prepopulate — the bill owner is set to Calho, the bill split set to even, and the payment status is set to unpaid. Calho could change this here if required.

Wireframing

Now that the workflow is defined, let’s look at how that might work in a wireframe.

Calho inputs the bill details and saves it, notifying the other flatmates

Asad recieves a bill notification and pays his share

Calho recieves a notification that all shares have been paid and then proceeds to pay the bill

UI

Adding the UI layer to some of Calho’s screens — the expenses section, selecting an expense type, and adding a new electricity bill.

Here I am focusing on key actions and keeping them within thumbs reach — adding an expense and saving a new expense. In the expenses screen, key data points are displayed in the summary for each bill — one of the more critical is the bill payment status and share payment status, so the user knows what the current state of the bill is at a glance.

Further exploration

Given more time, I would like to further explore:

• More in-depth exploration of UI layer including transitions
• Sending/receiving payments from housemates via an in-app solution (connected bank accounts/credit cards), automation of payment status updates
• Expand functionality of ‘expenses’ section — take into consideration existing debts when requesting payments rather than having each expense as standalone (eg Calho previously owes Asad $60, so when Calho adds a shared bill for $100 each, Asad only has to pay Calho $40 and then the existing debt will be settled)
• Look at reminder notifications — bill due in 7 days
• Look at error states
• Additional optional fields in the bill (bill period, notes, attachments, biller payment details)