'Loan transfer tool', what customers need?
Within Nationale Nederlanden originally a dutch company, my role as a UX designer was to design a loan transfer or comparison tool in collaboration with the Agile Finance (end-to-end) team, stakeholder bank, and team research. Below I give a description of the process, challenges, and choices. Unfortunately, not all the images have been translated into English.
Exploring context
Previous research and google searches have proved that loan transfer is one of the biggest loan goals. So I received stakeholders' requests to create a loan transfer or a comparing tool. Unfortunately, the compliance colleagues had rejected a previous tool request because it was misleading. So my greatest challenge was to put stakeholders and the team in the customer's shoes and get approval from compliance. So my first plan was to include team, stakeholders and compliance in the design decision while keeping an eye on the customers using the 5 W's.
Getting buy-in for discovery
With the 5 W's, I could find gaps and make assumptions about users' needs and behavior. However, user research was needed because we couldn't rely on what we were unsure about, but I had a challenge here. How to get buy-in from stakeholders and the team to do more than usability and understand who we were designing for? I decided to use low-fidelity wireframing to get buy-in from stakeholders and compliance in combination with the five w's. It was a suitable method with low effort for understanding the mindset of stakeholders and compliance employees; before moving to the final design and creating expectations for the final design that would need to be built immediately. With wireframing, we could discuss with compliance and see their wishes without much effort to change the design. Stakeholders were happy because we got their buy-in, and it was much easier to get their approval for research. However, we needed more research to understand customers' needs and see if our assumptions were correct.
Preparation for research
In the previous phase, I convinced compliance to design the tool and the team and stakeholders who only knew about usability testing to do user research. With the research team and stakeholders, I formulated hypotheses and research objectives (defined the scope). I have drawn up a research approach and recruitment plan with the research team. I decided to combine usability testing with interviews. This combination helped me understand who the customers were and how they would react to my design. It was a challenge to test the first design remotely, so I went a step further and made a testable prototype where they could go/click through, and
​
"I understood why customers get a loan and whether a loan transfer tool would be enough to encourage them to transfer a loan and transfer it to one loan".
​
Finally, I invited the stakeholders and the team to attend the research. It made the team empathize with the customers and understand the design decisions and changes I had to make later.
Findings from research
We had planned to do the research with eight respondents, but due to a technical problem, five have remained. But that still gave me many insights to improve the design. I acquired insights about their needs concerning taking out a loan, their concerns, their knowledge, and the extent to which the design meets their needs. I was able to recognize that only the tool was not enough to meet users' concerns and conditions (see visual). Also, on whether a loan transfer tool sufficiently meets their need when taking out a loan. The answer to this question is that with some adjustments, it only partially meets their needs. I estimated short and long-term decisions. Using the Impact & Effort scale with stakeholders and the scrum-team makes these decisions actionable.
High Fidelity Prototype
The next step was to transfer the insights to a high-fidelity prototype with more interactions. Again, I included the team to create new ideas. I used the insights and issues from the usability test to develop a responsive design. I started with the smaller screen (mobile and transferred it to the desktop screen). Because of the usability test, the design needed huge changes and transformation to the company brand and design system. Because of those changes, it was necessary to test it again with customers, but this time with a high-fidelity prototype. For testing, I used different scenarios:
1. comparing one loan
2. comparing more loans
3. negative outcome
4. positive outcome
Of course, with all the design steps, I communicated with the development to check the possibilities. And with stakeholders to be on the same line. Stakeholders reaction:
​
" I am convinced that with this tool, we can easily provide customers insight into existing loans and/or refinancing. We, therefore, add value for the customer. So a compliment to you in that regard."
​
Follow Up Customer Journey
From user interviews, I observed that besides a loan comparison tool, more actions were necessary to fulfill user needs. Mapping out the customer journey was a usable method to show stakeholders and the product owner that a tool may be just one of the needs we will fulfill for users. I demonstrated to the team and stakeholders what we had already done and what steps would still be required to complete the customer journey.
We need more research, resources, and time to map the entire customer journey.
Learnings
I learned a lot from this journey, and I would like to share some of my learnings.
When do you start with the ideation phase? I know it is valuable to ideate and test as much as possible, but this is not for UX unmatured contexts that are more familiar to scrum only for developers. Asking for ideation can feel invasive with the different experts who expect everything to go fast.
"Design based on functionalities and usability tests is the smartest to start with in this context".
To allow design and development to interact more logically, starting with story mapping seems to be a better approach for this project. However, the association of the environment with design and designer remains challenging, and going too fast can create resistance. In addition, several projects run simultaneously with different subjects and stakeholders.
"Therefore, starting one step ahead and with multiple story mappings simultaneously can be the solution".