Background

Inbank is a financial technology company that connects merchants, consumers, and financial institutions on its next-generation embedded finance platform. In 2023, Inbank went through a major rebranding and restructuring, and as the first designer to be hired I was tasked to work on rebuilding our digital channels, focusing on our Hire Purchase products and our customer service back office. Here I'll be describing the Hire Purchase project and a little bit of my process.

Mapping the flow

Before starting the project I spent a good amount of time mapping the steps of the whole loan application in Estonia. This map takes into account all the main touch points and actors (customer service, back office, partner portal, hire purchase, store system, and customer) and shows where they interact, the flow of information, notifications, and decisions that can happen throughout the process.

Done in Miro, based on several BPMN files and interviews with PMs and Analysts.

Goals of the project

• Analyze the current flow together with PMs and developerss to improve the flow and prevent current drop-offs

• Apply the new brand identity and make it feel lighter and modern

• Develop design components and kick-off our Design System

First steps - Landing/Summary and identification‍

Here is were the customer lands after making a purchase and selecting Inbank as their payment method. I decided to use a narrow body that would keep the content visually similar on both mobile and desktop version. Based on feedback, I put more emphasis on the numbers that actually matter, grouped similar information and used stronger colors for actions that move them forward, although they still can edit some of the conditions.

After agreeing to continue, the user is prompted with the available methods of identification. The methods vary by country, so the "method tabs" can vary in number and because of that this component allows for multiple lines.

Next steps - New vs Returning customer, and offer

After identification, if it's a new customer, they are presented with a form to fill in their personal data. If they are a returning customer they only need to confirm their income data. This step can vary wildly depending on the country, as we can get different responses from each country, and we are also bound to local laws and regulations that dictate what kind of information we need to ask.

Despite that, this formula (personal data block, additional data block, consents) has been working very well as a basis for all countries.The customer can edit the data with the same logic and the step 01, they can clearly see the currency expected and tooltips with more information in case it's necessary.

After the customer confirms his data and continues, we run checks on the background and in case we have a positive offer, this is the screen that they see. I again grouped the most important numbers on the top and the details on the bottom.

On the top, we have extra space to accommodate different cases were we need to display other data, such as downpayment, changes in financed amount, etc. In case of negative, they are sent to a "thank you" page, but if we need more data in order to provide an offer they are redirected to an Account Information Service (AIS) where they can either link or upload their account statements. I also designed this part, but I'll post on a different project.

Final steps - signing and down payment

After signing the contract, the flow can already direct them to an end screen and later redirect them back to the merchant. But in some cases they still need to make a down payment in order to complete the process.

So I designed this component that can accommodate any number of available banks in that country. We can configure the amount initially displayed, and collapse less used methods in order to unclutter the view.