Lending Club
Earlier, I wrote about a key competitor: Prosper.com, and its 1-click borrow flow.
Scenario
Let's say you're a borrower with a $4,000, 36-month term loan on Lending Club. Your monthly payment is $130.47 (Figure 1).
 |
| Figure 1 |
Problem Summary
What happens if you want to pay off your loan faster, or wonder what happens if you change the monthly loan payment amount? How would you approach this problem as a product manager?
Possible Solutions
First of all, as a product manager, your job is not to do the user-interface (UI) design work. You have design experts who would be insulted if you thought you could do their work for them.
Rather, your role as a product manager is to explain what the goal of the feature is: explain the benefit to user and to the business, and help the team understand why it's important.
That said, I don't have a designer, so by way of communicating, I'm going to share a few screenshot mockups to illustrate a few possible solutions to the problem.
When possible, you want to think in terms of common design patterns. Be creative, but not too creative. A common UI-pattern for changing prices is a slider (think Kayak).
Slidebar
In figure 2, I borrow Kayak's price slider to let the user perform a "What If" analysis on the summary page.
The bordered box and the fonts clarify to the user that the loan term has not changed. This is simply a what-if calculator for informational purposes.
An alternative to leaving the UI as is, would be to make this kind of calculator a pop up, or placed on the side navigation bar (below the referral incentive, for example).
 |
| Figure 2 |
Payment Spinner
Perhaps another way to solve the problem and keep the UI clean would be to add a spinner to the Next Payment line. In figure 3, you can see the up and down spinner, and next payment dollars in brown font.
It goes without saying that the amortization calculator in the backend would adjust the due date accordingly.
 |
| Figure 3 |
FAQ Approach
Now, I am not a Lending Club product manager, and therefore do not have a broader view of the problem and its impact. Let's suppose I have access to customer support calls, and this happens to be a frequently asked question, and something that is not yet automated.
The best first approach to this problem might simply be to provide the user more information (it'd be worth parsing some of those customer service calls) and provide a self-serve page explaining the impact.
All you really would need is a hyperlink that answers "Can I pay more?"
In figure 4, I visualize what this could look like. I added a red dot with question mark as a way to create a common UI pattern within LendingClub site itself. Whenever we find a common question, we can insert it within the default screen. It acts as a supplement to the "Common Questions" already found in the side navigation bar.
 |
| Figure 4 |
Stepping Back and Advocating for the User
It is the product manager's job to advocate for the user, and understand the business goals. If the user wants to increase the monthly amount (in the slider example), it could be a signal of financial strength. However, if the user wants to decrease the monthly payment, it could be a signal of some problem. For the business, this presents an opportunity to deliver user delight, and at the same time mitigate business risk (for example, by providing pertinent information or options that mitigate default risk).
On the whole, I think there are other small improvements that can be made to the summary borrower screen.
For example, as a borrower, I really want to know what the overall amount of money I am paying is going to be, interest and all. Rather than purely text-based rendering of that information, a progress-bar type of visualization could be much more effective (and would be relatively easy to implement).
And as a borrower, I might be confused to see the lenders of my loan. Thus far, nothing in this space has shown me I have any incentive or useful interaction with the lenders. It's a distraction, unless it were clearer to me what I am to do with that information (figure 5).
 |
| Figure 5 |
Testing, Revenues, Summary, etc
Let's suppose that the user actually wants to pay off the loan faster. The first task is to work with the designers to design some possible solutions (as we did above). Next, we would want to consult engineering (or communicate to them) to ensure that the implementation is feasible within time or other resource constraints.
I can say that all of the changes suggested above are mostly cosmetic, and would not take long to implement. The thing is, you don't actually know a priori whether it is going to help or harm your business.
Testing
You already know that I'm going to tell you you need to test. Since the changes are relatively easy, I would opt for having multiple versions of possible solutions and running A, B, C tests in different markets and segments to see which ones perform the best.
Revenues
Moreover, for those borrowers accelerating payment, you want to convert that intent to a new call to action. For example, "would you be interested in becoming an investor?" Why not, you have money spare.
Here, Lending Club has a potential weakness. Unlike on Prosper.com, on Lending Club, you need to create separate accounts to lend and to borrow. Why? Why can't I be both a lender and a borrower from the web product perspective (never mind the regulations for a second)? The answer is, no reason at all!
As it is, Lending Club will need two separate email addresses from you for you to be both a borrower and an investor.
 |
| Figure 6 |
You might also like ...
If you enjoyed this product teardown, be sure to check out:
