Weave Payment Plans

Provide our customers flexibility in how they charge their customers. Creating our own payment plan product will allow our customers to avoid third party lenders (who charge borderline predatory interest rates) while offering "pay over time" features.

This feature isn't necessarily a revenue driver as it doesn't net Weave more money than a standard payment does. So the purpose of it really is to just provide further functionality and a positive experience for our users. Features like this are valuable because it makes the product stickier and increases the LTV (Lifetime Value) of our customers.

The main challenge we faced was in determining an MVP for the feature. We wanted to build the simplest viable version first, but being a financial product we had to make sure it offered all the essential features our customers (and their customers) would need. Some of the features we debated and, after some customer interviews, ultimately added into it are:

• Make one-time payment

• Edit billing method

• Edit payment plan (remaining balance, term, date of billing)

Ultimately we determined that without these features it could be a frustrating experience and not viable by our standards.

This feature isn't necessarily a revenue driver as it doesn't net Weave more money than a standard payment does. So the purpose of it really is to just provide further functionality and a positive experience for our users. Features like this are valuable because it makes the product stickier and increases the LTV (Lifetime Value) of our customers.

I wanted to develop a system interactions within payment plans so that any actions taken on the payment plan felt consistent, and also followed the design system for consistency amongst the broader Weave app.

I leaned on modals for most payment plan interactions because it allowed for the user to take action (sometimes multi-step actions) without losing the context of where they were, and giving them an easy exit path back to the payment plan.

Here's an example of one of the actions (editing a payment plan)

There's a lot of information for a user to process, so I wanted to organize it in a way that the user could see the previous information, updated information, and understand which is which. The original information is placed on the right because it's secondary info and not always necessary, but is there for the user's sanity and cognitive load.

After making edits, they're shown a confirmation page that highlights their changes again, and clear CTAs to either go back to editing or confirm their changes.