emember the time how “requirements analysis” was all the rage? Remember how “storyboard” images — helped developers understand what the users wanted? Remember when we raised our hands and went Agile, mostly because we had no idea we had to manage requirements? There is a huge craft because those who use applications cannot communicate with those who create applications and those who create applications — as complaints are often heard — speak another language.
Low Code/No Code to the Rescue
Today’s low-code and no-code platforms have forever changed the way we “see”, validate and meet business needs. Yes, you can say these tools are for “citizen developers”, but they are much more. They allow us to show and tell something that has been difficult to do for decades.
Showing is better than talking, right?
Why not give vendors the ability to showcase a demo what customer’s need? What would they like the app they’re using to do? Why pass this on to product managers who think they know what their customers want?
Years ago, we asked customers to describe the features they would like to see in the apps we created. Our developers assisted in the process. We used graphics programs to facilitate the communication process. But today things are different. We can now show clients exactly what they would see in the application at a high level and then development the application.
Different Platforms Available Today
Spend some time analyzing and selecting low code/no code platforms, then standardize on one that is the same for the customer and for you. There are many platforms. A few of these popular platforms are:
Low Code Platforms
- Appian
- Mendix
- OutSystems
- Quickbase
- Zoho Creator
- Kissflow
- Salesforce Lightning
- Microsoft Power Apps
- Nintex
No Code Platforms
- ClickUp
- Appy Pie
- Airtable
- Kintone
- Quickbase
- Webflow
- AppSheet
Process Improvement
The process is up to the us, not the customer. We should introduce the customer to platform developed app and have the customer go through and understand the requirements and its process. It’s certainly an investment, but it will lead to lots of improvements. Earlier, a separate requirements teams were formed or business analysts were used within companies to identify, describe, and prioritize developer requirements. But now, especially without code platforms, anyone can be a requirements manager. We have seen that some of the best ideas for functional improvements comes from users and analysts.
What else?
So we have tried to decentralize the requirements management process. Then, we introduced the idea of low code discovery / no code usage and how it will help us build faster and better. Third, we identified the range of low code/no code platforms. Then we evaluate its power, its use case, its cost, its scalability: so many due diligence criteria is used to evaluate software platforms. A important criterion is ease of usage. Piloting the approach with a small group of clients is always the best way forward. Feedback here is necessary to determine rider acceptability and strength. Adjustments are still needed before the approach is rolled out to more clients. It is worth it. Future looks interesting with such an opportunity to engage app users in such a diagnostic and documented way.
