How I Designed the QuickBooks Mobile Deposits Feature

Every day, all over America, millions of small business owners get paid for their work. The pool cleaner, the interior designer, the friendly neighborhood baker. Some have ‘gone all digital’ with credit and debit cards, while others accept only cash and checks. That money, in whatever form, is almost always deposited in the bank at the end of the day. If you ever worked retail as a teenager you’ll certainly remember the blue pouch stuffed with cash and checks that was dropped off at the bank every night after closing. That’s still the way it works.

QuickBooks is the operating system for small businesses. From tracking customers and sales to preparing year-end taxes, QuickBooks is the primary tool small businesses use. After receiving payments, tracking deposits made to bank accounts is an important part of a small business’ workflow.

QuickBooks Online (web) deposit feature

The deposit feature has existed in QuickBooks for many years. The visual and interaction design on QuickBooks Online has seen several recent revamps, but when I joined the QuickBooks mobile team, there was no deposit feature in the native mobile app.

QuickBooks mobile users frequently requested the ability to enter deposits on mobile devices. Here’s one from earlier this year.

Business goal + design challenge

The product manager, David, had set the deposits feature as a priority based on customer feedback and usage data from the web version. The key challenge for me as the designer was adapting a core piece of the small business’ web workflow to mobile, with its different constraints and affordances, all while maintaining elements of consistency with the web experience.

Constraints

From the onset, the most important constraint to keep in mind was consistency with the web experience. Intuit’s visual design (at time of writing, Harmony) is well documented, which made it easy to ensure uniformity, but many of the interaction patterns used on the web didn’t directly translate to any of our established mobile patterns.

For example, this dropdown is a common web pattern, but is not ideal for picking from a list on the phone or tablet.

Additionally, the deposits feature is chock full of input fields — acceptable on a large screen, but completely unpresentable on a mobile device, where size of the screen is one of the main constraints. With this in mind, simplifying the mobile experience to focus on just the pieces that were critical to the mobile user was one of the most important tasks for this project.

Look at all these fields the user could potentially fill on the web! That isn’t going to look good on your iPhone.

Research and empathy building

Indifference towards people and the reality in which they live
is actually the one and only cardinal sin in design.
-Dieter Rams

I always try to spend time with real users before I begin drawing. There were a few fields on the web deposit screen that I didn’t understand (specifically the Track Returns for Customers checkbox and the accompanying fields it opened up), so after scouring QuickBooks help forums for answers I resorted to hunting down the PM responsible for the web feature and got some answers.

Armed with a basic understanding of the web feature, I found a QuickBooks Online user who was willing to walk me through how she records deposits. Fortunately, she’s a bookkeeper for several small businesses so she was able to give me insight into some of the nuanced ways different business types record deposits. Some businesses create sales receipts in advance, while others wait until they’ve been paid to record the transaction. I learned that the Track Returns for Customers checkbox is not commonly used and I got to see which of the fields are mandatory.

Another important part of the research for this project was ensuring I was following patterns established elsewhere in the app. Since invoices and payments are also workflows that can sometimes contain a large number of fields, I referred to those screens to make sure I was designing cohesively.

This is a screenshot of the New Payment screen. Since the look and feel of the app shouldn’t change from feature to feature, Deposits needed to leverage these existing patterns.

Ideation + Tradeoffs

I began hypothesizing about what parts of the deposits feature should be most prominent and what fields should be minimized. For example, I proposed that the mobile version didn’t need to initially expose all the fields under the Add New Deposits option. Instead, we could simplify the screen by showing an Add Other Deposit button that exposes those fields to the user only if necessary.

Simplifying the main screen shown here meant adding an extra tap for users with Other Deposits, but doing so removed a large amount of clutter for most users. This was a tradeoff our product team was willing to make.

In talking with customers I also learned that not all users have a mix of sales receipts and other deposits. Many small businesses only use the Other Deposits when recording a deposit. I designed the iPad version, which affords considerably more space than the phone, to show the Other Deposits fields if there were no existing payments to select from.

The deposits form felt too blank when there were no recorded payments or sales receipts to select so we added the Other Deposits fields.

Another example was turning Cash Back into a toggle and drop down, since this is not something all users do every time.

The tradeoff here is the extra step of toggling for the removal of 2 fields that are not used for every deposit.

Prototyping and iterating

After thoughtfully developing some ideas about my mobile approach, I created a quick prototype with Flinto. I then reached out to several small business owners, accountants, and fellow Intuit designers to see how they would use the feature and solicit feedback.

The PM and another designer both expressed some confusion over why the web was titling the header Add New Deposits (the copy the web team had chosen), so I proposed Add Other Deposits instead and worked with the Web team to make the copy consistent across the two.

In one prototype (screenshot below on the left), the customer’s name was blue and had the arrow positioned right beside it, but tapping there took the user to the payment, not the customer. Feedback about this disconnect led us to change the Select Existing Payments section to make it more clear where a user would be taken after tapping.

Access points was another nuanced decision. The tradeoff here was between putting a Create Deposit button in the ‘global create’ section/nav bar (the downside being an even more crowded ‘global create’ section) or to place the Create Deposit button in a more contextual create section under Registers (see explorations below).

Top left: Faced with adding a 7th icon to the ‘global create’ section we considered redesigning ‘global create’ vertically | Top center: The nav bar slides out from the left and allows access to many different features in QB mobile. This exploration added Deposits to the bar | Top right: Within ‘global create’, Note is the least frequently used so we explored replacing it with Deposit in order to maintain two rows | Bottom left: Instead of replacing, simply adding another button to the ‘global create’ section | Bottom right: Placing the deposit feature in the create section when users were already on the Registers screen (mostly bank accounts) seemed contextually appropriate.

Deciding where to expose access points is always a decision in trading off easy access with a clean interface (classic Google/Yahoo tradeoff).

We opted to allow access only within Registers, but decided to watch usage and place Deposits button in ‘global create’ if many users are using this mobile feature daily.

The iPhone and iPad designs had subtle differences as well. One of the key differences had to do with input fields. One the phone it would’ve been too chaotic to expose all the Other Deposit fields when a user tapped Add. On the phone we opened a new screen full of input fields a la creating a new contact in the iOS Phone app. The iPad affords more space, but still not the width the web utilizes for the many Other Deposit fields. We had to get creative about how to fit the all of the fields, but it made sense to keep the user on the original New Deposit screen if possible.

Other iterations for tablet Add Deposit interaction included opening a new screen like on the phone (left) and using a modal overlay (right).

Results and feedback

Since I was leaving the team for a six-month rotation at Intuit’s Connected Device Lab, I worked with the PM to document the iXD and vXD with commentary and notes. Though the dev team is still in the building stage, our prototype received rave reviews from small business owners and accountants which gave us confidence that the design was solving for our core customers’ mobile needs.

I loved this! This looks great! Having the ability to choose the payments and grouping them and then having the ability to add other things like an office supply reimbursement check or whatever is great.

Thank you for adding this, it was a glaring omission.

Love that you are caring about the mobile deposits. The simple entry of the deposits is one step but more important to me is the grouping of the payments properly for easier reconciliation with the bank. It completes the deposit and bank feeds process.

LOVE THIS!

A big thanks to the QuickBooks mobile team. Though I was responsible for the interaction and visual work you see above, I would’ve struggled much more and had a lot less fun if it weren’t for all of them. Thanks especially to Karen, David, Sherry, Brigette, and Will for their invaluable feedback.

If this piqued your curiosity, read more of my How I Design
design process stories.

And check out my portfolio at jacobmclaws.com.