Bill.com and divvy-content design

Bill.com is an online B2B payment platform that helps manage accounting and finances for small and medium-sized businesses.

Designing content in the FinTech industry can be quite tricky. Not only do we have to navigate government and financial regulations, but we also have the tall task of demystifying complex systems and methods of payment.

Project: Payment method conversion

Role: Senior Content Designer. Worked on a team with a product designer, PM, and engineering leads.

Business problem: As a business, we want to convert more users to switch from paying by checks to online ePayments. ePayments, are faster, cheaper, and allow more opportunities for BILL to expand their user base.

Previously, we didn’t have a lot of great ways to convince users to switch payments. Users were presented with a simple choice between checks or ePayments, but with no call to action or persuasive content to convince them otherwise.

Requirements: Provide contextual content for users paying by check when they might miss their due date, and give them the context and ability to switch to ePayments to make their payment on time.

Initial mockup (what the product teams used as placeholder)

Feedback and analysis:

• Too much content. This is a lot to consume at the moment I just want to pay my invoice.

• The benefit isn’t clear to the user. It doesn’t tell me how much faster, or what this might do for me.

• The process sounds complicated, and too easy to skip. We should make sure the user better understands what we’re asking.

  
  My approach

Execution

• Most beneficial items are directly in the headline

• The CTA’s match and answer the question the headline

• Removed jargon and complex requirements

• Specifies the immediate benefit in the headline (pay 2-3 days faster), instead of making it harder to read in the body text.

Result

I left the company before we could see the results, but the teams were very happy with the new content explorations, and are eager to launch this immediately to their users.

How I used content conversation design to improve completion rates by 21%

Role: Senior Content Designer. Worked on a team with a product designer, PM, and engineering leads.

One of the most impactful and highly visible actions users take on the site, are adding vendors to their network. Similar to LinkedIn or Venmo, adding vendors to your network expands your reach, enabling you to pay more vendors easily and simply.

For BILL users, adding new vendors to your list of connections meant that you can pay, receive, and get updates on payments easier and much faster.

The previous experience however, was less than ideal. Data showed that users on our site were abandoning the flow, not filling all details correctly, and generally having issues figuring how how to add vendors to their network.

One look at the previous UI, you can start to figure out where some of the issues may be:

How users used to add vendors in BILL:

So we did some research on the flow, and some of the initial impressions we had as a team were as followed:

• Users were slow to fill out the details.

• They struggled to understand some of the feature terms.

• They had to pause to realize they can scroll down for more information.

• We’re not really giving users any idea of what is important here, and what they should know. The closest thing is a red asterisk for required information.

• The content is impersonal and doesn’t convey the action taken. Example: Setting preferences isn’t quite accurate since this is a new vendor, and should be positioned as a new entry.

• The page (which scrolls down further) is quite a bit of cognitive overload, causing users hesitation and prevents them from making an informed decision consistently and repeatedly.

So the team took some feedback and we decided to go with a different approach.

We hypothesized that by creating a simplified, conversational add vendor flow, we could encourage and entice users to completing it at a higher frequency, enhancing our add venodr percentage rate.

Here was the initial draft:

We thought that in this case, simplifying the flow didn’t necessarily mean creating less screens. Quite the opposite. In this case, we hypothesized that by going from 2 screens to 3, would actually simplify it by making the content more contextual to where the users mental model is.

So we thought this was a good approach, but testing showed that people still struggled with the content and design here.

Further analysis:

• Including the payment method in the same screen as inviting the vendor to sign up (via email) is confusing, and causes the user to try and reconcile two different ideas in one screen. Both are a bit complicated and need their own space to breathe.

• Usage of “Bill.com” in multiple areas feels robotic and non human. User is already on Bill.com, why do we need to repeat it?

• The business goals are to get vendors to sign up themselves, so that the user doesn’t need to contact them for bank details, or send a check manually. This preference isn’t clear with the current iteration.

• Overall, it’s a lot of content to try and communicate multiple ideas, which ultimately leads to low confidence for the user to know what they’re doing.
  I’m always asking the question, As a user, what am I supposed to do?

My redesigN

PM requirements

• Need to add benefits of enabling ePayments

• Let user know they can still pack by check

The updated content design has a clear recommendation and CTA for the user to make a decision, which improved conversion and sign up rates in early testing.

• In the happy path, user selects “Yes, email vendor” and the flow is pretty much complete, since the vendor will receive an email to sign up for an account, and payments will be sent to the account they provide.

• If the user selects, “No, don’t use ePayments”, it then asks how the user wants to pay their vendor. Separating the screens allows the user to understand the different concepts on their own, reducing cognitive load, making it easier and simpler to process.

• By adding simple terms such as “Recommended”, we let the user what we want them to do, knowing that the recommended approach is easier, faster, and more beneficial to them in the long run. That allows them to make a quick decision if they want to complete the flow quickly.

If user selects “No, don’t use ePayments”

Now the user has two clear options for how to pay the vendor. They can select:

• Check: in which Bill.com will send a physical check to the vendor’s address.

• Bank deposit: in which the user will need to acquire the vendor’s bank info to send payments to their account. While not preferred due to it’s risk concerns, as well as not as advantageous for Bill.com’s growth goals, it’s still offered as an option.

Bank Deposit

If the user does select bank deposit, they will see an expanded form for them to fill out their vendor’s bank details. At this point, we allow the user to still change their minds, either by selecting check, going back to the vendor invite screen, or by selecting the checkbox and allowing the user to proceed without filling in all the bank info.

Conclusion:

This new experience tested well with small business owner, mid-market, and power users (accountants or admins).

• Early metrics show an increase of 36% to 40% of new account sign-ups (signing up for ePayments).

• Completion rate, or how many users completed the add vendor experience, increased from 50% to 71%.

Overall, the business and product teams are very happy with the new designs, and our customers like it as well. It’s been a pretty big shift for our company and I was happy to be a big part of it.

Project #2: Paying a bill flow

Communicating payments can also be quite tricky. When designing a flow for payment instruments, a content designer must consider both what the sender (payer) sees, as well as the receiver (recipient), and make sure that if the two were to communicate (which happens often), they both the right expectations for when and how this payment is made.

Problem:

Some users have expressed frustration with our payment systems, typically around when to expect their money, and how it will be sent/received.

Below was the previous experience when you pay a bill on BILL.

Solution:

Content changes:

1. Included process date so the payer can see when the funds will be withdrawn

2. Banking information for the payer to understand where the money is coming from

3. Changed arrival date to delivery date to provide clarity/consistency on how we talk about when the money should arrive to the receiver.

4. Added a tooltip to clarify this is an estimate, and not an exact date. By keeping it general, we can account for multiple payment types, from ACH, to check, international payments, etc.

By reducing noise and keeping the content concise, focusing on the payment details, we can improve user confidence and their understanding of what will occur with this transaction.

Results:

The team has approved and finalized the design, and we will launch the new designs this year (2023).