There’s a suggestion in the idea exchange for better Make docs, but there is very little specific and actionable recommendations in the request.
Let’s use this thread to make specific and constructive documentation suggestions. User interface docs are welcome here too!
Rationale
Many look for a tool like Make when they want to save time and money when performing repetitive software and data tasks. In many organizations and businesses, business processes and workflows usually take place with Microsoft Office or Google docs strewn about the office, archived in a shared folder. Or worse, these processes are just passed down by “oral” tradition in companies. Today, there are software services and apps like Make that enable the design and configuration of automated data workflows. This is a huge win for automating more repeatable business processes and for getting things done quickly, accurately and efficiently! This is the true value proposition of no/low-code tools: concretizing workflows.
But In order to wield the power of Make, business process automators will need to make sure they improve their logical skills and data capabilities before fully mastering automation. Users with any programming or data management experience will have a clear advantage when using Make. These are the first users that will convert to paid customers and continue to lever Make for a long time and tell others about it. But to really change the business automation world, non-technical users will also need to level up their data and logic skills.
Make is categorized as a “no-code” platform, and while there may be very little code when using Make, a logical, data-driven mindset is an absolute must. Building and testing scenarios in a “start small” and iterative approach must also be documented and described. Integromat documentation should encourage and never downplay “willing-to-experiment” thinking.
I propose these 3 principles for Make documentation:
- No assumption of any prior knowledge of programming, logic design or data structure knowledge
- Liberal use of rich media (text, hyperlinks, images, video and audio where appropriate) and documentation structure including deep hyperlinking between documents
- Clear scenario examples that are downloadable
The style of the documentation must use plain-language whenever possible. The use of plain language ensures the reader understands the documentation as quickly and completely as possible. Plain language strives to be easy to read, understand, and use.
Do NOT ever ever do this in documentation
This is very, very lazy and unhelpful:
Inspiration
Style Guides
Reference documentation systems for inspiration:
This Parabola foundation doc must be created and maintained for Make. They set the context for effective usage of Make.
Another great piece of documentation:
These beginner, intermediate, advanced workflow tutorials are excellent.
Platform overview
Reference docs needing updates:
https://www.integromat.com/en/blog/zapier-vs-integromat/
make though in the near future.
