Building a Fintech Product
At Advicefront I was responsible for understanding user and business needs as well as for conducting user research, for information architecture, UX and UI design, product strategy and planning. I was also the only designer at the start, lucky enough to have the unique opportunity and freedom to create a whole product, from scratch, with an end-to-end approach.
During most of my time at Advicefront, the team of six, myself included, comprised two business managers (CEO and COO), one full-stack developer, two front-end developers. A design intern was later hired to assist me, reporting to me at all times.
As a product, Advicefront is almost like a private marketplace, bridging the gap between financial advisers and their clients. It is a web-based app with two sides, one catering to financial advisers and the other to their clients.
Traditionally, a financial adviser’s relationship with their clients would be based on one-to-one interactions, such as meetings, which is not very time-efficient. By introducing a logic of bulk management, automated processes and a centralised view of all clients, Advicefront saved financial advisers a lot of time and allowed them to effectively manage many more clients at once.
One of the challenges I faced was the fact that all processes involving financial advisors and clients happen offline, they are very bureaucratic and they have to be legally compliant. And seeing as they deal with clients’ life savings, communication and information sharing are key. The process therefore needed fine-tuning and it was interactive in nature.
The whole process can be outlined in four important moments: Engagement, Data collection, Advice and Execution (see the figure below).
1. Onboarding and detailing your own financial goals
Typically, advisers start by working out a profile with their clients, proposing a financial plan only after they have thoroughly understood their clients’ life goals — acting somewhat like counsellors!
At Advicefront, we simplified the process by turning the entry page into a self-service tool so that clients can define their own goals (a plan is a collection of goals), with real values and time-slots, before presenting the whole plan to the adviser. This allows the product to scale properly and the app can gather plenty of valuable information right away, thus reducing advisers’ workload.
For onboarding, we created a very short and interactive questionnaire composed of a few key questions — with tips and help text to provide context and educate the user — from which three main goals are automatically generated, the clients can then fine-tune their plan. In order to test assumptions and design solutions.
To validate this feature we conducted user testing sessions and coordinated feedback sessions with highly engaged financial advisers, who were involved in the product’s development. Eventually, with the right copy and design, we managed to get good feedback from our user interviews!
Creating / modifying a goal
For the client to create a financial goal we introduced a self-service approach. The interface therefore needs to be clean and informative so that clients can feel comfortable enough to engage in experimenting with several amounts and values for their personal goals.
2. In-app messaging system
One of the first features I had the pleasure to design was the in-app messaging tool, which allows clients and advisers to talk online and enables advisers to search for words within a conversation.
Recording information and conversations was also a great way to fight a business requirement — compliance.
Setting expectations for users within the app proved to be a fun challenge. A messaging app feature needs to communicate how prompt the reply is likely to be. We set expectations by creating copy that read ‘we normally take 5 days to reply’ (the time can be customised by the adviser), which also worked visually, ensuring the feature looked more like an e-mail than an instant chat.
It was essential to set expectations on both client and adviser sides. On client side, messaging works one-to-one — the client has one adviser only — whereas on adviser side, the messaging feature allows one adviser to connect with an endless list of clients, which is a big difference in terms of design. There were many mini-features planned for the messaging section, but our focus at the time was on building a solid MVP (see images below).
3. Client Acquisition for Advisors
This is an important component for advisers as it allows them to generate several client leads, in bulk, to the platform. Advisers can send template or custom-made e-mails, offering help to their clients so they can move up a step in the process.
Notes on research
‘When do you consider a task successful?’
At one point in the project, I needed to better understand the reality of how advisers work with clients end-to-end. I researched several tools, such as jobs-to-be-done, but I needed parts of it to be different. Using existing concepts from a range of tools, I grabbed a pen (and later illustrator) and I built a tool to interview advisers. I aimed to find out how they do their job, task by task, and at what point they consider the job successfully done. Finally, I asked what SaaS and tools they liked to use.
After a few days of booking time slots with all the stakeholders and the management team, we interviewed advisers.
From the tool mash-up I used, the most revealing formula was a simple one I found in online books (see red section of the diagram). I asked advisers to rate the Level of Satisfaction and Level of Importance of a task from 1 to 10 — the resulting difference is the Level of Opportunity for a certain moment. This turned out to be great tool for us since it mapped out the level of opportunity to build the most relevant features as advisers themselves saw it!
A few interviews in, it became obvious that the client profile feature should be improved, as the process was tedious for the user, and a digital, intelligent form should be built We knew this meant innovation space! Here is an image of the client profile we built after these interviews and new insights:
User testing with adviser and clients
Building maps of the flows was an important part of the project. Zooming out of detailed interfaces as a constant reminder of a whole picture of the product was crucial for design as well as development.
We still did not have analytics because the product was yet to be released, so I started doing qualitative research and carrying out user testing for both advisers and clients.
User interviews were always recorded and notes were taken. To prepare for the interview, we would make a guide of suggested tasks and carefully introduce the idea of the test to the user so they felt comfortable during it. In the end, we analysed the notes and entered the data into NomNom, an amazing app we had the pleasure to work with while it was still in Beta. I kept and organised all user feedback on this platform (you can read more about this below, in the section ‘Notes on product design’).
Notes on visual design and branding
How to design a white label product?
As you may know, all advisers in the UK (or target country for a start) hold their own brand and therefore colour. As a white label brand, at Advicefront, advisers can configure their colour with us. All icons were designed with that intention in mind, all fonts and symbols required a bit of an extra effort together with the front-end work, but the result was great.
Illustrations for a human touch and educative onboarding
I’m a designer first and illustrator second. In the onboarding for this product, we thought illustrations could add up to something quite unique. Most importantly, we believed they could make the process feel more human. Finance as a subject can feel heavy but there are moments in the process and parts of the relationship between the app and the user — and between the client and the adviser — that will involve various degrees of emotional investment. Our challenge was to find those moments — onboarding, goal creating, risk tolerance and risk capacity surveys and the profile in the header section — and humanise them.
Notes on product ownership
I would like to add that my responsibilities as a Product Owner also included priority management. This was pushed by the management team as some feasibility guidance for product building was needed at the time. I had the pleasure of being mentored by Diogo Teles, former Product member at Faber Venture. Out of that mentoring came this scheme (see image below), which was how we prioritised features at Advicefront. After Diogo left, three weeks into my time there, I became responsible for the processes marked in pink below:
This very complicated looking diagram describes a feature cycle until they are released. The cycle kicks off with a deliverable that was released, then feedback is immediately requested, (internal ideas + interviews might also come in at this point), then all feedback plus next features are classified and prioritized so that features can prioritized and discussed on Roadmap meetings.
This was a generic scheme for the team, it would help immensely in terms of setting expectations for pretty much anyone, from investors, managers to the team. This generated confidence has it would help the team focus and have less tasks on their plate. It mounts up to an informed roadmap, as well as it insures that team ideas and client feedback have a very special place of their own at all times.
Thank you so much Advicefront for allowing me to be part of this special project, specially the management team which showed so some much confidence in my work at all times.
Thank you so much for taking the time to read this case-study.
To build this project, I used the following tools: Trello, Jira, GitHub, Invision, Zeplin, Photoshop, Illustrator and Sketch.
If you have any questions feel free to send a message!