Come pianificare un sito web: la guida completa
La maggior parte dei progetti di sviluppo web non slitta perché il codice era difficile. Slitta perché il piano era debole: nessuno aveva concordato cosa dovesse ottenere il sito, chi avrebbe scritto i testi, o cosa significasse «finito».
Questa guida copre il lavoro di pianificazione che precede design e realizzazione, nell'ordine in cui è davvero utile, e le decisioni costose da cambiare più avanti.
Parti da un compito che il sito deve svolgere#
Un sito che deve fare tutto di solito non ottiene nulla di misurabile. Prima di ogni altra cosa, scrivi l'unica azione che conta di più: un modulo inviato, una telefonata, un acquisto, una prenotazione, un download.
Tutto il resto — struttura delle pagine, navigazione, cosa sta nella parte alta, quanto conviene spendere — discende da quella risposta. Un sito il cui compito principale è generare richieste è un progetto diverso da un sito il cui compito è vendere 4.000 prodotti.
- Obiettivo primario: l'unica azione che terresti se potessi tenerne una sola.
- Obiettivi secondari: utili, ma non al punto da compromettere il primario.
- Come lo misurerai: un numero verificabile il prossimo trimestre, non «più traffico».
- Cosa il sito non deve fare: messo per iscritto, così resta fuori perimetro.
Se due persone della tua organizzazione indicherebbero obiettivi primari diversi, quel disaccordo riemergerà alla sesta settimana di realizzazione. Risolvilo alla settimana zero, quando costa una riunione anziché una ricostruzione.
Sappi chi arriva e per cosa#
La ricerca sul pubblico non deve essere un esercizio formale. Serve una descrizione breve e onesta dei due o tre gruppi che visitano davvero, con quale domanda arriva ciascuno e cosa li farebbe andare via.
| Visitatore | Arriva chiedendosi | Se ne va perché |
|---|---|---|
| Primo acquirente | Questa gente sa fare ciò che mi serve? | Nessuna prova, nessun prezzo, nessuna chiarezza |
| Cliente abituale | Dov'è la cosa che mi serve adesso? | L'attività è sepolta a tre clic |
| Chi sta confrontando | In cosa è diverso dagli altri? | Testi generici che potrebbero essere di qualsiasi concorrente |
| Un candidato | Com'è lavorare qui? | Nessuna pagina lavora con noi, o una vecchia |
Decidi le pagine prima del design#
La struttura delle pagine è la cosa meno costosa da cambiare sulla carta e una delle più costose da cambiare dopo l'approvazione di un design. Elenca ogni pagina, raggruppale in sezioni e segna quali servono al lancio e quali possono arrivare dopo.
L'errore ricorrente è una struttura che rispecchia il tuo organigramma anziché il compito del visitatore. Nessuno arriva cercando la tua «Divisione Soluzioni»; arriva cercando ciò che gli serve.
- Elenca ogni pagina che pensi ti serva, una per riga, senza raggruppare.
- Segna ciascuna come critica per il lancio o successiva. Sii severo: quasi tutti i siti partono con meno pagine del previsto.
- Raggruppa quelle critiche in non più di cinque o sei sezioni di primo livello.
- Scrivi l'unica frase che ogni pagina deve trasmettere. Se non ci riesci, probabilmente quella pagina non dovrebbe esistere.
- Verifica che l'obiettivo primario sia raggiungibile con un clic da ogni pagina di primo livello.
Il contenuto è il percorso critico: pianificalo per primo#
Testi, fotografie e dati di prodotto bloccano più lanci di qualsiasi problema tecnico. La realizzazione finisce e il sito resta sei settimane in preproduzione ad aspettare una pagina «Chi siamo».
Decidi ora chi scrive ogni pagina, chi la approva e per quando, e tratta quelle date con la stessa serietà delle milestone di sviluppo. Se internamente non ha tempo nessuno, metti a budget un copywriter: costa meno di un team di sviluppo fermo.
- Assegna un responsabile e una data a ogni pagina di testo, non «il marketing».
- Decidi cosa fare dei contenuti esistenti: migrare, riscrivere o eliminare. La maggior parte andrebbe eliminata.
- Prenota la fotografia presto: ha i tempi più lunghi di tutta la lista.
- Per un negozio, esporta e ripulisci i dati di prodotto prima dell'inizio, non durante.
- Concorda chi dà l'approvazione finale. Due approvatori con pari autorità sono un rischio per i tempi.
Un test utile: se il sito fosse pronto domani, riusciresti a riempirlo? Se la risposta è no, il contenuto è la tua vera scadenza.
Fissa una fascia di budget e decidi l'approccio di realizzazione#
La pianificazione finisce con due numeri e una scelta: quanto puoi spendere, quando ti serve online, e se si tratta di un template, di un CMS o di uno sviluppo su misura. Quei tre punti decidono con chi dovresti perfino parlare.
| Approccio | Va bene quando | Rischio principale |
|---|---|---|
| Costruttore di siti | Piccolo sito vetrina, nessun requisito insolito | Sbatti contro un limite e devi ricominciare |
| CMS (es. WordPress) | Sito editoriale, aggiornamenti frequenti da non sviluppatori | Proliferazione di plugin e manutenzione continua |
| Piattaforma e-commerce | Vendita di prodotti, esigenze di pagamento standard | Commissioni di piattaforma e personalizzazione limitata |
| Sviluppo su misura | Il sito è il prodotto, o le integrazioni escludono il resto | Costo più alto, e la manutenzione è tua |
Domande frequenti
Quanto dovrebbe durare la pianificazione?
Per un sito di piccola impresa, una o due settimane di lavoro reale, non di tempo trascorso. Per un negozio o un'applicazione, tre-sei settimane, in gran parte dedicate all'inventario dei contenuti e ai dati di prodotto più che ai documenti. Se la pianificazione si trascina per mesi, di solito significa che l'obiettivo primario non è stato concordato e la discussione gira in tondo.
Mi serve un documento formale dei requisiti?
Serve qualcosa di scritto a cui entrambe le parti possano fare riferimento, ma non deve essere lungo. Una struttura delle pagine, un elenco delle funzionalità nel perimetro, un elenco delle cose esplicitamente escluse e un responsabile dei contenuti per pagina eviteranno più contenziosi di una specifica di cinquanta pagine che nessuno legge. L'elenco delle esclusioni è la parte che si salta ed è quella che salva il progetto.
Devo pianificare il design in questa fase?
Pianifica la struttura, non l'aspetto. Decidere quali pagine esistono e cosa deve ottenere ciascuna è pianificazione; scegliere colori e caratteri è design, e farlo prima che la struttura esista significa che il design verrà rifatto appena arriva il contenuto vero. I wireframe sono la via di mezzo utile.
E se i requisiti cambiano a metà progetto?
Cambieranno. Ciò che conta è aver concordato in anticipo come si gestiscono i cambiamenti: chi può richiederli, chi li quota, e se spostano la data di lancio. Un progetto con un processo di cambiamento slitta in modo controllato; uno senza slitta in una discussione.
pianificare un sito webpianificazione sito webpiano progetto webrequisiti sito webstruttura sito webpianificazione sviluppo web
