It has now become apparent that, while the vast majority of no-coders are indeed trained in the use of the tool, they are not necessarily trained in the appropriate methods, nor in the specific computer culture: algorithmic logic, databases and data processing, API, versioning, and the associated documentation. There are a certain number of good practices within the developer world, that must be transposed to the no-code world. However, “we cannot lie”... documentation is not the most exciting part of a project, and its editing is often put off to the last possible minute...
Documentation is, however, a key factor in success and sustainability: we identified its importance while interviewing start-ups .
Nowadays, the main, and most common reasons behind the selection of a no-code solution are:
In either case, if the no-code solution is used to prototype an application and test its feasibility and efficiency, the main concern will be that this can be done quickly. With a bootstrap operating method; with a small number of players interacting with one another, documentation is naturally not a priority.
The Bus Factor represents the number of people who would have to be “hit by a bus” before your organisation would be in danger. This is a factor that demonstrates the significance of the risk associated with the non-sharing of information and competences within a team.
In spite of the importance of sharing information so as to be able to deal with the infamous Bus Factor, the need to document one’s no-code environment arises whenever several people are brought together in collaboration.
We can see that without MVD (Minimum Viable Documentation), working in teams of several people can prove chaotic: incompatible changes, accidental deployment to production... The lack of documentation can become extremely counter-productive. If you encounter this type of situation, it’s high time that you address this issue.
Documentation must be considered a standard practice and not a box-ticking exercise. It must be thought of as a genuine productivity tool.
The tools that are currently and most commonly preferred when it comes to hosting and collaborating on documentation are notion.so or coda.io. These tools allow you to store or integrate (embed) information that is highly diverse in terms of its nature or source (diagrams, tables, wireframes...). Comment: Generally speaking, it still remains more practical to work directly within source tools (e.g. Miro, Figma...), the objective of inserting them into the documentation is the sharing and centralization of information.
Some of these components may appear trivial, however, having this information available in a centralised manner represents a genuine timesaving for the entire team – therefore, they must not be neglected. It is not necessary to have ALL of the elements listed below, the key terms here being good sense and pragmatism: you must document what is useful and adds value. This will depend a great deal on your context and will without doubt evolve over time, as your platform becomes more complex, your team increases in size, and your number of interfaces multiplies...
How to create a user flow diagram
Entity-organisation symbols and diagram notation
This list is not exhaustive. It will have to be adapted to your own situation.
The next challenge will be to successfully and regularly update this documentation, not out of a desire to tick boxes, but because it is genuinely useful: documentation must serve as a tool. This requires rigour and discipline.
Nonetheless, the feedback that we have received indicates that, for growing structures, you ultimately waste less time if you document on a regular basis rather than constantly having to search for information when this documentation is not in place.
The creation of a documentation system is a prerequisite to working effectively as a team. A necessary, albeit insufficient requirement, no-code stacks can be highly fragmented, the tools used are not always adapted to group work, and therefore it is essential that you are sufficiently well organised.
Context: a collective of digital process optimisation freelancers, working, in particular, with no-code tools used for documentation: Notion
Good practices:
Example of a scenario using these good practices:
Example of one of their documentation pages in Notion:
Context: Edtech uses as much code to develop its various products as it uses no-code – use of the following tools: Stacker, Airtable, Zapier, Make, Notion. Tools used for documentation: GitHub with document versioning in markdown format.
The Git repository:
Tree: Tool name > Functionality > readme.md
Content of the readme.md file:
The objective is to have all of the elements that are present in the no-code scenario parameters – this is a lengthy manual task, however, is essential for the proper maintenance of the environment. 20-30% of development time is dedicated to documentation.
Example for a scenario:
In addition to scenarios, other elements are also stored in this knowledge base, such as formulae or scripts, so that they can be referenced in the same place.
Formula for an Airtable column
💡 The benefit of having everything in text format is the ability to perform a full-text search, which allows you to see the field name dependencies between Airtable and Make, between an Airtable script and an Airtable column, with a view to modifying throughout prior to release.
Here you can see the presence of a firstname field in an Airtable script – you must therefore update the script if the column name is modified.
