FreshBooks Project Hero

FreshBooks

Overview

FreshBooks is a B2C invoicing platform focused on small to medium-sized businesses. As the first design hire in the EU, I co-led the strategy and execution for the expansion into the European market. Two of the key aspect of the strategy were:

  1. Improve the experience of users and their clients. In order to adapt the payment experience for the many needs of the EU market, we had to rethink the experience of both the person sending the invoice and those receving it
  2. Improve the backend of bank transfers to meet the expectations of our users.
FreshBooks Payment Experience

Improve the Payment Experience for EU Businesses

FreshBooks'core market—North America—is credit card–focused. The EU market is much more nuanced, each country with its own preffered method. FreshBooks payment flows were designed with credit card in mind, and so the UI didn't scale well for the EU. The way to solve this was to reduce the complexity of the payment section of the invoice.

Payment Settings After Redesign
1
Disabling payments is now a parent setting instead of a sibling to payment gateways.
2
Sending to client is separate from charging. This allows to focus the payment options.
3
Charge automatically only shows options to use saved methods, or save new ones.
4
By focusing the options to a specific way to get pay, we reduced the clutter and could introdcue helper text.
Payment Settings Before Redesign
1
Selecting the gateway takes 50% of the payment panel even though it is the least used. Most users collect payment the same way over and over.
2
Disabling Online Payments is set as an option under the gateways. Selecting disable payments entirely, so it should not be a sibling of payment gateways.
3
Partial payments do not work with automatic payments, but it still shown as option and is selectable.
Payment Settings After Redesign
1
Sending for payment does not show automatic payment related options
2
Our data shows that 90% of user do not chnage the payment gateways. It's a set and forget type of options. With the new design, we leverage that behaviour by further simplifying the options.
3
Partial payments are now only visible when the user can actually request it.
Payment Settings Before Redesign

Next: the client experience

After fixing the Online Payment Settings for our main users, we looked at the experience of the person paying (the client). Our goals were:

  1. Redesign the checkout experience. The client experience also had scalability issues do the the layout accounting mostly for credit cards and not more complex payment options.
  2. Increase conversion rates. We wanted to test our assumption that poor usability was affecting the clients payment rate success.

    3. To address the scalability issues and the low conversion rates, we tested a redesign that put the payment experience front and center.
    We ran A/B tests with variations that placed payment options front and center. This gave us more space to present helpful, contextual information and allowed us to use progressive disclosure—showing only the options relevant to each user's flow.

Client Experience After Redesign
1
The header now focuses on key information users want to see at first glance.
2
The payment section is separate from the payment capture. This helps separate the intention betwen choosing what to pay and how to pay it.
3
A clear segmented nav option to choose payment methods.
4
By moving some of the information in the header allowed us to de-prioritise the invoice, offering more space to focus the experience on payments.
Client Experience Before Redesign
1
The head of the payment section is heavy with unclear options e.g. what does "pay future invoices" automatically. User consistently reported confusion with this feature.
2
Users often missed the tab to choose card or bank, due to the different element taking more of the focus.
3
User were often confused by this checkbox. Is it related to the automatic payment for this invoice? All invoice? Will I be notified or charged without notice?
4
Tooltip placeholder 4 - describe improvement here
Bank Transfers Backend

Unifying and Simplifying Bank Payments

FreshBooks' bank payment existed across multiple pages. This means users had to navigate to different pages to set up a bank transfer payment. This unnecessary complexity caused two main issues:

  • Poor discoverability. In order to use bank payments, users were expected to set up bank payments at the client level or the options to get paid via bank wouldn't be visible on the invoice. This caused many users to assume bank payments were not possible.
  • Inconsistent UX. Charging with cards or with bank transfer required setting up each payment in different sections. In other words payment settings existed in different parts of the product, creating unnecessary complications.

Key Improvements

By doing a simple backend change on the logic of bank transfer we solved both issues. Now when an invoice is sent, the system automatically checks for the bank transfer authorisation, required to charge via bank. Instead of expecting the user to do it, the system is capable to check and send a request as well as an invoice is needed. Simple, easy and effective.

FreshBooks Project Footer
Previous
Next