Rapid Prototyping: cos’è e come farlo con strumenti NoCode

Scritto da

Radhe Telange -

Marcello Rossi -

Rapid Prototyping: cos’è e come farlo con strumenti NoCode?

Nella mia esperienza, quando si parla di prototipazione per strumenti digitali, le opzioni suggerite da utilizzare sono le seguenti:

  • Paper prototypes (disegni su post-it o in generale su carta);
  • Wireframe;
  • Presentazioni (Power Point etc.);
  • Interfacce grafiche (Figma e simili);
  • Interfacce cliccabili (Sempre Figma etc.. ma con interazioni impostate);
  • Prototipi interattivi scritti da sviluppatori.

Solo raramente vengono citati i prototipi con strumenti NoCode, che oggi propongo come via di mezzo tra le interfacce cliccabili e i prototipi interattivi.

Quindi, in questo articolo descriverò in maniera quanto più pratica possibile come e quando sia possibile utilizzare strumenti NoCode per fare Rapid Prototyping in un contesto di prodotto digitale.

Rapid Prototyping: cos’è e come farlo con strumenti NoCode

Il motivo per cui penso importante parlarne è un’idea che rubo a Tom Chi, che mi ha ispirato molto: “Vorrei evidenziare come la cultura di sviluppo è cresciuta nel tempo per incentivare principalmente l’ottimizzazione, non l’elasticità di modifica”.

Parafrasando dal video nel link:

“Un sistema ottimizzato è un sistema che impiega il minor numero possibile di step per raggiungere un obiettivo, questo in un sistema informatico vuol dire che per fargli fare qualcosa di diverso bisogna prima distruggere parte del sistema attuale e ricostruirlo, seguendo un processo molto lento”

La flessibilità alla modifica nei prototipi è vitale per permetterci di velocizzare il feedback loop, e quindi imparare e migliorare più rapidamente.

In questo caso il sistema da ottimizzare non è quello informatico, ma quello di apprendimento.

Qui sotto, trovate una lista esempi pratici di utilizzo dei prototipi NoCode:

  • Per testare l’interesse del pubblico verso un’idea;
  • Per condividere e rifinire un concetto con colleghi in un ambiente facilmente modificabile;
  • Per testare volumi di traffico e le fonti di dati necessarie;
  • Per testare dei nuovi processi aziendali aggirandone la burocrazia;
  • Per affrontare un incontro con gli stakeholder con maggiore sicurezza.

Infine, prima di iniziare vorrei chiarire un paio di punti:

  1. I prototipi NoCode sono ideali quando non esiste ancora un prodotto solido con una sua architettura: in quel caso diventa difficile attenersi a quella struttura usando il NoCode, e generalmente conviene affidarsi al team di sviluppo;
  2. Il punto di forza principale degli strumenti NoCode è la capacità di sviluppare prototipi interattivi senza l’onere economico di formare un nuovo team di sviluppo.

Le tipologie di prototipo

Esistono diverse tipologie di prototipo in base alla loro complessità. In generale, questa analisi prenderà molti concetti da Lean UX di Jeff Gothelf e Josh Seiden.

Qui di seguito ho voluto inserirli tutti in uno spettro i cui estremi sono Prototipi a bassa fedeltà e ad alta fedeltà.

Come si può vedere dall’immagine, divido poi lo spettro in due macrocategorie: i prototipi non interattivi e quelli interattivi.

Il prototipo più semplice, all’estrema sinistra dello spettro, è Paper prototype. Si tratta solitamente un disegno su carta o su post-it, più o meno raffinato, che viene presentato ad uno stakeholder per mostrare le funzionalità descrivendole a voce o in forma di testo intorno al disegno.

Nella categoria dei prototipi non interattivi rientrano anche wireframe, presentazioni e interfacce grafiche creati con vari strumenti come Figma, Sketch, PowerPoint, Miro, e altri. Questi servono a mostrare in maniera statica l’aspetto e la struttura di un’app o di un sito web senza permettere interazioni reali.

La distinzione diventa evidente quando i prototipi iniziano a includere elementi interattivi, consentendo all’utente di partecipare attivamente al prototipo, non solo come spettatore.

Queste interazioni possono essere preimpostate, come in un documento Figma, o più complesse, con la possibilità di interagire con un database che l’utente può consultare e potenzialmente aggiornare.

Una mia tesi: personalmente, ho notato che la qualità delle discussioni con colleghi o stakeholder migliora in maniera direttamente proporzionale alla complessità del prototipo. In altre parole, più il prototipo è avanzato, più le considerazioni emerse durante le discussioni risultano essere affidabili. Se doveste essere d’accordo, mi farebbe particolarmente piacere poterne discuterne.

Per dare concretezza al tutto, qui sotto vi propongo un mini-esperimento di sviluppo di un piccolo programma per prendere appunti.

L’esempio prende volontariamente un applicativo molto influenzato dagli input dell’utente, perché’ per sviluppare pagine non interattive ormai esistono strumenti molto semplici e noti come Wix e simili che non tratterò in questo articolo.

Valutiamo il Tempo di apprendimento come il triplo della durata media di un videocorso sull’argomento, assumendo che guardare un video non sia sufficiente per poter mettere in pratica.

Per il Tempo di creazione, abbiamo stimato quanto ci è voluto a noi e ai nostri conoscenti per completare il compito.

EsempioStrumento usatoTempo di apprendimentoTempo di creazione
DisegnoDisegno010min
FigmaFigma4h30min
Figma InterattivoFigma9h4h
NoCodeWebflow6h2h
Sviluppo classicoHTML/CSS/JavaScript72h48h

Sono cosciente del fatto che i tempi variano molto in base alle circostanze, per questo faccio una proposta: Se volete, potete aiutarmi ad ampliare l’esperimento inserendo i tuoi progetti a questo link.

Se invece fossi interessato a vedere casistiche di altri, ho creato questa tabella in costante aggiornamento.

Oltre a tutte queste tipologie di prototipo, abbiamo infine il Rapid Prototyping, una strategia che permette di creare velocemente prototipi per valutare il mercato e le aspettative degli utenti.


Cos’è il Rapid Prototyping

Parafrasando, dal libro Evolutionary Systems Development di John Crinnion:

Il Rapid Prototyping è un approccio veloce alla creazione di prototipi che inizia con un’indagine rapida seguita dalla realizzazione di un modello funzionante di parti specifiche del sistema, spesso rappresentato come un “Vertical Slice”. Il metodo utilizzato per costruire il prototipo è di solito informale, il fattore più importante è la velocità con cui il sistema viene costruito.

Il prototipo diventa quindi il punto di partenza da cui possiamo riesaminare le aspettative degli utenti chiarire i requisiti del sistema. Il fine ultimo è quello di sostituire il prototipo con una versione finalizzata del sistema, sviluppata in base ai requisiti definiti durante la fase di prototipazione.


Cos’è il Nocode

Io considero come NoCode tutti quegli strumenti che sostituiscono un lavoro solitamente svolto tramite linguaggio di programmazione o architettura informatica.

Ad esempio: la costruzione di un Sito web o un DataBase, ma non strumenti di Wireframing e progettazione come ad esempio Figma.

La definizione di NoCode può variare in base alle fonti. Sul web questa distinzione non è sempre così netta, ma la caratteristica comune è che questi strumenti consentono a chi non sa o vuole scrivere codice di sviluppare velocemente prodotti che seguendo determinati standard.

Questa accessibilità amplia le possibilità di chi lavora in ambito digitale, permettendo una realizzazione veloce e flessibile di progetti senza la necessità di scrivere codice.


Un excursus degli strumenti NoCode

Quindi, cosa ci permettono di fare gli strumenti NoCode attualmente sul mercato?

Principalmente:

  1. Costruire e pubblicare Siti Web
  2. Costruire a pubblicare App
  3. Costruire e pubblicare Web App
  4. Costruire Operations Software (strumenti ad uso interno aziendale)
  5. Automatizzare processi tra strumenti diversi
  6. Extra: Svolgere attività molto specifiche ma standardizzabili.

Per aiutare a navigare tra le opzioni, ho cercato di mappare gli strumenti NoCode attualmente sul mercato che ritengo più validi valutandoli secondo due criteri:

  • La conoscenza informatica necessaria, da Lowcode a Nocode
  • Il tipo di risultato atteso, da Strumento tecnico a Sito web

Spero che questo schema possa essere utile per visualizzare rapidamente quale strumento sia più adatto alle esigenze di un progetto, tenendo conto sia delle capacità tecniche dell’utilizzatore/i sia dell’obiettivo finale desiderato.

Qui sotto ho inserito una breve descrizione di ognuno con un valore che identifica difficoltà di apprendimento ad utilizzare ogni strumento da 1 (semplice) a 5 (complesso).

  1. Carrd: Piattaforma semplice per creare siti web one-page, ideale per landing pages, portfoli e profili personali. Velocità e facilità d’uso sono i suoi punti di forza. Learning Curve: 1.
  2. Framer: Strumento di prototipazione e design interattivo, offre animazioni avanzate e collaborazione in tempo reale, perfetto per mockup dinamici. Learning Curve: 3.
  3. Webflow: Combina design visivo e sviluppo web, permettendo la creazione di siti web responsive con controllo granulare su animazioni e interazioni. Learning Curve: 4.
  4. Super: Trasforma documenti Notion in siti web, semplice da usare con un focus su velocità e minimalismo, ideale per progetti rapidi e agili. Learning Curve: 2.
  5. Softr: Per costruire web app e siti web dinamici senza codice, usando dati da Airtable. Facilità d’uso e integrazione con database. Learning Curve: 2.
  6. Bubble: Potente piattaforma per costruire applicazioni web scalabili, con un editor visivo completo e la possibilità di creare funzionalità complesse. Learning Curve: 5.
  7. Drotcode: Soluzione semplice per creare siti web e landing pages con drag-and-drop, enfasi sulla velocità di costruzione. Learning Curve: 1.
  8. Stacker: Trasforma fogli di calcolo e database in app personalizzate, focus su personalizzazione e integrazione dati. Learning Curve: 3.
  9. Airtable: Mix tra database e foglio di calcolo, ideale per organizzare dati e automatizzare flussi di lavoro, con forte capacità di integrazione. Learning Curve: 2.
  10. Google Appsheet: Crea app mobile e web da Google Sheets, accessibilità e integrazione con l’ecosistema Google. Learning Curve: 2.
  11. Retool: Strumenti per costruire applicazioni interne, connessione con database e API, componenti personalizzabili. Learning Curve: 4.
  12. Ragic: Database online configurabile come foglio di calcolo, personalizza applicazioni database senza codice. Learning Curve: 3.
  13. Make (ex integromat): Automatizza flussi di lavoro tra app e servizi online, approccio visuale e intuitivo, ideale per integrazioni complesse. Learning Curve: 2.
  14. Zapier: Connette app e servizi automatizzando flussi di lavoro, semplice da usare, ampia libreria di integrazioni. Learning Curve: 3.
  15. Excel e Google Sheets: Tutti sappiamo che si tratta di piattaforme di fogli di calcolo potenti e versatili, ideali per l’analisi dei dati e la modellazione finanziaria; pochi però ne conoscono le funzioni di automazione e le integrazioni con i vari strumenti Microsoft e Google. Learning Curve: 2.
  16. Power Platform: Piattaforma di Microsoft che include Power BI, Power Apps, Power Automate e Power Virtual Agents. Permette di analizzare dati, costruire soluzioni, automatizzare processi e creare chatbot virtuali. Learning Curve: 5.
  17. Tableau (e altri strumenti di BI): Fornisce strumenti interattivi di visualizzazione dei dati per business intelligence tramite interfacce Drag and Drop. Learning Curve: 3.
  18. Appian: Piattaforma per lo sviluppo di applicazioni software di business process management (BPM) e low-code. Permette di creare, eseguire, gestire e ottimizzare i flussi di lavoro e le operazioni aziendali. Learning Curve: 5.
  19. FlutterFlow: Offre un’interfaccia drag-and-drop per costruire applicazioni mobile. Integra funzionalità come database backend, autenticazione e API. Supporta l’esportazione diretta del codice sorgente Flutter. Learning Curve: 4.

Sviluppo in NoCode: i vantaggi

Uno dei vantaggi principali che ho trovato nello sviluppo in NoCode è la facilità di apprendimento.

Questo per me è stato il fattore determinante nel decidere di utilizzare questi strumenti per sviluppare e credo sia il fattore principale per permettere a chiunque di sviluppare sistemi complessi in maniera semplice.

La complessità di scrivere codice ed interagire con le macchine non è scomparsa, sia chiaro, ma viene nascosta dietro ad un’interfaccia utente intuitiva e di automatizzazioni che rendono l’utilizzo meno frustrante della scrittura di codice normale per utenti inesperti.

L’elasticità e la velocità di utilizzo inoltre ci permettono di evitare quelli che, sempre Tom Chi, definisce molto adeguatamente come i “guess-a-thon meetings”, riunioni in cui ognuno parla delle proprie opinioni, senza avere dati su cui basare le proprie decisioni.

La rapidità di costruzione di un prototipo influenza direttamente la nostra capacità di validare una o più idee sul mercato, e spesso il costo di uno sviluppatore NoCode non è paragonabile a quello di uno sviluppatore FullStack tradizionale.

Personalmente, ho notato anche che l’utilizzo di strumenti NoCode ha anche un interessante effetto secondario sull’educazione. Più volte ho notato un apprendimento più rapido di alcuni concetti di informatica tramite l’utilizzo di alcuni strumenti NoCode.

Inoltre, ho notato sia su di me che su altri come l’utilizzo di questi strumenti abbia facilitato a superare la “paura di sbagliare”, una paura molto comune di fronte alle incognite di chi si approccia ad imparare un nuovo argomento e a mio parere uno dei principali ostacoli all’apprendimento.


Sfide nell’Utilizzo degli Strumenti NoCode

Le sfide nell’utilizzo degli strumenti NoCode sono significative e variano a seconda delle esigenze specifiche di un progetto.

La natura del NoCode, sebbene faciliti l’accesso alla tecnologia e allo sviluppo, porta con sé dei compromessi, in particolare in termini di performance e innovatività.

La perdita di performance (di solito velocità di computazione, la quantità e l’effettiva perdita di performance sono attualmente causa di dibattito), si manifesta anche negli strumenti NoCode a causa dell’astrazione elevata. Questo non sorprende, dato che l’astrazione mira a semplificare lo sviluppo a scapito, in alcuni casi, della velocità di computazione.

Tuttavia, questo vale solo quando parliamo della performance della macchina, ma la tecnologia ha raggiunto un livello tale per cui la performance critica a cui fare più attenzione è quella dello sviluppatore, non necessariamente quella del codice.

Il NoCode eccelle nell’esplorazione di applicazioni per sistemi consolidati ma trova limiti nell’innovazione tecnologica. Quando si deviano dalle configurazioni standard, emergono complessità come:

Il NoCode si presta bene all’esplorazione di nuovi usi per sistemi consolidati, ma è limitato per quanto riguarda la pura innovazione tecnologica.

Quando proviamo ad uscire troppo dagli schemi tradizionali emergono complessità nel gestire:

  • L’adattamento a Design System specifici o regole consolidate,
  • La gestione di interazioni complesse, come quelle con le mappe,
  • L’integrazione con sistemi legacy e obsoleti,
  • Lo sviluppo con design unici o molto artistici,
  • La creazione di simulazioni fisiche o 3D,
  • Le interazioni di tipo videoludico.
https://felt.com/

La migrazione da un sistema NoCode a un altro

Un’altra complessità è quella di migrazione da un sistema NoCode ad un altro sistema.

Così come la gestione del costo nel lungo termine. Spesso, la decisione di utilizzare strumenti NoCode dipende dalla valutazione se il prodotto digitale sia un centro di costo o di profitto.

Sebbene spesso si possa arrivare fino alla pubblicazione ufficiale di prodotti sviluppati interamente in NoCode, nel lungo periodo questo può risultare costoso (anche se lascio a voi l’onere di calcolare quanto, invece, verrebbe a costare un team di sviluppo o un contratto con una software house). In questi casi, una valutazione fondamentale è se il prodotto digitale sia un centro di costo o uno di profitto.

La crescente complessità e le necessità di personalizzazione specifiche possono richiedere l’introduzione di codice personalizzato, mostrando i limiti degli strumenti NoCode quando si tratta di esigenze molto particolari o avanzate.

Un altro motivo comune di abbandono è l’aumento della complessità e la necessità di personalizzazioni specifiche. Personalmente ho dovuto ricorrere più volte a workaround utilizzando piccoli script per aggiungere funzionalita’ ad un sistema NoCode a cui mancavano.

Le integrazioni, soprattutto con piattaforme enterprise come ad esempio SalesForce, possono essere impossibili o eccessivamente costose, o anche impossibili per policy di sicurezza molto specifiche.

Infine, nonostante la curva di apprendimento più accessibile, esiste comunque uno sforzo necessario per imparare gli strumenti se nuovi. Sebbene questo sia generalmente meno impegnativo rispetto all’apprendimento della programmazione tradizionale.

Anche se a mio parere questo non sarà mai più impegnativo di imparare della programmazione tradizionale, resta comunque una valutazione da considerare e per cui vi invito a rivedere la mappa degli strumenti NoCode.

Rapid Prototyping: la mia esperienza

Personalmente, ho utilizzato questi strumenti in tutti i modi elencati sopra la mappa, a parte la produzione di app per il cellulare.

I casi più frequenti restano quelli di produzione di landing page e siti; tuttavia, i casi più interessanti sono stati quelli in cui ho utilizzato questi strumenti per provare a risolvere problemi più complessi di gestione dati e automazioni.

Per esempio, cercando di migliorare il processo di gestione di fatture e pagamenti usando Make e Airtable, abbiamo finito per costruire una mini-CRM per gestire i Deal, per poi lasciar perdere il prototipo e passare lo sviluppo ad un partner.

Un altro caso interessante ha coinvolto l’utilizzo di diverse API, tra cui quella di OpenAI per semplificare un processo di creazione di annunci pubblicitari.

Il Futuro del NoCode e altre considerazioni

Per uscire un po’ dall’argomento della prototipazione, ci tengo ad evidenziare che ci sono diversi casi di successo che vi invito a cercare online, alcuni li cito alla fine, di persone che hanno creato impresa partendo da 0 utilizzando strumenti NoCode.

Per gli sviluppatori che vedono i vantaggi del NoCode invece c’è una decisione da fare, che diventa più semplice da fare solo con l’esperienza: quando implementare qualcosa scrivendo codice e quando no?

Cisto Kenan Saleh, un imprenditore la cui startup è stata poi acquisita da Lyft nel 2019, che scrive nel suo articolo sul blog di Zapier:

“My advice here would be to code your unique value proposition, if you have the resources and budget available. This is what will differentiate you from your competition and give you the most leverage”.

A questa considerazione aggiungo che il codice è anche l’unica risorsa che poi possiamo registrare come proprietà intellettuale. Infine, un’altra cosa da considerare è come le IA stanno entrando nel processo di sviluppo.

Per ora, le IA non bastano da sole per creare prodotti finiti, ma ci sono strumenti interessanti, come ad esempio Builder.io, che trasformano i design di Figma in codice per il web, responsive, adattandolo a vari framework.

E poi c’è Copilot che aiuta a scrivere più in fretta.

In tutto ciò la necessita’ di avere delle forti basi di informatica non è andata da nessuna parte. Senza delle basi di infrastruttura resta complesso lanciare di applicativi complessi. Anche se questo potrebbe cambiare a breve.

Questi sviluppi potrebbero rendere lo sviluppo di applicativi via codice talmente più veloce da rendere il NoCode obsoleto.

O meglio ancora, se sviluppare utilizzando le AI in linguaggio naturale diventasse un sistema abbastanza potente, sarebbe sicuramente un sistema ancora più semplice dell’utilizzo di un’interfaccia grafica.

Io personalmente sono scettico di questa conclusione, il linguaggio naturale non è abbastanza preciso per permetterci di controllare con un livello di dettaglio abbastanza alto la raffinatezza di un sistema complesso.

A prova di ciò ci sono state diverse iniziative nel tempo (nessuna di successo fin ora) che si sono proposte di creare un “linguaggio” come quelli informatici ma per l’ambiente legale, che attualmente è descritto totalmente in linguaggio naturale e ne subisce i difetti/qualità, che si traducono poi nelle sfumature di significati, nei malintesi e nelle possibilità di avere diverse interpretazioni.

Per approfondire

Durante le mie ricerche ho trovato diversi siti interessanti, che ho deciso di raggruppare qui sotto:

E voi, che ne pensate? Come fate Rapid Prototyping? Fatecelo sapere nei commenti 😉

Dicci cosa ne pensi

Le slide sono disponibili per studenti ed ex studenti del Master in Product Management

Accedi a "Agile Starter Kit" Gratis

Iscriviti alla newsletter e accedi ad Agile Starter Kit: la cartella che contiene oltre 70 pagine su Agile, Scrum / Kanban, Organizzazione Team, User Story, Backlog, e tutto ciò che ti serve per partire.

Scarica il post sulle alternative a Scrum

Iscriviti alla newsletter e scarica gratuitamente il post "Agile Scrum: Alternative più flessibili e agili"