Borrower’s Portal Notification

Going back to square one

First, I’d like to mention that several of my projects at Uplift have not been implemented yet. Therefore, I am not able to post and discuss them yet. This feature that I can discuss (but can’t post any visuals yet) had an interesting journey that I wanted to share.

background

Uplift has a user portal called the “Borrower’s Portal”. Customers with accounts and loans with Uplift can log in and submit payments, download documents, update information, and more.

project journey

The scope of the project was simple: create an error message that notifies the user to take a certain action (make a payment, update payment method, etc). Using Uplift’s standard error message design, I worked with the copywriter to come up with clear and concise messages to cover the basic use cases. After I presented my designs with the product managers, the project quickly spiraled into a complex enigma. There were several permutations of actions that I hadn’t originally thought of, which complicated a lot of the messaging. For the next round of iterations, I came prepared with several use cases to cover the majority of permutations. It became obvious that these designs weren’t scalable, especially for cases that may pop up in the future.

I took a step back and decided on a different approach. I evaluated all the use cases, edge cases, and behaviors in the Borrower’s Portal, relating to my project. I narrowed it down to two major actions that we wanted the user to take to resolve the issue we were running into. One action was to make a payment, and the other action was to update the payment method. All the use cases could be organized into one of these groups. It was a total “Aha!” moment. The copywriter and I were able to come up with clear, informative copy to direct the user to the correct action.

I presented my findings and new designs to the product managers, and it was successful! They came up with hypothetical use cases, and I demonstrated how they can all be sorted into one of the two action categories. Everyone signed off on the designs, and the project was closed and put into the engineering queue.

lessons learned

Sometimes it’s so easy to develop tunnel vision. I wasn’t able to see the bigger picture and overcomplicated my designs. I had to step back, start over, and strip the project down to pinpoint the issue and potential solutions. This project rediscovery was a solid foundation for the rapid ideation and iteration that followed.