Payments processing is a core business management problem facing founders operating eCommerce businesses. Early research and interviews have shown that small business owners are looking to improve the way they manage and pay invoices. Some are looking to optimize their cash flow, while others are looking to simplify complexity and find efficiency in processing. The challenge was to build a payments solution that scales with the founders, helping them manage and organize their invoices and aid them in distributing and spending their capital efficiently.

Part of the challenge was also to develop a path for founders to access additional capital when it was required for extending payment terms on invoices thereby building a “Buy now, Pay Later” for the customers.

Since the product was new, we had to work on multiple problems in parallel, run discovery, monitor the performance of freshly released experiments, deliver assets to engineers and strategize the big picture. 

During the design process, most of the time is spent discovering and thinking about the problem. The cost of solving the wrong problem is high. Iteration is also a constant process for designers. Before coming up with a final solution that goes to production, we experiment and try out dozens of alternative solutions. Most of them end up in junk, but the learnings are precious. Making mistakes during the design phase is much less expensive than after the product has been developed and released.

We scoped out the design work week and prioritized problems to solve based on our recent releases and iteration. This not only helped us move faster but also helped us align stakeholders while building an agile methodology to manage the product roadmap. 

Weekly design sprint structure

Stakeholders: Product, Operations, Sales, Marketing, Engineering.

Problem statement

With the start of the original Clearpay experiment, we saw customers uploading invoices above their capacity and returning customers not uploading invoices when there was capacity available. When Clearco couldn’t pay their invoice, some consumers had a poor experience, which affected both the founder and Clearco’s business. Because of this, the product had lower conversion and engagement.

Objective

Similar to a “Line of credit”, Clearco wanted to introduce the concept of “capacity” – which is how much capital Clearco can give a customer using the payments platform. “Capacity” is complex because there are so many variables involved in determining how much capital a user is eligible for and communicating this in a succinct yet understandable manner.

Goals

Managing expectations: Founders sitting out of capacity need to easily understand:

1. If there is anything they can do to gain capacity?
2. When will capacity be regained?

Be proactive. Notify Founders of freed-up capacity.

Help them understand how Capacity works …. outside the product

1. This is not a line of credit. Founders are confused about why capacity is not re-gained as they are repaying Clearco.

Hypothesis

We believe the Capacity module should help drive higher conversion on getting the very 1st bill from new users as well as getting subsequent bills since the remaining capacity will be constantly exposed to users. We know we will be right when we see a higher conversion with net new customers and a higher engagement with existing customers.

Success metrics

50% of users submit their first invoice immediately after signing up.

50% of users submit at least two invoices in the first two months after signing up. 

Design Principles 

Match Between the System and the Real World.

Minimize doubt, fear, confusion, and hassle for the founder.

Affordance: how do I use it?

Research – How have others?

Ideation sketches

User Testing

Background

The purpose of this study is to gather an understanding of how the capacity modal on the main landing dashboard is understood. This includes the potential amount as presented, the steps required to confirm the potential amount, and the word/usage of capacity itself to label the potential amount available to the Founder for BNPL transactions.

Research Objectives

Behavioral

What is the understanding of the capacity as presented when they first land on the screen after completing the onboarding steps including providing their monthly revenues estimate?

What is noticed on the main page at this point? What is not noticed? What is missing that they are looking for?

Is there a frame of reference for participants to compare capacity to? If yes, what is it? If not, is it clear what capacity means to them?

Are the info tooltips engaged with by the participants throughout the flow? If not, do they have questions that could be answered through the information contained in the tooltips? If yes, do they receive the information they were seeking? What information was missing, if any?

Do participants notice that they need to connect their accounts in order to confirm the capacity available?

Do participants connect their accounts, what happens as they move through this flow? What works, doesn’t work, is missing

Do participants understand the revised capacity states; (1) where they are not provided any capacity? (2) where they are provided with a decreased available capacity amount

How is the information the capacity bar is trying to disseminate understood? (ie. amount outstanding, the amount available, total capacity)

Share-out document

Final screens