How SIDE Labs used the No-Code tool Glideapps to create a simple Google sheet powered app

No-Code tools allow non-developers to quickly and easily create applications using drag and drop features at a low cost. In this post, I’ll talk you through how and why the No-Code tool Glideapps became our chosen platform to create the simple Google sheet powered app needed for our project.

The challenge

In October 2020, Refugee Action was experiencing issues using SharePoint, the database they were using to store the contact details of organisations providing services to asylum seekers and refugees. The database was mostly used during the signposting process where their volunteers referred their clients to the appropriate service provider. They asked for SIDE Labs’ help to create a simpler database for their volunteers to use. The project took a total of three weeks, spread across a few months.

Our process had two stages 

  1. Research the problem

Speaking to our client and their volunteers to understand the problem they were facing and the organisation’s needs

  1. Build the solution

Defining the core requirements and possible solutions, then building the solution out with a tool that fits

Research the problem

We started the discovery process with a stakeholder interview, talking to our client about their needs and expectations to understand the situation, process and problems they faced. From the interview we learned that the information their staff needs to signpost clients was organised in folders in two ways:

  1. The type of service the organisation provides e.g ESOL (English for Speakers of Other Languages) courses
  2. The area the organisation is located in

​When we asked them what the ideal new process looked like they said. "What I think we need is a directory view that allows you to go down three layers: city (e.g. Manchester), then borough (e.g. Bury) and then service (e.g. ESOL class providers) - so you would end up with, for example, ESOL class providers in Bury.”

Refugee Action’s biggest concern was having incorrect information about the organisations, and that in turn being used by the volunteers to advise their clients. For example, sending clients to an organisation or service that no longer exists or operates at a different time or day to that which is stated.

Since the database is managed by our client (Refugee Action), we needed to ensure that any solution we developed and implemented was easy to maintain and update in a way that minimises the chances of input errors.

We also spoke to four volunteers who signpost clients - the people who will be using the app - to get answers to the following questions:

  1. What is their current process for signposting asylum seekers?
  2. How do they decide whether an organisation is the right fit for their client?
  3. Where do they get the contact details of the organisations from?
  4. What issues and pain points do they face in their process?

What we found out

From the interviews, we were able to map out all the steps the volunteers take -from a client approaching them, to successfully referring the client to an organisation that can help them. We used this information to create a small diagram laying out their actions and the pain points faced at each step. This enabled us to narrow down the functionality of the app to the part of their process causing the most pain points. 

untitled image
A diagram showing the steps taken by the volunteers in their signposting process

The key issues 

The details of all the organisations providing services for asylum seekers were stored on a SharePoint database that became unusable for the volunteers. It contained hundreds of folders and numerous out of date bits of information. The problems ranged from duplicated files to people re-uploading the same organisation again when their phone number or address changed. It was just easier to add the latest information separately because if the organisation’s information was held on a PDF file it would be time-consuming to amend.

The database was maintained by several different people at any one time, which meant that whenever someone new helped out, the set-up of the data stored would be changed. At the time the information was organised in two different ways - service and location - making it difficult to know where the organisation needed was stored.

Methods used instead of the database - and the impact this had

Method 1. Advising based on memory 

The volunteers had a few go-to organisations they would send their clients to based on the issue stated. This meant that other organisations went underutilised and there was a general lack of awareness of any additional services those organisations could have provided.

Method 2. Asking a colleague for advice

If volunteers couldn’t think of an organisation, they would ask one of their colleagues for advice via email, which could sometimes take days. This had the same implications as the first option with their colleagues also advising based on memory.

Once those two options were exhausted they would turn to the SharePoint database as a last resort.

Build the solution

Based on the findings from the research we were able to establish a few points to take forward.

  1. We need one central source of information 
  2. It needs to be easy to update and maintain by multiple people
  3. It must have a simple search function, via which people can search based on three levels: city, borough and service provided.

This gave us a good idea of the features we needed and the type of data we would need to house. This made finding the right tool that much easier especially with websites like makerpad, a tool search platform to find something that fits the bill. 

There were also a few additional things to consider when looking for a tool:
  1. Do multiple people need to be able to access it?
  2. How high can the learning curve be? (dependent on the digital maturity of the people who will be maintaining it)
  3. Will any sensitive data be stored on it?

To create our database we chose to use Glideapps, which would allow us to utilise a Google sheet as a back end. We felt this would satisfy the need for a simple, easy to maintain database, since all the volunteers were familiar with - and capable of using - Google sheets. In addition, once it was set up and running, there was no need for anyone to log into Glideapps. Each time a change was made on the Google sheet, the data on the app would update. Therefore, the learning curve was zero for anyone with experience using Google sheets, which is exactly what we needed for a tool that would be maintained by several volunteers.

We also needed a tool that would give us the flexibility to easily and quickly build and test out a few different solutions with our users. So we could answer questions like “should it be a map or a list?” helping us find a set-up that fits the way the volunteers really worked. 

untitled image
The first iteration of the app and feedback received

After several iterations and tests, we had a setback due to the need for multi-filters (city, borough and service), something the tool didn’t seem to be able to handle. However, like most No-Code tools, Glideapps has a very active and supportive community willing to help solve the dilemma. By following a quick hack video posted by one of the members, we were able to create our own custom filter. 

untitled image
A before and after of the app detailing a trick to add a custom feature to the app

Results

We introduced the app to a team of 20 volunteers in Greater Manchester and Merseyside - and the feedback so far has been very positive. Particular credit has been given to the ease of keeping the information up to date and the increased awareness of the number of services and organisations available. The app will continue to grow until all the organisations providing asylum services in the UK are on it.

map app final.jpg
Showing the final solution for the app

There are a number of tools that can be used for endless reasons; here are just a few possible use cases

No matter what tool you end up using, the process to getting there is the same: research first. The great thing about No-Code tools is that they give you the ability to quickly test if the solution you come up with is worth investing in. Just keep these questions in mind during your next No-code project.

  1. What is the problem you are trying to solve?
  2. What does the ideal solution look like? 
  3. What are the must-have features and which ones are nice to have?
  4. Which No-Code tool fits the bill and will allow you to test your solution quickly and easily?


Check out SIDE Labs to see more No-Code powered projects

Our Catalyst network - what we do

Support & services

Our free services help you make the right decisions and put you in touch with the right agencies to make digital happen.

Resources

FREE resources to help you take control of your digital challenge.