Building a chat? Start with user flowchart!
N26 is a mobile bank. All services it provides are digitalised, including our customer support.
The chat on N26 for Web and on the mobile app is one of the most important communication channels. It has always been available for N26 customers, and in October 2018 we launched a chatbot along with the new chat UI.
This article explains the complexity behind building the chat from scratch and our approach on planning and visualising the chat user flow.
When we started to work on it, the task looked quite easy: build the chat UI and implement the logic of sending and receiving messages between the user and the chatbot or the customer support agent. However, it turned out being way more complicated than we had anticipated at the beginning.
Here are some figures and facts:
- First of all, before becoming interactive, the chat goes through several initialisation steps.
- There are 6 possible ways of failure during the chat flow.
- There are 5 different types of messages depending on its author and purpose.
- There are 6 different user scenarios only when chatting with a chatbot. However around 75% of chat sessions are escalated to customer support agents, in which case we can have 9 different scenarios.
- There are 10 types of chat hint messages like, “Chatbot joined the chat”, “An agent is on the way” and so on. Three of them include illustrations and animations. Moreover, there are messages we create on behalf of the chatbot. For example, we display buttons when there are predefined answers available.
At the beginning we were like: 🤷♀️🤷♂️, then 🤔, then 🤯. If things are getting complicated and you heavily understand what is going on, take a pen and a piece of paper and start drawing! I started to draw a flow chart which would illustrate all possible processes, starting from the intent to open a chat to ending it. My teammates even gave it a name: Mad Diagram™.
Why is it so complex?
The complexity of the chat starts from the architecture. On the backend side there is a microservice which manages chat connections with the chatbot service and customer support agents through SalesForce. The client and the server communicate with each other using a third party service. Moreover, the client side logic makes the chat one of the most complex React components we have in our codebase.
After the chat has been opened, we need to make sure the UI module is loaded and the connection with all services is successfully established. Afterwards, the chat is ready to interact with and there are 5 possible events that can happen at the beginning:
- If available in the user’s language, the chatbot joins the chat
- Customer support agent joins the chat
- Neither the chatbot, nor the customer support agent are available
- The customer support agent is available but busy, so customer is put in the queue
- Although unlikely, the connection might fail entirely
Then, during the conversation, the customer can reload the page or close the browser and shortly come back. In this case we should keep previous chat session. The users can be timed out because of inactivity or lack of internet connection. They can minimise or close the chat. They can get pre-made answers to the chatbot’s questions which we display as buttons and handle as a short message when clicked. Or they can be invited to switch from the chatbot to a customer support agent. All of this, and even more, requires special solutions in terms of the application logic and design.
The flow chart example
The aim of the flow chart is to make complex things easier to understand, build and test. The example below shows how the following part of scenario should be handled:
- After opening the chat, a customer is put to the waiting queue. At this step, it shouldn’t be possible to send a message.
- If a customer minimises the chat during the queue, but a customer support agent joins the chat at that moment, the chat window should be expanded and it should be possible to send a message.
We illustrate the application logic with input events, decisions, processes, and views.
Events. The entire communication between our client and the server is based on the events. When you see an animated chat hint “We’re connecting you…” or “Agent joined the chat”, it means we received an event about that. The user sees only messages, but there are a lot of “hidden” messages on the chat’s background that the client-side logic should consider.
Processes. The logic of the chat is based on status system. There are 9 different statuses the chat may have, for example “session active” or “waiting in the queue”. With the help of those statuses we know if we need to render a chat component, when we need to disable the chat input field or if we need to show closing confirmation.
Decisions. A lot of decisions (or rather “logical ORs”) are made during the chat session; for instance, whether the user has minimised the chat window. The outcome of such decisions defines whether any event should be sent or processed to be started.
Views. It shows what should be displayed to the user in each step of the scenario. For every type of event or decision we define the status of UI and/or hint message that should be displayed to the user.
Conclusions
If you work on building a complex event-driven user flow with various scenarios, views, error handling and so on, I definitely recommend starting with a flow chart.
It is useful because it:
- Helps improving the communication between all parties (design, frontend, backend).
- Helps creating a consistent design concept (and not forget any possible case).
- Is a good reference one can rely on during testing.
- Becomes easier to introduce the project to new members joining the team.
Interested in joining one of our teams as we grow?
If you’d like to join us on the journey of building the mobile bank the world loves to use, have a look at some of the Tech roles we’re looking for here.
