Background

As part of my ITP 310: Designing for User Experiences class, our group was tasked with pitching an idea for a digital venture that could be prototyped by the end of the semester.

How did I add value?

Though we did not have official roles within our project teams, I took on the unofficial role of design lead by planning meetings and work sessions, organizing team files, and guiding the development of prototypes. Additionally, I did most of the prototyping for the onboarding and bill creation workflows (to be shown).

Problem

Bill-splitting is hard.

My friend does all her bill-splitting calculations by hand. After a weekend out, she can easily spend several hours meticulously summing up everyone’s respective due amounts in an Excel spreadsheet. Considering her busy workload, there were times that I couldn’t help but notice the extra burden this created, and I began to wonder if there were easier and more time-efficient ways to handle bill-splitting.

Several other students in the class felt similarly, to which we became a team and chose to further explore the problem space of bill-splitting.

Research

Interviews

Though we all had our personal experiences, we wanted to confirm whether this was truly an issue and if so, to collect potential reasons why. To do so, we conducted three informational interviews with fellow college students about their own opinions and experiences with bill-splitting.
‍
The key takeaways we gathered from students were:

To help empathize with the target users and determine potential problem areas, we constructed several user personas based upon our interview responses.

This led us to the overarching question:

How can we simplify and streamline the bill-splitting process for a better user experience?

Solution

Bill Up is a financial management tool that streamlines the bill-splitting process, allowing users to more easily divide costs, manage payments, and track their spending.

To start, create a bill: either by taking a picture of your receipt or manually.

Next, select your recipients and assign the items.

Lastly, monitor bills and send payment reminders from your transaction history.

Recipients can choose to pay or dispute transactions once they've received the bill, either from the notification or from their transaction history on the home page.

Process

To help visualize potential target users and the solutions that needed to be addressed, we first began by developing a mind map.

This process allowed us to narrow down on the specific problems and consequent features we wanted to focus on.

View in FigJam ↗

Next, we conducted a competitive analysis to identify what was lacking in current solutions.

To do so, we compiled a list of features commonly-found features in several direct competitors such as Splitwise, Tab, and Settle Up in addition to intermediate-level competitors like Venmo.

We saw that none of Bill Up’s competitors utilized a bill-splitting system with all of the aforementioned features that was both intuitive to use and visually appealing, hence their lower user retention rate (an observation supported by app store reviews). On the other hand, financial tools like Venmo were popular but lacked the specific infrastructure needed to split bills quickly and easily.

We then defined the high-level tasks and the flow of steps necessary to carry them out.

This helped us identify additional features that needed to be included on top of the core features, as well as potential use cases and problem areas.

View in FigJam ↗

From there, initial sketches and wireframing.

To visualize the flows that we organized in the user story mapping, we sketched out the two higher-level tasks of creating a bill and paying off a bill.

We also created low-fidelity wireframes of the assigning system for future usability testing trials, where we could determine whether the system made intuitive sense to users.

Usability Testing

Before taking our designs to higher fidelity, we first wanted to check the usability of the systems and features we had integrated with end users. In total, we had 6 individuals test for functionality, during which participants would attempt to complete a task from the flows and then answer various questions about the task using the system usability scales (SUS) format.

Results & Analysis

All 6 individuals were unable to complete the task at hand. Only one ended was unable to proceed past the first screen, while the other five got stuck in the latter parts of the flow. The average task time was 29.4 seconds, which was longer than expected. These results suggest that our assigning system was not easy enough to understand.

This is further confirmed by the heatmaps -- the clicks were more concentrated in the first several screens and became more scattered and frantic as the flow progressed. Additionally, by the last screen, activity dropped by a drastic amount.

Through these findings, we came to the conclusion that the root issue was the tap-user-then-item assignment system, and that it needed to changed significantly to be more intuitive to use.

Feedback

All 6 individuals reported difficulty in completing the task because of a lack of instructions or intuitive design, while some reported even feeling overwhelmed by all the features on screen.

Reflections

To say the least, the results of our usability testing trials were incredibly humbling. We had carelessly assumed in our first design iterations that the assigning system made intuitive sense for users, when it was the complete opposite. It was a very necessary wakeup call that just because an idea works in your head doesn’t mean that it will work on paper!

We realized that we had gotten distracted designing the less important details.

Feedback from our course instructor and peers, in addition to the insights from usability testing, brought us to this realization. Instead, we needed to focus instead on elaborating on the app’s distinctive features.

So we restarted from the drawing board.

First, we reevaluated the necessary features based on the needs of our user personas and applied the necessary changes to our user flows. Next, we redid our wireframes and lo-fis based around these changes.

After receiving praise of improvement from our instructor during an intermediate check-in, we finally felt confident moving forward.

Displayed below were some of the key changes:

Once we felt confident with our designs, we moved to higher fidelity.

We continued to implement the feedback we gained from more informal critique sessions with our instructor and peers. By doing so, we were able to refine areas that needed usability and clarity improvements.

Some of the key changes implemented are displayed below:

An addition we made to our onboarding flow was the privacy feature for people discovery. By toggling a switch, users can have control over the personal information Bill Up has.

Visual Design

From there, the design system.

Bill Up utilizes a purple color palette, conveying trust but also innovation, creativity, and fun. The darker purples act as a solid base for our visual identity, while the lighter tints serve as subtle accents across the user interface.

The Bill Up interface consists of two different sans serif fonts that are legible at all sizes and professional, yet casual.

Future Iterations

The designs above were what we presented during our final semester presentation, where notably among the crowd was a panel of industry designers that our instructor had invited in.

We ended up receiving a lot of valuable feedback from the panelists, the general recommendation being to add features to incentivize users to stay on the app after creating a bill. This helped call attention to a major issue that we had previously overlooked, which was Bill Up’s complete lack of competitive advantages outside of creating bills to split.

Some of the suggestions we came up with to address this, which could come with future iterations of Bill Up, were:

Takeaways

1. The design process is not linear

As a designer and student, it is a natural instinct to defend the effort I’ve put into my own work; however, there were multiple instances throughout this project where I knew deep down that we would have to backtrack in order to get to the right solution. I learned that, though it may hurt, to fight sunk-cost fallacy and strive for the best product for end-users.

2. Never make assumptions for users

Our first pitfalls in usability testing came when we assumed that our designs would be intuitive to use. This experience taught me that when creating new products from scratch, it is imperative that we don’t make assumptions for the knowledge and expertise of users; instead, make intentions as clear as possible so that users can think less and do more.