In the first of a new editorial series, we tackle common misconceptions around using no-code tools. First up: the idea that you actually need to have some level of technical knowhow to really make use of the no-code tools out there.

‍

TL;DR: You don’t have to know how to write or read code to use no-code tools, but you do need to understand the basics of how computers work – and design a system for whoever uses your app.

‍

So…what do you need to know?

First things first, let's just clarify the level of tool you’re using. Zero-code tools (eg, Squarespace or Shopify) don’t require any knowledge of coding or how computers operate; at the other end of the scale, low-code tools do require coding knowledge and are mainly for developers. No-code tools don’t require you to write code, but they do require some basic software understanding.

‍

Meaning what, exactly?

Basically, you need to get logical. By that, we mean understanding the underlying rationale behind whatever software app you create. How the system you create should work.

So when a user clicks on a login button, what happens next? Where does that info go? How are you telling a computer what you want to happen? Every time something happens on a piece of software you essentially have to make these decisions. You ultimately need to get in the mindset of thinking like a computer (aka, computational thinking). Where you start to see and understand how systems actually work, and how different elements relate to each other. 

Think of yourself as an architect, designing a maze for your user to get around. It’s up to you how that user goes through it. You're designing a flow-chart for all the potential routes someone can take. That means you have to think systematically, and you also have to think about what can go wrong too.

Are there any concepts that are important?  

As it happens, there are. Plenty of no-code tools will take care of these concepts for you, but it’s definitely helpful to understand the basics: 

• How your data is structured. You need to have an understanding of how different data groups relate to each other in a database structure. So take Uber as an example. To set up databases to show Uber’s data, you could decide to create a separate database for cars, drivers and users. Or you might instead decide to have a ‘people’ database with drivers and riders together. It’s your call, but it helps to get things down and really think about it. Some no-code tools teach this really well, but sometimes you need to teach yourself.

• IF Statements. This is a pretty crucial term when it comes to building apps. It means that if a specific condition is true, this action happens, and if that condition is false, a different action happens. So in the real world it could be: If the weather is sunny, then pack sunscreen. If it’s not, pack an umbrella.    

• Instances. One important element to think about is the idea of instances – in the sense that multiple people are going to be using your app at once. That means you have to make decisions based on whether an action (like clicking a button) only does that action for that specific user. Likewise, when you’re saving data you need to decide whether you’re saving it for that user, or for every user.

• Edge cases. This basically means a problem or situation that only happens in extreme situations or at the highest/lowest end of possibilities. So for example, if you think about a login screen, an edge case might be a user inputting the wrong password. What happens then? Does the screen refresh? Are they taken to a different page? 

Think of yourself as an architect, designing a maze for your user to get around. It’s up to you how that user goes through it.

‍

Where do people get stuck?

As philosopher Ted Nelson once said: ‘The good thing about computers is that they do what you tell them to do. The bad thing about computers is that they do what you tell them to do.’

The tricky part is, in a sense, trying to figure out all the things that you didn’t figure out. Take the login screen example. You might think that’s pretty straightforward – all you need is a box that lets someone enter an email, a box that lets someone enter a password and you’re done. 

• But what about a ‘signup’ box? 
• What are your users allowed to enter? Are there restrictions on email addresses, or username length?
• And what happens if they forget their password? Do you send them an email or an SMS? What email address or phone number should that come from?

Suddenly something simple like a login has become quite complicated, with lots of different logical decisions to make. For most of the software you use, someone has thought about that stuff. But with some no-code tools, nobody is going to pop up and say, “Wait, you’ve forgotten to put a forgotten password screen there!” You have to think about it and that’s where challenges can come up. 

Do no-code tools help? 

They do, and you don’t need to think about the logic and decision-making for everything. Indeed things that are really commoditised and common, like login screens, sending emails when someone signs up, and two-factor security authentication, are actually already taken care of by the majority of no-code tools that are out there.  

Some help you figure out these decisions more than others. Generally, the more a no-code tool prescribes what happens when an action happens, the less power you have in building your app. The more they don’t prescribe what happens next, the more power you have. That’s great for your design freedom, but also naturally leaves more margin for problems and issues too.

‍

What’s the takeaway? 

Just to reiterate: you don’t need to know how to write or read code to make some incredibly useful apps using no-code tools. But if you want to increase your chances of being successful, it’s definitely worth understanding the basics of how computers work, and then embracing the mindset of an architect. The app you'll be building is something that users have to navigate – and you're responsible for making that happen in a seamless, logical way.

‍