How client and supplier can build a fruitful partnership.

VisualVest also serves as a platform-as-a-service provider for the cooperative banking sector in Germany. Their mission is to make financial investments transparent and accessible. They have been the first so-called robo advisor to offer sustainable investment fund portfolios. Sustainability and social responsibility have been drivers for VisualVest since its founding.

Given the continuous growth of chatbots, machine learning, and mobile messaging as interaction tools, the idea emerged to utilize this strategy for engaging new and existing customers interested in financial topics.

Chatbots don’t offer frictionless communication. As a chatbot user, you need to text, think about how to phrase the question, and rephrase as long as the AI gives a reasonable answer. To better adapt to advancements in AI, we initially started with structured conversational flows. However, recognizing the evolving capabilities of AI, we have transitioned to a more dynamic system where users can freely input text. This shift embraces the progress in AI, allowing for a more natural chat-based interaction between users and the platform.
The following requirements have been set for the software:

• To effectively connect with the audience, it is essential to establish a communication channel that allows interaction. Like the web, Slack/Mattermost, or any other suitable medium. In our pursuit of simplicity and broad reach, we have chosen the web as our preferred option to engage a wider audience.
• Content creators require a user-friendly content management system and a conversational crafting backend technology that is both dynamic and easily accessible. Even for those without programming skills. This empowers content creators to effortlessly modify and upload content with a simple click, eliminating the need for intricate compiling, exporting, and deployment processes.
• A tracking solution that provides insightful feedback on how the audience both reaches and interacts with the communication channels.
• A dynamic microservice architecture to integrate third-party systems as plugins, such as CRMs, emails, notifications, external data analytics solutions, etc.

Who did it?

The experts from VisualVest in UX, design, and product management, as well as engineers, DevOps experts, and a product coach from ProductDock, comprised the team.

VisualVest handled usability, user experience, and design. While the ProductDock team translated the derived requirements into frontend and backend functionality, constructing the IT architecture.

What technologies did we use?

Frontend
Considering the marketing channels at hand, we decided that the web is the most promising channel to get the biggest reach. Since marketing actions would include Search Engine Advertising, Google Ads, and landing page teasers, it was clear that we should start with an application that covers desktop and mobile usage.
We have developed a React frontend that introduces users to a friendly customer coach. This customer coach effortlessly guides users through various financial topics by asking clear questions that are easy to answer. The process is straightforward as the content creators have already prepared the answers. Users find enjoyment and effortlessness in interacting with various features, including sliders, multiple-choice options, single selects, and more.

Backend
We choose to use a flow-based programming technology to allow the content (flow) creators to create and maintain flows easily without developer skills. For this purpose, we adopted the well-known, open-source, low-code flow programming platform Node-Red.

To pair the communication channel (React frontend) with the backend (Node-Red), we’ve created a middleware in NestJS paired with the graph database ArangoDB. To handle analytics and tracking features, connection handling, and plugin extensions.

Plugin architecture
We’ve created plugins to extend the core functionalities and integrated them into the core, leveraging the separation of concerns.

React plugins
The React plugin is displayed as a widget on the screen, extending the provided ones within the React App.

See some examples in the following table:

Node-Red plugins

In Node-Red, a node acts as a versatile plugin, adept at handling both internal configurations and frontend data models. It serves as the central hub, efficiently managing the intricate interactions within the plugin ecosystem.. This feature streamlines content creation by allowing creators to effortlessly add nodes to the flow, complete with customizable settings. Consequently, they can effortlessly construct frontend application flows without the need to delve into coding intricacies.

With the plugin architecture, seamlessly adding additional features over time becomes effortless. For instance, we initially introduced a single-select plugin and subsequently expanded it to include a multi-select plugin.

Microservice architecture

Customizable plugins and an all-dots-connecting middleware make up the rest of the architecture, allowing for easy addition.

Docker Containers ship together The React App, Node-RE, Middleware, and ArangoDB.

Containers enabled us to expedite shipping while providing complete transparency into the complex dependencies setup for each system component.

The development environment uses Google Kubernetes Engine to orchestrate the test tenants for the team without disrupting the global test environment.

The development team at VisualVest adopted docker-compose to serve the application on the client side due to the system’s relatively small complexity compared to the development pipeline.

At one moment, we integrated the Node-Red as a sidecar inside the middleware core. Extending the capabilities of the Node-Red itself and allowing the middleware to handle fail recovery, clustering, user and authentication methods, and much more. This move reduced the shipment by one less container and overall complexity.

OpenSource project

In addition to serving as a tool for VisualVest users, another objective emerged from the desires of our VisualVest clients. With a commitment to an open source-first approach that underpinned the creation of our solution, the concept arose to contribute back to the wider community. As a result, a condensed iteration of the conversational flow is now accessible to the public, extending the benefits beyond our immediate user base: https://github.com/conversationplatform

If you’re interested in the history and details of this joined Open Source project, please continue here.

The project was designed using different phases:

The first phase consisted of a 2-3 month period dedicated to establishing the Proof of Technology and Proof of Concept. We built a quick-and-dirty first version of the conversational flow to present the idea to stakeholders and gather first user feedback via user tests. During user tests, VisualVest partners collected valuable insights on enhancing content and prioritizing initial features. This feedback will guide our iterative development process effectively. Also, we showed that Node-Red can be used as a backend for non-developing editors to edit flows and publish them with one click.

After the buy-in from the VisualVest management, we started the second, the hardening phase, together to get the software production ready.

During this time, we refactored the current POC architecture to enable extendability to third-party software. We also built a landing page for the conversational flow for later marketing purposes.

One aspect we overlooked during this period was the strict regulations that financial institutions impose on integrating new elements into their production systems. Therefore, the landing page efforts were only deemed suitable for additional user tests and were not approved to go to production later.

Of course, this mistake cost a bit of time and delayed a desired go-live. Besides that, we started the third phase:

As mentioned, we built on a common core, the Open Source version of the product. 

The Conversational Platform switched into maintenance mode temporarily while the team remained committed to finishing the OpenSource version. We ensured that the system remained operational during this time, even though VisualVest had not scheduled a go-live. They continued user experience testing by incorporating more intricate use cases before making a decision to launch.

The fourth phase started: Feature enrichment. We added a calculation logic and more functionalities that enabled the VisualVest editor team to create. Besides the base use case (the user who wants to learn more about financial topics), several other use cases. Such as a user who:

– wants to know what kind of investor they are;
– is interested in retirement provision;
– is curious about their current level of sustainability.

The software was still not ready to go. Besides bug fixes, fine-tuning was necessary. One primary requirement from the beginning was to learn about user behavior. While this was easy during conducted user tests and feedback sessions, it was impossible in production without an integrated third-party tracking system. It took another month until we made VisualVest’s business analysts happy and able to work with the data.

A year later, we silently launched a version of the software for family and friends, with marketing initiatives to follow soon after.

First, we learned a lot about the many details you can forget, starting with a simple POC and modifying it until it is production-ready.

• Building a Proof of Concept is easy since you don’t pay much attention to edge cases, a broad set of devices and browsers, and there is no need to focus on scalability. 
• You also don’t have to care about GDPR, user consent, or whether the software can be integrated with the existing IT infrastructure. 
• Furthermore, the difficult part of the POC-to-production journey begins with different deployment pipelines that need to be connected. For example, on the ProductDock and OpenSource side, we use GCP and Kubernetes managed by CI/CD DevOps pipelines with GitHub Actions. This setup needed to be married to the clients setting up docker-compose, load balancers settings, content security policies, on-premises resources, and CI/CD DevOps pipelines with Jenkins and GitLab. 
• Of course, you need to check if it is scalable and performant, which usually isn’t since you didn’t care about it during the POC phase. Tip: Having a cloud provider, like GCP, helps a lot. 
• When the hardening and production phase takes too long, you need to be aware that libraries can get deprecated, and you may need to replace them or build the specific functionality from scratch. This has happened to us more than we can count since we started with React 14 and gradually upgraded to React 17. And today, it’s outdated already! 
• As a team, you should always talk directly with responsible persons from other departments as soon as possible. For example, we didn’t know how the Business Analyst (BA) team at VisualVest worked and what they needed to get a data aggregation that their existing tools could process. Luckily, the BA colleagues took the time to explain their requirements and test the results incrementally. 
• Bad Timing: Unfortunately, we stumbled over this issue during vacation time, and the go-live was delayed.

• As POC, we didn’t care too much about security. Initially, the technology stack progressed from one level of complexity to another as various libraries were explored and tested. After the POC phase, the hardening started, and it happened at one of the most controversial times. Global hacking attacks exposed vulnerabilities and, therefore, made these packages unusable for us. Just recall the log4j vulnerability 2021 as an example. Some were updated, some were not, and we ended up with three solutions: upgrade them when available, search for replacements, or implement them from scratch. We ended up using all of these three options.

In the end, one of the most valuable lessons was that, besides starting as a POC, we would connect the development pipeline with some sort of code analyzer such as SonarQube and vulnerability scanner solutions next time. It’s not hard (at all) and takes a few hours at the start of the project. Doing this in advance might save weeks to months since refactoring code from day one is cheaper than the complexity created by non-optimized code in the beginning.

What are we proud of?

1. Learning about low-code: The development part is always fun. First, because the technology stack is not usual, you have more freedom to try different things.

The real surprise was how fun it became to play with these new nodes on Node-Red, how to create a story and translate it into a flow. How easy it became to just drag & drop nodes, configure them, and test the flow on the client. It was at this moment that we realized the power of low code in a real side-by-side comparison. Because, as developers, we did write code to build those nodes, but as content creators, it was so easy!

Playing with Node-Red is fun and easy, and it’s simple to deliver improvements in a flow thanks to this architecture consistently.

1. Collaboration in a product mindset:
   On one hand, for our VisualVest colleagues, it was important to help users invest their money trustfully in a better and more sustainable way – the KuCo as a tool accompanies the investors throughout their journey. VisualVest involved users from the very beginning in the product development process, doing user interviews with the use of the POC. With continuous feedback about the tool and the content flows, it was possible to create a user journey that is understood by users and does not contain flaws that make the journey inconvenient.Furthermore, the VV team defined the hypotheses that could be verified or falsified according to the user behavior. As such, the team was able to react to the learnings from the user behavior and adapt the flows content-wise and software-wise.

ProductDock, on the other hand, could focus entirely on the technology and had the freedom to figure out the best solution to fulfill the desired and continuously tested outcome. 

We realized two like-minded companies collaborating create a harmonious and enjoyable partnership. Team members thrive in the synergy of shared goals and values between collaborating companies.

1. The learning process:
   Discovering new technologies and understanding how they interact makes a developer’s heart beat faster. The sense of accomplishment and of being able to make these tools work towards our goal and figuring out what works and what doesn’t work for our specific use cases has made us very proud, and everybody has grown professionally because of it.

User value

As mentioned before, we considered making the lives of two different target groups easier.

First:  Young urban professionals who want to learn more about investment topics.

The product for sure needs some more time and marketing to be evaluated. After the first month of usage, there seems to be a high interest in information about financial topics. On average, several thousand users clicked through the flows and spent more than 5 minutes. This indicates that people are curious and want to know more. We will monitor those first results over time to continue or pivot our approach if necessary.

Second:  The content creators who want to be able to build and update flows without help from developers.
Since our content creators were part of the development team, they can easily use the tool and create whatever they want. If they really want to build something that is not possible yet, of course, they are still happy to reach out to the developers and ask for support.

To fully appreciate the value it holds for you, I encourage you to follow the link and convince yourself.(note: German content only)

The first link tells you more about financial topics

https://www.visualvest.de/kunden-coach/finanzenstarten

The second link tells you more about sustainable investments

https://www.visualvest.de/kunden-coach/nachhaltigkeit