Breve Progetto del Sito Web: Come Scriverne Uno che Prezzi Correttamente

Perché un Brief Vago Consuma Silenziosamente il Tuo Budget

Risposta diretta: uno studio non può valutare la tua intenzione, solo il tuo documento. Tutto ciò che il documento omette, entrambe le parti lo completano silenziosamente e in modo diverso — e le due immagini si incontrano finalmente alla demo, quando cambiare rotta è costoso.

Prendi una frase che suona perfettamente chiara: abbiamo bisogno di un sito web aziendale, circa dieci pagine, con un modulo di richiesta.Ci sono almeno quattro biforcazioni nascoste lì dentro, e ognuna costa denaro:

• Il modulo di richiesta — è un'email a una casella di posta, o crea un affare nel tuo CRM e invia al cliente una risposta automatica?
• Dieci pagine — dieci schermate uniche, ciascuna progettata e costruita separatamente, o un modello compilato dieci volte?
• Contenuto — stai consegnando il testo finito e la fotografia, o qualcuno deve scriverlo e scattarlo?
• Lingue — una, o tre, e chi traduce?

Il divario tra la lettura economica e quella costosa è un multiplo, non un errore di arrotondamento — e entrambe sono oneste, la risposta semplicemente non era nel testo.

Poi arriva il programma. L'ambiguità arriva a fette, ognuna vestita come una piccola cosa — un filtro qui, un calcolatore lì, un modulo di preventivo nella pagina dei servizi. Ognuna sembra mezz'ora; insieme riscrivono metà del progetto, e il lancio slitta di mesi. Un buon documento dei requisiti non è burocrazia; è un modo per dissentire presto, mentre dissentire è ancora gratuito. Saltalo e il cliente paga per il rifacimento, mentre lo studio assorbe il costo o discute e perde la relazione.

Brief, Specifica, Ambito di Lavoro — e Chi Li Scrive

Il brief è un documento di raccolta — una o due pagine che il cliente compila: chi sei, cosa vendi, a chi, perché hai bisogno di un sito, cosa ti piace e cosa odi dei concorrenti, budget, scadenza. Descrive il problema, non la soluzione, quindi non può essere valutato con precisione — solo misurato per ordine di grandezza.

La specifica tecnica descrive cosa sarà costruito: elenco delle pagine, struttura di ogni pagina, funzionalità, scenari, integrazioni, requisiti amministrativi, criteri di accettazione. È scritta dopo che il problema è stato compreso, e diventa un'appendice al contratto.L'ambito di lavoro è il confine — cosa è incluso e cosa è escluso. Una riga che dice il contenuto della scheda prodotto è fornito dal cliente vale più di una pagina di prosa elegante.

Chi dovrebbe scrivere la specifica

Risposta breve: il cliente scrive il brief, lo studio scrive la specifica. Sei l'esperto della tua attività — margini, stagionalità, le obiezioni che i tuoi venditori sentono. Lo studio è esperto in cosa si romperà nel terzo mese: quali soluzioni esistono e quanto costano. Lasciato a scriverla da solo, un cliente inventa soluzioni dove non ha esperienza, e il risultato specifica cose che non funzionano in quel modo o richiede tutto in una volta.

Quindi il modello è: il cliente compila un brief; lo studio esegue la scoperta — alcune sessioni di domande scomode, mappando il reale processo aziendale — poi scrive la specifica, e il cliente la legge, discute e approva. La scoperta e la scrittura della specifica sono un lavoro reale: uno studio che offre una specifica dettagliata gratuitamente produrrà una formale, giusto abbastanza per ottenere una firma. Per distinguere i team che scavano genuinamente da quelli che riutilizzano modelli, abbiamo coperto i segnali nella nostra guida su scegliere uno studio web.

L'Introduzione: Obiettivo Aziendale, Pubblico, Concorrenti

La prima sezione di qualsiasi specifica decente risponde a perché, non cosa. Saltalo e nessuna decisione successiva può essere presa: ogni argomento su se un blocco sia necessario si riduce a un criterio, e il criterio deriva dall'obiettivo.

L'obiettivo aziendale

Esprimilo in termini aziendali, non in termini di sito web. "Un sito bello e moderno" è un'opinione. Un obiettivo suona più come: ottenere richieste di installazione da proprietari di case — al momento tutto arriva per telefono e metà di esso si perde, o trasferire i clienti all'ingrosso al self-service. Il primo rende importante il modulo, la fiducia e la velocità; il secondo, un'area account e riordino con un clic. Lo stesso budget, posti diversi.

Il pubblico

Descrivi il comportamento, non i dati demografici. "Uomini, 25-45" non dice nulla a uno sviluppatore. Questo sì:

• Chi decide e chi paga — spesso persone diverse.
• Come arrivano: cercando un problema, seguendo una raccomandazione, cliccando su un annuncio.
• Cosa verificano prima di impegnarsi: prezzo, tempi di consegna, licenze, recensioni, area di copertura.
• Su quale dispositivo si trovano. Un telefono in un cantiere con segnale scarso cambia i requisiti di peso della pagina.

Concorrenti

Fornisci da tre a cinque link, ognuno con una frase: cosa c'è di buono e cosa di cattivo. Non "design carino", ma "il loro prezzo è visibile immediatamente senza un modulo — lo voglio." Questa abitudine fa risparmiare settimane di email, perché trasforma il gusto in requisiti. E scrivi onestamente come ti differenzi da quei concorrenti: se non c'è differenza, non è un problema del sito, e nessuna quantità di front-end lo risolverà.

Elenco delle Pagine e Struttura: Dove Vive la Stima

Qui è dove proviene la maggior parte della stima. La regola è semplice: conti modelli unici, non pagine. Un catalogo con mille prodotti è un modello di scheda prodotto, e un sito di otto pagine progettato pagina per pagina costa più di trenta pagine su tre modelli. Quindi scrivi l'elenco in due passaggi: nomina ogni pagina, poi segna quali sono modelli e quali sono unici.

Come descrivere una pagina

Per ogni pagina unica, elenca i blocchi dall'alto verso il basso con lo scopo di ciascuno. Per una pagina di servizio:

1. Hero: titolo, descrizione in una riga, pulsante per richiedere un preventivo.
2. Cosa è incluso — elenco puntato, da cinque a otto elementi.
3. Come si svolge il lavoro — tre a sei passaggi.
4. Prezzi: tabella dei livelli o una singola riga "da"; decidi durante la scoperta.
5. Lavori correlati — tre schede, estratte automaticamente dal portfolio per tag di servizio.
6. FAQ — modificabile dall'amministratore. Modulo di richiesta.

Nota le due frasi che fanno il grosso del lavoro: "estratte automaticamente per tag" e "modificabile dall'amministratore." Non sono decorazioni, sono ore: un blocco che un editor riempie a mano e un blocco che si assembla da solo dai dati sono lavori diversi a prezzi diversi.

Navigazione e collegamenti tra le pagine

Descrivi il menu principale e il piè di pagina in dettaglio, e come le pagine si collegano: i servizi portano a casi studio, i casi studio tornano al servizio e al modulo, gli articoli ai servizi. Un test utile è camminare nel tuo futuro sito come uno sconosciuto — qualcuno è atterrato su un articolo, cosa vede dopo e dove va? Se non puoi rispondere, quella pagina non è finita. Puoi vedere come si sviluppa in il nostro lavoro recente. E non scrivere "il sito deve essere reattivo" — sono le basi; scrivi dove il mobile si comporta in modo diverso: la tabella dei prezzi diventa schede impilate, il filtro si apre a schermo intero. Quei punti bruciano tempo quando emergono tardi.

Descrivere la Funzionalità Senza Ambiguità

L'errore classico nelle specifiche è descrivere le funzionalità con aggettivi: un filtro conveniente, una ricerca intelligente, un checkout veloce. Questi non sono requisiti, sono desideri: non puoi verificarli, non puoi quantificarli e puoi discuterne per sempre: conveniente secondo chi?

L'alternativa sono gli scenari: chi fa cosa e cosa ottiene. Confronta. Debole: "Account cliente con cronologia ordini." Forte:

• Il cliente accede con email e password; il ripristino della password funziona tramite un link inviato via email.
• Il cliente vede i propri ordini: numero, data, totale, stato e un pulsante "riordina".
• Ci sono cinque stati: nuovo, in corso, spedito, consegnato, annullato, impostati da un manager nell'amministrazione.
• "Riordina" rimette gli articoli nel carrello; qualsiasi articolo esaurito viene saltato e al cliente viene comunicato quale.
• Il cliente scarica una fattura in PDF ma non può modificare il nome dell'azienda registrata: solo un manager può farlo.

La seconda versione può essere quantificata in ore senza una singola chiamata; la prima è solo un'ipotesi, fuori target.

Annota i casi limite

Il costo raramente è il percorso felice: è tutto ciò che lo circonda, dove si nasconde metà del budget:

• Cosa succede senza dati: carrello vuoto, ricerca senza risultati, una categoria senza nulla.
• Cosa succede in caso di errore: pagamento rifiutato, file troppo grande, email già registrata.
• Cosa vede l'utente se la connessione si interrompe durante il pagamento, e chi può fare cosa: editor e amministratori hanno bisogno di permessi diversi.

E contrassegna ogni elemento: necessario per il lancio, bello da avere, o fase due. Questo è il miglior strumento di budget esistente: quando la stima torna più alta di quanto speravi, taglierai deliberatamente invece di colpire a caso ciò che è più vicino.

Contenuti, Integrazioni, Lingue: Chi Fornisce Cosa e Quando

Più progetti muoiono qui che in qualsiasi riga di codice. Il sito è finito e il lancio non avviene: perché il testo non è mai arrivato, o le foto sono scatti di telefono fatti in un magazzino poco illuminato.

Contenuto

Le specifiche devono indicare chiaramente chi possiede ciascun tipo di contenuto e entro quando esiste:

• Testo della pagina. Scritto da te, dal copywriter dello studio, o redatto da te e modificato da noi? Tre prezzi.
• Fotografia. Il tuo archivio, un servizio fotografico o stock? Se è un servizio fotografico — chi lo organizza e lo paga.
• Catalogo. Chi compila le schede, da dove provengono le descrizioni, in quale formato arriva l'esportazione.
• Pagine legali. Politica sulla privacy, termini, dettagli dell'azienda — territorio del cliente, ma lo studio dovrebbe ricordartelo.

E un'ultima riga: cosa succede se il contenuto non è pronto in tempo. La risposta sensata è lanciare con segnaposto su un elenco concordato di pagine, non tenere un sito finito in un cassetto per mesi.

Integrazioni

Descrivi ciascuno allo stesso modo: quale sistema, quali movimenti dove, in quale momento, e cosa succede quando fallisce. "Integrare con CRM" non ha significato — copre sia due ore di lavoro che due settimane. Passa attraverso l'elenco abituale — CRM, gateway di pagamento, spedizione, software di magazzino, email marketing, messaggeri, ricevute fiscali, analisi — e per ciascuno rispondi a tre domande: ha un'API, c'è documentazione, chi detiene le credenziali. Credenziali mancanti sono un rischio, e appartengono alle specifiche piuttosto che emergere una settimana prima del lancio.

Lingue

Multilingue non è un interruttore nell'intestazione. È un modello di dati separato, URL separati, meta tag separati, lavoro editoriale separato, e una regola per cosa succede quando una pagina non ha traduzione. Decidi in anticipo: quali lingue al lancio, quali dopo, chi traduce. Aggiungere una seconda lingua a un progetto che non ne prevedeva una costa più che pianificarla fin dal primo giorno.

Riferimenti di Design e la Trappola del "Fallo Come X"

Le referenze sono necessarie: senza di esse un designer sta indovinando il tuo gusto, e il gusto non può essere indovinato via email. Ma come le fornisci è importante.

La trappola del "fai come X" sembra innocua e diventa costosa. Copiare il sito di qualcun altro non funzionerà per la tua azienda — prodotto, pubblico, fascia di prezzo diversi — ma il problema più profondo è che vedi un sito web dall'esterno mentre il costo si trova all'interno: dietro quell'animazione fluida potrebbero esserci tre mesi di lavoro, dietro il catalogo vivace un'integrazione di magazzino, dietro "solo belle foto" un servizio fotografico che non hai.

Da qui la regola: un riferimento senza un commento è inutile. Ogni link ha bisogno di una frase che dica cosa stai effettivamente prendendo da esso:

• "Mi piace come il prezzo è proprio lì, senza modulo di richiesta."
• "Mi piace il senso di spazio — tanto aria, poco testo per schermo."
• "Mi piace la struttura della scheda prodotto, non i colori."
• "Non mi piace affatto il carosello principale."

Le contro-riferimenti funzionano altrettanto bene: "non così, troppo aziendale" restringe la ricerca più velocemente di cinque esempi di ciò che ti piace.

Cos'altro definire

Se esiste un brand book e quanto è vincolante; tono — formale o colloquiale; e soprattutto, chi approva il design. I progetti si bloccano per le approvazioni molto più spesso che per la tecnologia, quando un mockup gira a un terzo vice direttore e torna con note che contraddicono le prime. Metti un nome nelle specifiche — il cui "sì" è finale — e concorda su un numero di giri. Due o tre è normale; illimitato non è un progetto, è un hobby.

Vincoli Tecnici, SEO e Vivere nell'Amministrazione

Questa è la sezione che i clienti saltano con "tu sai meglio." Lo studio sa meglio riguardo alle soluzioni — ma solo tu conosci i vincoli da cui parti.

Vincoli tecnici

• Hosting e dominio.Dove si trovano le cose ora, chi detiene le credenziali, se ci sono regole che governano dove possono trovarsi i dati.
• Il sistema esistente.Se un sito esiste già — cosa migra, cosa viene abbandonato, cosa continua a funzionare accanto.
• Politica interna.Revisione della sicurezza, regole delle password, restrizioni sui servizi di terze parti.
• Proprietà del codice e dati personali.Chi possiede il risultato, cosa raccogli, come viene eliminato su richiesta.

SEO

Indica i requisiti di ricerca come meccaniche, non promesse. Nessuno studio può garantire posizioni, ma ogni studio deve fornire le basi:

• Titolo, descrizione e intestazioni modificabili su ogni tipo di pagina — dall'amministratore, senza uno sviluppatore.
• Indirizzi leggibili, uno schema URL coerente e mappatura dei reindirizzamenti in fase di migrazione.
• Dati strutturati, una mappa del sito, canonici corretti e, con più lingue, attributi di lingua appropriati.
• Velocità dichiarata come metriche specifiche su un dispositivo specifico, non come "veloce."

L'amministrazione e la modifica quotidiana

La sezione più sottovalutata in qualsiasi specifica. Rispondi a una domanda:cosa cambierai tu stesso e con quale frequenza?La risposta guida l'architettura. Cambia un numero di telefono una volta all'anno e hai appena bisogno di un amministratore; assembla nuove pagine di atterraggio ogni settimana e hai bisogno di un costruttore di blocchi — un sistema e un budget diversi. Descrivi i ruoli e cosa succede quando un editore commette un errore: bozze, anteprima, ripristino. E sii onesto sulle competenze delle persone che lo utilizzeranno — un'interfaccia costruita per uno sviluppatore paralizza un editore ordinario.

Criteri di Accettazione, Tempistiche e un Intervallo di Budget

Questi tre chiudono la specifica e la trasformano da una descrizione di un sogno in un documento di lavoro.

Criteri di accettazione

Un criterio di accettazione è un'affermazione verificabile. Non "il sito funziona correttamente," ma un elenco di ciò che sarà controllato:

• Ogni pagina nell'elenco si apre; nessun link porta a un errore.
• Il modulo di richiesta viene inviato, l'email arriva e il lead appare nel CRM.
• Il sito si visualizza correttamente nei browser attuali e su un telefono.
• Le metriche di velocità sulla home page e su una scheda prodotto rientrano nella soglia concordata.
• Un pagamento con carta di prova va a buon fine, un ordine viene creato e l'email di conferma viene inviata.

Quella lista protegge entrambe le parti: il cliente sa esattamente cosa controllare e lo studio sa dove si trova il traguardo invece di affrontare una fase di accettazione che non finisce mai perché qualcosa non va.

Cronologia

Le date del calendario in una specifica sono solitamente dannose — obsolete già alla seconda settimana. Descrivi il programma in fasi: mockup dopo l'approvazione della struttura, sviluppo dopo i mockup, popolamento dopo il contenuto. La parola operativa è dipendenza. Le scadenze funzionano in entrambe le direzioni: se il contenuto arriva con tre settimane di ritardo, il lancio si sposta — è aritmetica, non punizione. Scrivi chiaramente quali scadenze appartengono al cliente: approvazione dei mockup, consegna del contenuto, concessione di accesso.

L'intervallo di budget

I clienti nascondono il budget, temendo che la stima venga adattata al numero. Il risultato è inverso. Un budget non è un prezzo — è una restrizione sul problema: se lo trattieni, otterrai o una proposta che non puoi permetterti o una ridotta oltre il riconoscimento. Un intervallo è sufficiente: "stiamo pensando in questa fascia e discuteremo di più se giustificato." Ciò che segue è una conversazione ingegneristica su cosa si adatta al quadro e cosa passa alla fase due. Per come viene effettivamente assemblato un prezzo e perché due siti che sembrano identici costano diversamente, vedi la nostra analisi di cosa costa un sito web nel 2026.

Cosa Non Mettere in un Brief

Specifiche cattive non sono solo quelle brevi — un mostro di ottanta pagine è anche un sintomo. Ecco cosa tagliare senza esitazione.

Aggettivi valutativi. Moderno, conveniente, intuitivo, ad alta conversione. Nessuno può essere verificato. Rendilo verificabile invece: piuttosto che "un catalogo conveniente," scrivi "un visitatore raggiunge il prodotto giusto in non più di tre azioni."

Soluzioni tecniche prescritte, se non sei tecnico. Una linea che dice "costruiscilo su questo stack," senza motivo, lega le mani e aumenta il prezzo. Dichiarare invece la restrizione: "il nostro sysadmin può supportare solo questo stack," o "deve funzionare sul nostro server." Lo studio onorerà il motivo e sceglierà il metodo.

Tutto, nel caso. "Il sistema dovrebbe anche consentire l'espansione futura delle funzionalità" non significa nulla, ma uno studio coscienzioso prezzerebbe un margine contro l'ignoto. Stai pagando per la nebbia.

Copia-incolla dalla specifica di qualcun altro. È dolorosamente visibile quando la specifica di una clinica cresce improvvisamente con un carrello della spesa e opzioni di consegna: ora nessuno sa quali requisiti siano reali. Anche il design in prosa e la macchina legale sono fuori — uno è compito del mockup, l'altro del contratto.

E cosa manca quasi sempre

Il rovescio della medaglia: alcune cose vengono omesse in nove specifiche su dieci e non sembrano importanti fino a quando non si accendono.

• Cosa succede dopo il lancio: chi aggiorna il sito, chi lo ripara, chi risponde a mezzanotte di sabato.
• Backup: con quale frequenza, dove si trovano, chi verifica che possano effettivamente essere ripristinati.
• Consegna: credenziali, documentazione, una guida per l'editore, file sorgente e formazione per il tuo personale.
• Cosa conta come una correzione in garanzia rispetto a un nuovo compito.

Come il Brief Diventa una Stima — e Gestire le Modifiche

Una stima non è un numero estratto dall'esperienza — è un'operazione aritmetica eseguita su un documento.

Come funziona realmente la tariffazione

Lo studio suddivide le specifiche in elementi e prezza ciascuno in ore: ogni template unico, ogni pagina templata, ogni funzionalità, ogni integrazione, l'amministrazione, i test, il lancio. In cima ci sono le cose assenti dall'elenco delle pagine ma sempre presenti — gestione, comunicazione, revisioni, accettazione. Da cui segue la parte importante: una stima è accurata solo quanto le specifiche. Da un brief puoi citare un intervallo, e sarà ampio perché è onesto. Quando un appaltatore legge un paragrafo e nomina un prezzo esatto, quello è un numero dal soffitto — e alla fine il soffitto è tuo o loro.

Confronta solo le stime scritte contro le stesse specifiche; altrimenti stai confrontando progetti diversi. La proposta economica quasi sempre descrive meno — nessun test, nessuna popolazione di contenuti, nessuna integrazione — e una riga che legge "sviluppo del sito web — totale" non può essere verificata, mentre una stima dettagliata dimostra che l'appaltatore ha letto le specifiche. I nostri ambiti di servizio sono strutturati esattamente su questa logica: struttura prima, poi funzionalità, poi accettazione.

Modifiche dopo l'approvazione

Le modifiche accadranno — le aziende si muovono, e una demo rivela sempre cose che un documento non poteva. La domanda non è come prevenirle, ma come gestirle:

1. La modifica è scritta — come voce separata, non come osservazione in una chiamata.
2. Lo studio la prezza: quante ore, cosa si muove nel programma, cosa tocca.
3. Il cliente decide: farlo ora, nella fase due, o abbandonarlo, e la decisione è registrata come un'appendice.

C'è una regola da memorizzare: una correzione è quando la costruzione non corrisponde alle specifiche; una modifica è quando le specifiche non corrispondono al bisogno.. Lo studio fissa il primo gratuitamente e prezza il secondo. La linea è tracciata da un documento piuttosto che dall'umore. E se una funzionalità viene inclusa, o qualcosa di necessario passa alla fase due o vengono aggiunti soldi. Non c'è una terza opzione.

Checklist: Il Tuo Brief È Pronto Se Ha

Scorri l'elenco. Se più di tre elementi sono vuoti, il documento non è pronto per essere prezzato — e qualsiasi stima su di esso è finzione.

1. Un obiettivo aziendale in termini aziendali, non in termini di sito web.
2. Il pubblico come comportamento: chi decide, come arriva, cosa verifica, quale dispositivo utilizza.
3. Competitori: da tre a cinque link, ciascuno con una nota su cosa prendere e cosa evitare.
4. Un elenco di pagine suddiviso in schermi unici e quelli templati.
5. Struttura di ciascuna pagina unica: blocchi dall'alto verso il basso e lo scopo di ciascuno.
6. Funzionalità come scenari: chi fa cosa e ottiene cosa. Inoltre casi limite e fallimenti.
7. Priorità: necessarie per il lancio / belle da avere / fase due.
8. Contenuto: chi scrive il testo, chi fornisce le foto, entro quando, e cosa succede se è in ritardo.
9. Integrazioni per nome: cosa si muove dove, quando, cosa in caso di errore, chi ha le credenziali.
10. Lingue: quante al lancio, chi traduce, cosa succede senza traduzione.
11. Design: riferimenti annotati, libro del marchio, chi approva, quante revisioni.
12. Vincoli tecnici: hosting, accesso, proprietà del codice, dati personali.
13. SEO: meta modificabili, schema URL, reindirizzamenti in migrazione, una soglia di velocità.
14. L'amministratore: cosa modifichi tu stesso e con quale frequenza, ruoli, bozze, ripristino, formazione.
15. Criteri di accettazione: un elenco verificabile, non "funziona correttamente."
16. Una timeline a fasi con dipendenze, e un intervallo di budget.
17. Dopo il lancio: supporto, backup, passaggio delle credenziali, il confine della garanzia.

Prima che un progetto inizi, non cercare di compilare l'intero elenco da solo in una sola sera. Compila ciò che conosci veramente: l'obiettivo, il pubblico, i concorrenti, i vincoli, l'intervallo di budget. Il resto — pagine, funzionalità, integrazioni, accettazione — si assembla durante la scoperta, insieme a uno studio.

Una buona specifica è come un disegno tecnico: un documento noioso senza il quale la casa viene costruita a occhio. Un'ora spesa nella formulazione prima dell'inizio risparmia un giorno di rifacimento nel mezzo. Se desideri che la specifica venga scritta con te e valutata onestamente rispetto ad essa, metti in contatto — iniziamo con un brief e una conversazione, e il documento tende a scriversi da solo da lì.

FAQ