I primi quattro moduli hanno raccontato tre livelli tecnologici: streaming, metaversi, realtà aumentata. Questo modulo ne aggiunge un quarto, meno visibile e altrettanto decisivo: l'integrazione.

È una tentazione naturale pensare alla piattaforma web come a un contenitore — una cartella con dentro tre link. Si fa lo streaming, si fanno i metaversi, si fa l'AR, e poi si mette tutto su un sito. In quella visione il sito è logistica: serve a non perdere gli URL. È una visione sbagliata, e costosa.

L'integrazione è essa stessa un livello di progettazione, con un proprio lavoro e un proprio valore. Tre esperienze tecnologicamente eterogenee — un video, un mondo 3D, un layer di camera — non diventano un progetto solo perché condividono un dominio. Diventano un progetto quando un utente può passare dall'una all'altra senza attrito, senza chiedersi dove si trova, senza incontrare tre estetiche e tre logiche di navigazione diverse.

Il caso del progetto Osaka lo dice con un dato preciso: l'integrazione delle tre tecnologie ha generato quattro sfide tecniche serie — bundle troppo pesanti, compatibilità browser, performance mobile, gestione dello stato. Nessuna di queste sfide appartiene allo streaming, ai metaversi o all'AR presi singolarmente. Appartengono tutte al lavoro di tenerli insieme. È lavoro vero, e va preventivato come tale.

La conseguenza progettuale è semplice. La piattaforma non è l'ultimo passo, quello in cui si "mette online" ciò che è già pronto. È un livello da pensare fin dall'inizio, con lo stesso peso degli altri tre. Chi lo tratta come logistica si ritrova, alla fine, con tre buoni progetti e nessun progetto.

C'è una differenza che sembra accademica e invece decide la qualità di una piattaforma: la differenza tra la sua struttura e i percorsi che la attraversano.

La struttura — la sitemap — è l'albero delle pagine: home, streaming, metaversi, AR, gallery, contatti. È statica, è un organigramma. Lo user journey è un'altra cosa: è il racconto di come una persona reale, con un bisogno reale, attraversa quella struttura nel tempo. E le persone reali non sono una sola.

Il progetto Osaka ne ha mappate quattro, e vale la pena notare quanto sono diverse. Lo spettatore occasionale arriva da un link social durante la diretta, vuole il player e lo vuole subito. L'appassionato di VR arriva prima dell'evento, cerca i metaversi, tornerà più volte. L'early adopter è incuriosito dall'AR e finirà per condividere sui social. Il ricercatore o docente cerca documentazione e archivi per usarli altrove. Stessa piattaforma, quattro film completamente diversi.

Progettare per la sitemap significa assicurarsi che tutte le pagine esistano e siano collegate. Progettare per gli user journey significa assicurarsi che ciascuno di quei percorsi sia fluido dall'inizio alla fine — che lo spettatore occasionale trovi il player in un secondo, che il docente non debba scavare per arrivare agli archivi. È un lavoro più scomodo, perché obbliga a scegliere chi servire bene, ma è l'unico che produce una piattaforma davvero usabile.

Per chi progetta la propria porta d'ingresso, la regola pratica è: prima di disegnare le pagine, scrivi i journey. Tre o quattro, con nome e bisogno. Poi verifica che la struttura li serva tutti. La sitemap che ne esce sarà migliore di qualunque sitemap disegnata per prima.

Ogni progetto culturale digitale ha una porta d'ingresso. La domanda non è se ce l'ha, ma se qualcuno l'ha progettata.

Spesso la risposta è no. La porta è il sottoprodotto di altre decisioni: è il sito che "serviva comunque", messo insieme alla fine, con la home che elenca quello che c'è. Funziona, nel senso che le pagine si aprono. Ma non accoglie nessuno: lascia l'utente a capire da solo dove andare.

Il progetto Osaka ha trattato la porta come un oggetto di progetto a sé — pantheon.show, un single point of entry pensato con cinque principi architetturali espliciti e quattro user journey mappati. Non perché un sito sia difficile da fare, ma perché la porta è il punto in cui un pubblico eterogeneo — dallo studente tech al melomane poco digitale — incontra un'architettura complessa. Se quel punto è confuso, tutto il resto, per molti utenti, semplicemente non esiste.

Trasferire questo al proprio conservatorio non richiede lo stack del progetto Osaka. Richiede una sequenza di domande, da porsi prima di aprire l'editor del sito: chi arriva, da dove, con quale bisogno; cosa deve vedere nei primi cinque secondi; quale percorso deve poter fare senza attrito; cosa succede se il suo device non regge il contenuto più pesante.

Sono domande di progettazione dell'esperienza, non di tecnologia. E sono le domande che separano una porta d'ingresso da un elenco di link. Le prossime schermate le trasformano in uno strumento.