Although there's a plenty of room within web design to add as many functionalities as we want, I'd still like to present the most essential parts of the low at beginning. This is how the transaction model looked on web. The tricky part is understanding the freedom we give users to customize transactions, which means we had to ask ourselves: Within the split transaction model, what are the goals that users want to achieve? What functionalities do they need?

As I mentioned before, I conducted some competitor research, and realized that most of the transaction tracking on the market looks very similar to Excel. That's not particularly surprising since some users are over the age of 50 and are not familiar with tech products, so they chose to use an Excel spreadsheet to track their Net Worth, monthly spending etc. In order to reduce the cognitive load for users, I wanted to keep the Excel paradigm as the framework, then make some tweaks to the details afterwards.

Most of our competitors have decided to use a modal to split a transaction, and inside this modal they only show the child transactions. This means that if you are just looking at those screenshots, you probably have no idea what parent transaction they're referring to. (In this example of a spreadsheet, you can clearly see "Costco - Groceries" and "Costco - safe" but you don't know the total amount of the original transaction unless you scroll down.)

Another reason we opted for a different treatment is because we want to enable users to edit the description of a parent transaction at this step, because the original description pulled from the server end just captures the merchant information, which sometimes is not enough to remind the users of what it was for -- was it a team-building or a birthday party? Our users are quite fussy about the ability to customize transactions, so we wanted to make sure the parent transaction description also makes sense to them. Thus, we wanted to incorporate the parent transaction details here as well.

Secondly, I think it's better to show the original total amount in the same column as the child transaction amount (Mint has done a good job here; Yodlee shows the original total amount in the table instead of on the modal.) This way, when users are working on their transactions, it's easier to map and compare.

Yodlee allows users to add a note to each child-transaction, whereas Mint only has the ability to assign them to different categories. We allow users to not only can assign transactions to different categories but also assign them to multiple tags (including default tags and customized tags). For example, if you split your transaction in half for something reimbursable, you can assign that half to the tag "reimbursable," and that half won't be calculated in your monthly budgeting and cashflow.

Edge Use Cases: Undo Split, Error (Edit Split)

When looking at Error State and scanning from top to bottom, you'll find it's way easier to figure out the remaining amount to assign by checking these highlighted red text, and then you can fix it at that amount in the text input field.

Making It Contextual on Mobile Behavior

After the framework of the web version was locked down, I started to work on the mobile version in lower fidelity. In the meantime, I was working closely with the mobile team to check the feasibility and get their input about the design. The first approach I took was leveraging an iOS contact editing pattern here so that users can easily add another split or remove a split, as well as edit a specific input field to modify the amount or assign a category or tags. The second approach was one I got inspiration for from receipts in the real world - it lists everything down and shows the total amount at the bottom.

There were two points that the team kept arguing about. The first one was about how to launch the feature from the entry point - did we want to expand the function on the existing page or take users to a separate page? That was something I wasn't sure about myself at the beginning. Personally, I prefer to have a separate page so that everything is visually clean and users can focus on the child transactions like in the web version. However, as I brought this to user testing, users preferred to keep everything on one page, since it meant they didn't need to drill in too deeply to complete their tasks.

The second point of contention was about how users actually use the tool on a mobile device. Do they customize child transactions one by one, or assign the amount in the beginning and then finalize the other input fields, such as tags or categories afterwards? We thought the first option, to scan all the child transactions and split amounts, would be easier, whereas with Option 2 users might need to scroll down to see each amount. To clarify this point, I conducted user testing with some co-workers from another team, and the result was half and half. It seems that users might have different habits and therefore the test results in this case couldn't help us make a design decision here.

Make Design Decisions Not Only Based on User Testing

I took some feedback from the user testing session, and continued to iterate on these two options. After syncing with the web team and mobile team together, an interesting viewpoint emerged: they thought the first option had too many actionable components, so users might get lost.

To some extent, I agreed that the card option (Option 2) was better at displaying the information progressively rather than throwing everything in the user's face. Secondly, the card approach was more aligned with our mobile design system, so we decided to go with the Design Option 2.