Un template risolve molto rapidamente un problema che quasi nessun progetto ha: assomigliare esattamente alla demo del template.
Nella demo tutto funziona. I titoli hanno la lunghezza giusta, le fotografie condividono la stessa luce, i testi sembrano scritti da una persona serena e nessuno chiede di collegare il sito al gestionale sviluppato nel 1997.
Poi arrivano contenuti, esigenze e persone reali.
Il template, che il primo giorno sembrava una scorciatoia, comincia lentamente a diventare il territorio su cui bisogna costruire una strada.
Non c'è niente di sbagliato nei template. Possono essere una soluzione ottima per progetti semplici, budget contenuti, prototipi e siti che seguono strutture comuni.
Il problema nasce quando vengono presentati come il modo economico per realizzare qualunque progetto.
Perché un template costa poco soltanto finché non deve smettere di essere sé stesso.
Il prezzo di acquisto non è il costo del progetto
Un tema può costare poche decine di euro. Un page builder può essere incluso nell'hosting. Un pacchetto promette cento demo installabili con un clic.
Il confronto con un progetto su misura sembra immediato: da una parte migliaia di euro, dall'altra 59 dollari e magari una licenza “lifetime”.
Ma il prezzo del componente è soltanto una voce.
Il costo reale comprende:
- capire come è stato costruito;
- adattarlo all'identità visiva;
- sostituire i contenuti dimostrativi;
- modificare componenti che non corrispondono alle esigenze;
- aggiungere funzioni mancanti;
- rimuovere comportamenti inutili;
- verificare responsive e accessibilità;
- gestire aggiornamenti e compatibilità;
- mantenere nel tempo le personalizzazioni.
Il template non elimina il lavoro. Decide in anticipo una parte del lavoro e lascia a noi il compito di negoziare tutto il resto.
La demo è un caso ideale
Le demo sono progettate per valorizzare il tema.
Non devono gestire un titolo di centoventi caratteri, una fotografia verticale caricata dal telefono, una tabella tecnica con trenta colonne o la necessità del cliente di mettere in evidenza contemporaneamente sette cose.
Quando inseriamo i contenuti veri emergono le assunzioni nascoste:
- il componente funziona bene soltanto con tre elementi;
- l'immagine deve avere un rapporto preciso;
- il sottotitolo non può superare due righe;
- la navigazione mobile non prevede quel livello gerarchico;
- le traduzioni tedesche occupano il doppio dello spazio;
- la griglia è elegante finché tutte le schede hanno la stessa quantità di testo.
Non sono necessariamente difetti. Ogni design si basa su vincoli.
Il problema è scoprire i vincoli dopo aver scelto lo strumento.
Il page builder sposta il lavoro
I page builder promettono libertà: colonne, blocchi, margini, colori, animazioni e componenti trascinabili.
La libertà è reale. È anche una responsabilità.
Se ogni redattore può decidere struttura, spaziatura, tipografia e comportamento di ogni pagina, il sistema non possiede più una grammatica. Possiede una collezione di decisioni locali.
All'inizio tutto sembra flessibile. Dopo qualche anno troviamo:
- lo stesso componente ricostruito in cinque modi;
- colori quasi uguali ma non identici;
- spaziature inserite manualmente;
- layout duplicati e poi modificati separatamente;
- pagine che nessuno osa più toccare;
- HTML generato da livelli annidati che rendono difficile capire il risultato.
Il page builder non ha eliminato la progettazione. L'ha distribuita tra persone, momenti e schermate diverse.
E una progettazione distribuita senza regole tende a diventare archeologia.
Personalizzare significa spesso combattere le decisioni precedenti
Un progetto su misura parte dai requisiti e produce una struttura.
La personalizzazione di un tema parte da una struttura esistente e cerca di farla coincidere con i requisiti.
Quando la distanza è piccola, il secondo approccio è efficiente. Quando è grande, ogni modifica richiede di capire che cosa verrà influenzato.
Cambiare un header può coinvolgere impostazioni del tema, template, CSS aggiuntivo, breakpoint definiti altrove e funzioni del builder. Una modifica apparentemente semplice diventa una trattativa tra più livelli.
Si accumulano override.
Prima una regola corregge il tema. Poi una seconda corregge la prima su mobile. Una terza corregge entrambe in una pagina speciale. Alla fine il browser applica correttamente tutto, ma soltanto perché ha sviluppato una conoscenza del progetto superiore alla nostra.
Le funzioni pronte portano con sé un modo di lavorare
Installare un plugin è spesso più rapido che sviluppare una funzione.
Ma la funzione pronta non arriva da sola. Porta un modello dati, un'interfaccia, convenzioni, permessi, aggiornamenti e dipendenze.
Un sistema eventi decide che cosa sia un evento. Un plugin portfolio decide come organizzare i progetti. Un componente multilingua introduce il proprio modo di rappresentare le traduzioni.
Se il progetto coincide con queste decisioni, abbiamo risparmiato molto lavoro.
Se non coincide, cominciamo ad aggiungere campi, hook, filtri, sincronizzazioni e correzioni. A quel punto non stiamo più usando una soluzione pronta: stiamo mantenendo una variante privata di una soluzione pensata per altri.
Il debito visivo
Si parla spesso di debito tecnico e meno di debito visivo.
Il debito visivo nasce quando ogni nuova esigenza viene risolta aggiungendo qualcosa senza poter rivedere il sistema complessivo.
Un nuovo pulsante usa uno stile quasi coerente. Una sezione speciale introduce una variante tipografica. Una landing page adotta componenti diversi perché il builder non permette di riutilizzare quelli vecchi.
Il sito continua a funzionare, ma perde progressivamente identità e prevedibilità.
Ogni pagina sembra plausibile da sola. Insieme sembrano progettate durante governi diversi.
Un design system non serve soltanto ai grandi prodotti digitali. Anche un piccolo sito beneficia di regole chiare: tipografia, colori, spazi, componenti e comportamenti che non devono essere reinventati in ogni schermata.
Il costo della manutenzione arriva dopo
Il giorno della pubblicazione un sito non ha ancora dimostrato molto.
Il vero test comincia con il primo aggiornamento importante.
Il tema cambia versione. Il builder modifica il markup. Un plugin richiede una nuova versione di PHP. Un componente viene abbandonato. Il cliente chiede una funzione che la struttura originale non aveva previsto.
Ogni livello aggiunto all'inizio per risparmiare tempo deve continuare a essere compatibile con gli altri.
Questo non significa che un progetto custom non abbia manutenzione. Ne ha, e può essere impegnativa.
La differenza è che nel codice su misura le dipendenze dovrebbero essere scelte consapevolmente. In un pacchetto preconfezionato possono essere parte del punto di partenza, anche quando il progetto non le usa direttamente.
Quando un template è la scelta giusta
Ci sono molti casi in cui partire da un tema è ragionevole:
- il budget è realmente limitato;
- il sito ha una vita breve;
- la struttura richiesta è comune;
- l'identità visiva può adattarsi al sistema scelto;
- non sono previste integrazioni particolari;
- il cliente accetta consapevolmente i vincoli;
- la rapidità vale più della personalizzazione;
- il progetto serve a validare un'idea.
In questi casi il template non è una soluzione inferiore. È una scelta proporzionata.
Serve però una disciplina importante: non promettere contemporaneamente standardizzazione e completa libertà.
Se scegliamo una base pronta per risparmiare, dobbiamo anche rispettarne i confini. Trasformarla lentamente in un progetto su misura può costare più che progettarlo correttamente dall'inizio.
La domanda da fare prima
Prima di scegliere un template chiederei:
“Quanto è disposto il progetto ad adattarsi a questa struttura?”
Se la risposta è “molto”, probabilmente abbiamo trovato una scorciatoia utile.
Se la risposta è “per niente”, non abbiamo acquistato una soluzione. Abbiamo acquistato il primo ostacolo.
Il valore di un progetto custom non sta nel fatto che ogni riga venga scritta da zero. Anche il software su misura usa framework, librerie e componenti esistenti.
Sta nel fatto che le decisioni vengono prese a partire dal problema.
Un template costa poco il primo giorno perché molte decisioni sono già state prese.
Il costo successivo dipende da quante di quelle decisioni dovremo disfare.