← Tutti i Pensieri

Un progetto digitale non finisce quando va online

Il lancio è un traguardo visibile. Il valore, però, dipende da ciò che accade nelle settimane successive: persone, contenuti, controlli e decisioni.

Copertina del pensiero: Un progetto digitale non finisce quando va online

Quando un sito viene pubblicato o una nuova applicazione entra in uso, è naturale considerare il progetto concluso. Finalmente si può aprire un link, mostrare il risultato e iniziare a utilizzarlo. Capisco bene la soddisfazione di quel momento. Ma, nel mio modo di vedere il lavoro digitale, la messa online segna soprattutto un passaggio: da ciò che abbiamo progettato a ciò che le persone faranno davvero.

Una pagina può essere chiara il giorno del lancio e diventare imprecisa dopo un cambio di orari. Un modulo può funzionare perfettamente durante i test, ma lasciare senza risposta una richiesta se nessuno controlla la casella che la riceve. Un'app può offrire una funzione utile e poi perdere valore perché le informazioni al suo interno non vengono più aggiornate.

Non sono necessariamente difetti di sviluppo. Sono spesso responsabilità rimaste senza un proprietario.

Il primo controllo è organizzativo

Prima di pensare a nuove funzionalità, mi farei quattro domande molto concrete.

Chi aggiorna i contenuti quando cambiano? Chi riceve e gestisce le richieste? Chi si accorge se qualcosa smette di funzionare? Chi decide quali miglioramenti hanno davvero priorità?

Se la risposta è «ci penseremo», il progetto parte con un punto debole. Non serve per forza un gruppo dedicato o una procedura lunga. Anche in una piccola attività possono bastare un referente, accessi ordinati e poche responsabilità scritte con chiarezza. L'importante è sapere a chi tocca fare cosa, senza affidare tutto alla memoria di una sola persona.

Penso, per esempio, a un sito che riceve richieste di preventivo. La verifica tecnica del modulo è necessaria, ma non basta. Bisogna sapere dove arrivano i messaggi, chi li legge, che cosa succede se quella persona è assente e come si riconosce una richiesta rimasta senza risposta. Il percorso digitale continua anche dopo il clic su «Invia».

I contenuti hanno una data di scadenza, anche quando non la mostrano

Prezzi, servizi, recapiti, disponibilità, fotografie e istruzioni possono cambiare. Un'informazione obsoleta non è soltanto un dettaglio editoriale: può creare aspettative sbagliate o costringere qualcuno a cercare conferma altrove.

Per questo trovo utile distinguere i contenuti stabili da quelli che richiedono attenzione frequente. Un testo che racconta la visione di un'attività può durare a lungo. Un menù, un listino o gli orari di apertura richiedono un controllo diverso. Quando progetto uno strumento, mi interessa anche capire quanto sarà semplice tenerlo corretto. Se aggiornare una riga richiede un intervento tecnico ogni volta, quella riga rischia di restare vecchia.

Un controllo periodico può essere essenziale e breve: aprire le pagine più importanti da telefono, provare i contatti, rileggere le informazioni che cambiano più spesso. Non è un audit spettacolare. È manutenzione della fiducia.

Osservare l'uso prima di aggiungere funzioni

Dopo il lancio emergono domande che in fase di progetto non potevamo risolvere del tutto. Le persone trovano ciò che cercano? Dove si fermano? Quali richieste arrivano più spesso? Ci sono passaggi che richiedono spiegazioni ripetute?

Non serve trasformare ogni osservazione in un numero. Una domanda ricorrente ricevuta via email può segnalare una pagina poco chiara. Una procedura che il personale aggira sempre allo stesso modo può indicare che lo strumento non segue il lavoro reale. Questi segnali vanno raccolti e interpretati, senza reagire a ogni singolo episodio con una nuova funzionalità.

Io partirei da un piccolo registro: problema osservato, frequenza, conseguenza per chi usa il servizio e possibile intervento. A quel punto si può distinguere ciò che va corretto subito da ciò che merita un approfondimento. A volte la soluzione è modificare una frase. A volte è ripensare un passaggio. A volte serve sviluppare qualcosa di nuovo. La scelta viene dopo aver capito il problema.

Un piano semplice per le prime settimane

Se dovessi organizzare il periodo successivo alla pubblicazione, lo dividerei in tre momenti.

Subito dopo il lancio: verificherei i percorsi fondamentali su dispositivi reali, i recapiti, i moduli e gli accessi delle persone incaricate. Annoterei chi interviene in caso di errore.

Dopo alcune settimane: raccoglierei richieste, dubbi e ostacoli ricorrenti. Controllerei i contenuti più soggetti a cambiamento e farei una prima lista di correzioni, ordinata per impatto.

Con una cadenza sostenibile: fisserei un controllo leggero ma regolare. La frequenza dipende dal progetto: un'informazione che cambia ogni giorno non può essere trattata come una pagina istituzionale. Il punto è scegliere un ritmo che l'attività riesca davvero a mantenere.

Non considero questo lavoro un'aggiunta successiva al progetto. Fa parte della sua progettazione. Un sito o un'applicazione diventano utili quando restano affidabili mentre l'attività, le persone e le informazioni cambiano.

Il giorno della pubblicazione possiamo dire che qualcosa è pronto per essere usato. Solo il lavoro che viene dopo ci dirà quanto bene accompagna chi lo usa.