Finn’s a student project supervised by Christian Hertlein, then Head of Design at fintech N26, in teamwork with Marius Claßen at the University of Applied Sciences in Potsdam.

The course “Crafting User Interfaces” was mainly about the problem of trust-building in the banking industry. It’s an obvious problem: with the advancing digitalization there is a gap of trust between customers and new—and yet untested—banks and service providers.

The task given was “Design a solution that focuses on the aspect of building trust in relation to money. Trust can be built directly or over time, involving financial knowledge transfer.”

The analysis of the typical usage of banking apps put forward a thesis we subsequently confirmed throughout the design process:

Actions taken in banking apps can be divided into general banking transactions and extended banking transaction.

General banking transactions are the daily functions of a bank such as withdrawals, transfers and deposits. Advanced banking are all the other services of a bank: investments, assets, loans and the like.

We think, there is a huge difference in trust regarding these two areas with new banking service providers.

In our opinion, both areas work for long-established banks such as Sparkasse or Deutsche Bank - they are established banks with a high transaction volume and with the trust of customers from several generations. Reliable and secure processes are expected here for extended banking transactions.

This trust is lacking in online banks, such as N26. General banking transactions are regarded as serious, extended services are not trusted and accordingly little use is made of them — this is reflected in their statistics. In the course of the problem-finding process, we also conducted a survey with 36 users under the title “You & Your Bank”.

Our thesis was confirmed thereby - the confidence difference between house banks and online banks is immense. Our comparison value (since trust cannot be measured in a particular unit) is very clear here: house banks have a trust value of 7.9.

In our opinion, both areas work for long-established banks such as Sparkasse or Deutsche Bank - they are established banks with a high transaction volume and with the trust of customers from several generations. Reliable and secure processes are expected here for extended banking transactions.

In contrast, online banks such as N26 and Revolut have a comparative value of 6.1 - almost two points less. The other statements were similarly meaningful. For example, our question about a fictitious chatbot with provocative comments pointing to dangerous spending behavior, a service that we have identified exclusively with online banks. 51.3% of respondents gave the idea 0 out of 10 points and the average score was 2.2.

Following these interviews and surveys, a clear definition of the target group was required in order to establish contact with them as quickly as possible and carry out early user tests. Summary of the problem identified:

Online banks do not yet enjoy enough trust in advanced banking, mainly due to the “start-up feeling” and previously unknown patterns that make handling large sums in mobile apps feel uncomfortable.

We were able to define our target group based on two factors:

• it must handle large sums of money on a daily basis
• it must fundamentally fit into the target group of online banks

This allowed us to quickly narrow down our target group, but we made the mistake of thinking in terms of too large target groups at the beginning. So we started with the target group of young entrepreneurs, graduates & startup founders and, after a few consultations, we had our final target group:

Start-up founders who receive a larger loan from an online bank and have an affinity for banking and technology.

This narrowing down allowed us to make contact with people from the target group early on in the process and test our idea directly.

After finding the target group, we quickly established contact with two Berlin start-ups that provided a good basis for acute problem-solving in the financial sector for start-ups.

The founders interviewed, who wish to remain anonymous due to the financial data provided, showed us what went wrong in their initial phase after receiving the loan. The most commonly cited problems are the enormous amount of time and complexity involved in the finance of a startup. Some examples:

• We don't have the time. We trust our finance department and tax advisors, who are always looking over our shoulders.
• In the beginning, we just wanted to realize our idea, and the money thing took away our energy.
• It would be cool if everything could be automated so that we could spend money without having to look at the financial year in advance.
• That way, we would also be informed quickly without having to leaf through this mass of forms.
• [...] and summarize only the important reports and deliver them to us in an understandable way.
• Anna writes all expenses in the notebook and on Friday there is a shutdown. Here she presents all the income and expenses that have been lost during the week.

In the course of the interview, some wishes were also mentioned, provoked by questions such as “If you could build a financial service provider yourself, what could it do?”

Here’s the compiled wishes that were most revelant when creating Finn:

• Ha! He should see all the finances and be vigilant about income and expenditure.
• It would be cool if everything was automated so that we could spend money without having to look at the fiscal year in advance.
• In other words, a sub-program that is linked to the business account and automatically submits and pays the monthly taxes and only summarizes the important reports and delivers them to us in an understandable way.
• If one tool could do everything for us, that would be great! However, Anna is too skeptical because she tried several tools and ended up having to use 3 or 4 at the same time.
• It was all too tedious and complicated for us. We had an idea and wanted to implement it quickly. We all discuss it together and just do it when it's worthwhile.
• [...] a tool that organizes everything for us automatically. It spits out all our requests and business aspects, organizes them and, well... maybe even talks to the tax office at the end of the month.

The research and interviews gave rise to a clear idea for our service, which we christened with a name early on.

Finn is a derivative of the proper name for Financial Assistant. This also describes Finn’s field of activity well: Finn is a digital banking advisor that covers a large part of extended banking transactions in addition to typical banking transactions.

Finn stands out from other banking apps due to its diverse areas of application: Finn analyzes past payments, suggests recommended actions based on them, which can influence its forecast of the future.

During development, it was clear from the outset that Finn should be a digital but humanly advisor and should have an influence on as many useful functional areas as possible. This was based on the goal of building as much trust as possible—one of the pain points in the interview was the lack of a “face” at online banks, a lack of human identification.

We want to cover this aspect through a permanent appearance and communication with Finn that is as human as possible and offer the customer the opportunity to build a basis of trust with Finn: As if Finn were the typical bank advisor in the branch.

In order to design the app using as realistic an example as possible, we came up with two different fictitious personas on which we could “test” pain points and touchpoints.

Using Manu, Loraine and Julien, we were able to provide a realistic environment for the design of Finn right from the start, in addition to communicating with the two Berlin start-ups.

In numerous analog iterations, we tried to get an overview of the required features, also using existing banking apps. We placed particular emphasis on information hierarchy and the relevance of the information displayed.

The first digital iteration was a kind of wireframe, which we used to get an understanding of the space required and to find out to what extent Finn, as a pure icon in the top right-hand corner, offers enough incentive for communication.

Based on the wireframe, we built a first, quite similar high fidelity prototype with which we conducted the first user tests (with people from outside the target group).

The focus on the first iteration was on the colorfulness and shows the first aspects of the notification module, which will later become the main area of Finn. On the second screen you can see the basic function of Finn: Finn analyzes the past and gives the user curated notifications, naturally sorted hierarchically according to prioritization and relevance, which keep the user up to date without requiring much interaction.

After initial user tests, in which it became clear that there was an absolute surplus of information, we tried to reduce the information presented and make it clearer. We aimed for a clearer line towards color and tried to create a clear division for the user by means of color codes.

Numbers in black represent Finn's first two areas of activity, namely past and present. They therefore show previous incoming and outgoing payments on the account. All cyan-colored numbers represent a forecast by Finn, which Finn has calculated from the account movements of the last 6 months.

In a feedback round after the third iteration, there was a clear break for us that had already become apparent in the user testing: the main interaction of the service, both in terms of content and design, takes place with the transaction list on the start page. This does not only apply to our service, as it to be the industry standard.

We noticed this because our testers spent so little time interacting with what is apparently the most important feature. In multi-layered use with Finn, the transaction list plays absolutely no role. Information should be processed and prioritized by Finn - a chronological list of all transactions made is disruptive and distracts the focus.

In a completely new and analog approach, we have rethought: what does a banking app look like if it no longer has a transaction list? What content does Finn then offer? It became clear that Finn had to move to the forefront. The analogy that helped us in the subsequent development is that of the social media feed: messages sorted not chronologically but by relevance, which can offer more interaction possibilities in a module feed than a pure list.

Over the next few iterations, our home screen has evolved from a typical transaction list to an interactive feed that informs the user at first glance and prompts them to take action.

The left-hand screen illustrates the above explanation well: in contrast to the confusing list, when you open the app you will now find curated messages from Finn that he “thinks” are the most relevant and require the most action.

The right-hand screen shows our first version of Finn's middle area of activity, the active action in the present. The idea is that our digital advisor should be as close as possible to the real bank advisor - so we have developed a system that is as far away as possible from the typical bank transfer screen.

The user's input is done by entering text, which filters the keywords and automatically enters them into the mask. This creates the feeling of communication in which the user can enter the same information but does not have to stubbornly click through the mask.

Iteration 05 has integrated another important insight that we gained from user tests: the information on the current account balance is not so relevant, which would justify such a concise position on the start screen, and therefore disappears to the Finn overview page. Finn has also changed in that it now displays relevant statistics in addition to a search and interaction option.

Like the first versions of the home screen, this screen was quickly recognized as overloaded - the information is too numerous and too confusing. These findings have been significantly improved in the final version.

After final user tests of the fifth iteration, the last weeks of the project were spent creating the last and final prototype. The focus here was on natural interaction and a hierarchically tidy presentation of the new navigation.

The new navigation, which was created in the fifth iteration, has a new pattern that strengthens the relevance of Finn - it is the literal turning point.

To summarize, the icon of a teal circle at the top of the screen is Finn. Finn can be dragged down with the typical swipe motion to access the Finn dashboard. Pressing Finn again starts communication with Finn and then offers the option of entering activities such as transfers or instructions for a forecast.

The navigation dashboard provides an overview of relevant figures such as the account balance and its development with analysis and forecasts. The user can access advanced analysis results directly without having to interact with Finn.

Otherwise, all communication with Finn takes place via the dashboard. If the user wants to make a transfer, start an analysis or call up a forecast, they can do so by entering text in direct communication with Finn.

An example of a bank transfer looks like this. Finn recognizes the user’s entries and automatically assigns them to the transfer mask. This ensures that the workflow is not interrupted and the user can simply write down the planned activity without having to refer to the screen.

Another example is a simulation game that you can watch here. However, the dashboard is only the passive appearance of Finn, which requires interaction on the part of the user. The actual start page is the module feed, in which Finn displays curated messages to bring the user up to date with the latest account status in the shortest possible time.

There are different types for this: modules that require user interaction are highlighted in color and displayed at the top of the feed. They are also graded according to color, with red indicating particular urgency.

If a module is clicked on, Finn directly suggests an activity that it considers useful. However, in order for the user to retain full control over their account, they must always confirm this suggestion - even if they only set the type of Finn monitoring. An example of this is a spending warning classified as red by Finn.

The user's loan plan contains a fixed amount that the company may spend per month on office supplies. If this sum is exceeded, Finn issues a warning and suggests an action. The user can either confirm this suggestion or select their own user-defined action using the navigation bar.

The difficulties during the design of Finn have all proved to be good experiences that we can use to better address weaknesses in future projects.

The most important insight is the enormous relevance of an extensive conception phase in which the idea is put to the acid test before the actual implementation begins. To avoid this pitfall, we tried to work analog to the maximum extent possible and only design screens towards the end of the project.

This ensured that we were able to go through numerous iterations and eliminate obvious and major errors - for example, the transaction list, which we checked in one of the iterations to see whether it had a right to exist in Finn at all.

It was also noticeable that we often delved far too deeply into the topic due to its complexity. A basic understanding is important in order to be able to deal with topics such as Trust & Education appropriately, but in our case it often involved complex registration processes for the loan and extensively calculated scenarios that were not conducive to the development of the service.

In addition to the important conception phase, we were also able to establish the importance of motion prototypes: the introduction of a new pattern, such as navigation, is complex enough and is not made any easier by the mere presentation of screens in documentation. Animated screens that can explain the movement within a few seconds were important there and were able to illustrate our navigation concept well.