Guida digitale o app propria? Costi e un metodo per scegliere con criterio

Per prima cosa bisogna stabilire quale problema debba risolvere la guida digitale. I visitatori non comprendono il contesto degli oggetti esposti? Mancano versioni linguistiche, contenuti audio o un percorso per famiglie? I contenuti diventano rapidamente obsoleti? Oppure la struttura vuole mantenere il contatto dopo la visita? Ognuna di queste esigenze porta a un diverso ambito del prodotto.

Il semplice fatto di avere un'icona in un app store non risolve nessuno di questi problemi. È come ordinare una bella vetrina prima di decidere che cosa debba contenere. Conviene prima descrivere le situazioni d'uso, i contenuti e il processo di lavoro del team, e solo dopo scegliere lo strumento.

La domanda giusta è quindi: «Qual è il modo più semplice per offrire al visitatore la storia giusta nel posto giusto, consentendo al nostro team di svilupparla in seguito?». Un'app propria è una delle possibili risposte, ma non dovrebbe essere la risposta automatica.

La prima opzione è un semplice sito web accessibile tramite un codice QR. Funziona bene per poche descrizioni pubbliche, ma con l'aumento del numero di percorsi, lingue, registrazioni e dipendenti emerge rapidamente la necessità di un pannello di gestione dei contenuti, di strumenti di analisi e di una navigazione comune.

La seconda strada è una piattaforma condivisa. La struttura utilizza un'app per visitatori già pronta, pagine pubbliche e un pannello di amministrazione, mantenendo però il proprio profilo, i contenuti, le mostre, i percorsi e la segnaletica. Le funzionalità sviluppate per più luoghi non devono essere commissionate da zero da ogni istituzione separatamente.

La terza opzione è un'app mobile propria con la necessaria infrastruttura di supporto. «Propria» non significa soltanto un colore diverso per un pulsante. Di solito comprende la progettazione dell'esperienza, un'app per iOS e Android, un server o servizi cloud, un pannello di gestione dei contenuti, strumenti di analisi, test, pubblicazione e aggiornamenti successivi.

• Sito semplice: ambito limitato e pochi processi editoriali.
• Piattaforma condivisa: funzionalità pronte, contenuti propri e avvio rapido.
• App propria: pieno controllo, ma anche piena responsabilità del prodotto.

Non esiste un prezzo unico per un'app, perché questo termine comprende sia un catalogo con poche schermate sia un sistema completo con account, pagamenti, mappa, modalità offline e pannello per il personale. Un punto di riferimento può essere fornito dai dati di Clutch sui progetti descritti dai clienti: la maggior parte delle realizzazioni analizzate rientrava nell'intervallo tra 10 000 e 49 999 dollari, ma il costo medio era di circa 90 780 dollari e la durata media del progetto di circa 11 mesi.

Uno studio di GoodFirms condotto su 167 aziende di sviluppo di applicazioni indicava circa 24 830-59 150 dollari per un'app semplice e 59 508-137 150 dollari per una soluzione avanzata. I dati di Clutch e GoodFirms descrivono il mercato generale dello sviluppo di applicazioni. Non sono un preventivo per una guida museale e non vanno trasferiti meccanicamente a un'offerta per una struttura specifica.

Per confrontare le offerte, adotta un ambito ipotetico comune: 10 punti, due lingue, un percorso e tre anni di utilizzo. Ogni fornitore dovrebbe formulare un preventivo per lo stesso ambito e indicare quali attività restano a carico della struttura.

• Sito con codici QR: verifica il costo di realizzazione del sito, dell'hosting e degli aggiornamenti, oltre alle modalità di modifica autonoma dei contenuti.
• Piattaforma in abbonamento: considera l'avvio e l'abbonamento per l'intero periodo, i limiti del piano e gli eventuali costi aggiuntivi.
• App propria: includi progettazione, sviluppo dell'app e del pannello, pubblicazione, infrastruttura, aggiornamenti e assistenza.

In ogni caso, aggiungi la preparazione dei contenuti e delle traduzioni, la produzione della segnaletica, il tempo di lavoro del team e il costo di esportazione e trasferimento dei dati in caso di cambio di fornitore. Separa le spese una tantum da quelle ricorrenti e verifica quali voci siano già comprese nel prezzo. Solo un calcolo di questo tipo permette di confrontare tre anni di utilizzo di una soluzione.

Un'app non diventa un oggetto espositivo finito il giorno della pubblicazione. Apple e Google modificano i sistemi, i requisiti degli store, le regole sulla privacy e le capacità dei dispositivi. Occorre aggiornare le librerie, correggere gli errori, monitorare la sicurezza, testare le nuove versioni e intervenire quando un servizio esterno cambia il proprio funzionamento.

GoodFirms indica una media annua di circa il 25% del costo di sviluppo per manutenzione e assistenza, esclusi lo sviluppo di nuove funzionalità e l'adattamento del software a un aumento del carico. È un riferimento generale tratto da una ricerca sul mercato delle applicazioni, non una tariffa di manutenzione per una guida museale. L'ambito dell'assistenza e il relativo prezzo devono essere confermati in un'offerta specifica.

A questo si aggiungono servizi cloud, backup, monitoraggio, strumenti di analisi, invio di messaggi, archiviazione dei media e assistenza agli utenti. Il costo dell'infrastruttura può essere contenuto quando il traffico è basso, ma dipende dall'utilizzo. Firebase e servizi simili mettono a disposizione calcolatori proprio perché una sola cifra fissa non può rappresentare tutti i casi.

Gli account degli app store costituiscono solo una piccola parte del conto: la quota standard dell'Apple Developer Program è di 99 dollari statunitensi all'anno, mentre la registrazione a Google Play costa 25 dollari statunitensi una tantum. Apple precisa che i prezzi possono variare in base alla regione. Preparare le versioni, eseguire i test, gestire la pubblicazione e mantenere la conformità richiede più lavoro.

• aggiornamenti e test delle nuove versioni di iOS e Android
• sicurezza, backup e monitoraggio degli errori
• hosting, contenuti multimediali, messaggi e altri servizi addebitati in base all'utilizzo
• gestione degli store, delle condizioni d'uso, della privacy e delle segnalazioni degli utenti
• sviluppo del pannello di amministrazione e di nuove funzionalità

La struttura può essere il luogo più importante del sabato pomeriggio di un visitatore, ma raramente è l'unica istituzione che visita durante l'anno. La richiesta di cercare un'app, installarla, accettare le autorizzazioni e creare un account arriva di solito quando la persona si trova già alla biglietteria o davanti al primo oggetto esposto.

Un'app propria deve quindi offrire un motivo chiaro per essere installata: una funzionalità usata più volte, una modalità di visita particolare, un accesso acquistato in anticipo o un'esperienza impossibile da offrire su un sito web. La sola presenza di descrizioni e contenuti audio potrebbe non bastare. Se ogni luogo visitato richiedesse un'app distinta, lo schermo del telefono somiglierebbe presto a un catalogo degli stemmi di un'intera regione.

Una piattaforma comune riduce questa barriera. L'utente può già conoscere l'app da una visita precedente e può aprire i contenuti pubblici anche senza installare nulla. La struttura mantiene il proprio spazio e il proprio marchio, ma non chiede al visitatore di iniziare il rapporto scaricando un altro programma.

Il valore principale di una piattaforma comune non sta nel fatto che tutti i luoghi abbiano lo stesso aspetto. Si tratta di riutilizzare ciò che non ha senso sviluppare separatamente: accesso, supporto delle lingue, audio, codici QR, percorsi, accessibilità, strumenti di analisi, notifiche e app per il personale. La disponibilità di queste funzionalità dipende dalla soluzione e dal piano scelti, quindi va verificata nell'offerta specifica. La struttura investe soprattutto nei propri contenuti e nella progettazione della visita.

Quando il sistema viene aggiornato per una nuova versione di telefono o riceve un miglioramento dell'accessibilità, tutte le strutture ne beneficiano. Il costo del prodotto viene distribuito tra molti clienti, invece di ricomparire in una fattura separata per ogni istituzione. È un modello simile a un'infrastruttura espositiva condivisa: la cornice può essere standard, ma il quadro rimane il proprio.

La piattaforma genera anche un effetto di rete. Un utente che l'ha conosciuta in un museo all'aperto può poi utilizzare lo stesso profilo e le stesse modalità d'uso in un giardino botanico, in un castello o lungo un percorso urbano. Per la singola struttura questo significa una barriera d'ingresso più bassa; per il visitatore, un'esperienza più prevedibile.

Il limite è una minore libertà nella progettazione di funzionalità del tutto insolite. In cambio, il team non deve gestire un proprio ciclo di rilascio, un'infrastruttura propria e la compatibilità con ogni nuovo dispositivo. Per molti luoghi di piccole e medie dimensioni, questo compromesso è semplicemente più ragionevole dal punto di vista economico.

La decisione più sicura si basa sull'utilizzo reale, non su una presentazione in sala riunioni. Live Story permette di attivare un profilo pubblico, alcuni o una dozzina di punti principali e un percorso senza avviare un progetto informatico separato. Il piano Community o Lite può fungere da vero progetto pilota.

Dopo alcune settimane o alcuni mesi, la struttura sa già di più: quali codici vengono scansionati, se le persone ascoltano i contenuti audio, quali lingue scelgono, dove interrompono il percorso e che cosa chiedono al personale. È anche possibile verificare se il team dispone del tempo e dei materiali necessari per sviluppare regolarmente i contenuti. È importante, perché anche la migliore app non può scrivere una buona storia al posto dell'istituzione senza fonti e decisioni editoriali.

Se le funzionalità già disponibili risolvono il problema, si può passare a un piano superiore e aggiungere percorsi, accessi, gruppi o funzioni di comunicazione. Se il progetto pilota fa emergere un'esigenza davvero unica, i dati del test diventano la base per definire molto meglio l'incarico di sviluppo di un'app propria.

Un'app propria non è una cattiva idea. Può essere la soluzione migliore per una grande istituzione o una rete con processi unici, un marchio forte, molti utenti abituali e un team capace di sviluppare il prodotto per anni. Può essere necessaria per attrezzature specialistiche, funzionalità AR avanzate, esigenze particolari di localizzazione all'interno degli edifici o integrazioni non supportate dalla piattaforma.

La condizione, però, è avere un budget che non copra soltanto il lancio. Servono un responsabile del prodotto all'interno dell'istituzione, un processo di creazione e approvazione dei contenuti, responsabilità definite sui dati, un piano di assistenza e risorse per le versioni successive. Senza questi elementi, un'app propria può trasformarsi rapidamente in una sala digitale chiusa per lavori.

Se la maggior parte delle esigenze riguarda descrizioni, audio, lingue, codici QR, percorsi, quiz, accessi e contatti dopo la visita, una piattaforma condivisa consente di solito di raggiungere l'obiettivo più rapidamente e a un costo inferiore. La scelta, inoltre, non deve essere definitiva. Un progetto pilota su Live Story può confermare l'utilità di un piano superiore oppure fornire argomenti a favore dello sviluppo di un prodotto separato.