Many end users in the FinTech space are people with little to no coding experience. No-code/low-code solutions help them benefit from the power of innovative APIs like Investec’s Programmable Banking. Here are some principles we discovered when we tried to make the power of Programmable Banking accessible to a non-tech audience.
We created a check-list of the principles for you so it's easier to plan your own project!
With Investec’s launch of Programmable Banking, developers are now able to build FinTech products for individuals and businesses. However, this power of innovation and control over your personal banking is not yet accessible to people without coding skills.
We wanted to figure out how we might allow non-developers to benefit from the power of the Programmable Banking API. That’s where no-code/low-code solutions came in.
In this article we provide you with some principles that are helpful to consider when thinking about how to build a no-code/low-code solution for a non-tech audience.
What no-code/low-code solutions are about
As the name suggests, no-code/low-code solutions typically require little to no coding and often use a simple frontend as well as easy to use instructions for any “devvie” components that the user has to navigate. This allows more non-developers to use technologically complex products and services. What could be more awesome than empowering your parents to use technology they would never normally have access to?
A great example of a low-code/no-code platform is IFTTT.com. IFTTT allows users to integrate their much-loved apps with each other and define how they should work together in order to best suit their needs. This is all done without having to know how to code.
A no-code/low-code solution like IFTTT has endless applications for non-developers, even within the banking space. Imagine that you have just bought a new pair of running shoes which cost you way more than expected. You want to be more prepared the next time you head back to the shoe store. Using IFTTT, you could connect your Monzo bank account and your Strava app and tell Monzo to transfer money into your savings account every time you complete a run on Strava. After each run, the money transfer is automatically processed, helping you save enough for your next pair of running shoes when you need them.
Check out some of the many interesting examples of how IFTTT can be used within the banking space, enabling non-devs to optimise and automate their finances.
Bringing banking to Google Sheets
For the past two years, OfferZen’s been helping Investec build a programmable bank account for developers that allows developers to code their own banking experience using open application programming interfaces (APIs) and programmable bank cards. In most cases, however, finance managers themselves are not versed in traditional programming languages and therefore don’t have access to the wealth of features available to developers.
During a build day, we delved deeper into building out a low-code/no-code solution, aimed at finance managers, using Programmable Banking. The ideal outcome of the day was to give finance managers access to Programmable Banking features by creating a low-code/no-code solution using a language that was familiar to them: Google Sheets/ Excel.
Two members of the Programmable Banking OfferZen community, Pieter Heyns and Loftie Ellis, were invited to join the build day. Over the course of the build day we built out a proof of concept for “Spreadsheet banking”.
Useful principles for low-code/no-code solutions
Thanks to this experience, we realised a couple of useful principles for low-code/no-code solutions that might help you with your next build.
Ensure you have access to the end-user
Insights from your end-user are important when building a low-code/no-code solution because they can help you understand what level of simplicity your solution should be aiming for. We had Pieter Heyns, the former Head of Finance at Luno. He has a deep understanding of what finance managers would be able to navigate and what might be too complex.
Pick digital tools that your end-user is familiar with
To improve adoption to the solution, pick a digital tool that your end-users are comfortable using. Low-code/no-code solutions won’t be as effective if your end-user isn’t familiar with the tool or it isn’t easy to use. Google Sheets was an easy choice for us because most business finances run on Google Sheets or Excel and finance managers are very familiar with their functions.
Understand how the end-user is currenting approaching/solving their pain points
It is important to identify your end-user’s pain points, and even more helpful to understand how they are currently addressing these. If you can identify a process that takes a lot of time, you can confirm that this really is a problem worth solving.
Thanks to Pieter, we identified that financial managers were wasting a lot of time manually dealing with transaction data because:
- They couldn’t easily download it into Google Sheets or other software.
- It wasn’t in a format that can be manipulated easily.
- It quickly became outdated.
In addition, finance managers spend many hours moving money between the business’ current and savings account to ensure that they are optimising on earned interest.
With two specific problems to solve, the team got to work to create a Google Sheets interface that a finance manager could use to:
- View real-time transaction history data for their accounts
- Specify specific treasury rules to automatically optimise interest for the business.
Make the solution as accessible and clear as possible
In order to ensure that a non-tech user will be able to navigate your low-code/no-code solution, put in the effort to make it as accessible as possible In designing our Google Sheet, we ensured that we had the following:
- A READ ME set of instructions that gave the user a clear checklist/sequence to move through when using the spreadsheet.
- Clear column headers, buttons and checkboxes that hide Javascript code.
- Graphs to visualise data tables, so that the user could clearly see the minimum, maximum and current balance of each linked account.
Test early with a non-technical end-user
Test your low-code/no-code solution as soon as possible to know if you're on the right track. At the build day, we had a couple of users without development backgrounds, who continually tested the usability. Testing early gave us the confidence to show this to finance managers to see if it would resonate with them.
You can view the live demo of spreadsheet banking here.
