Come scrivere un brief per il redesign di un sito web passo dopo passo

Quando un brief di redesign è il documento giusto

Un brief di redesign non è un modulo di raccolta generale. Esiste per un sito che già funziona in alcuni modi e fallisce in altri, e il brief deve descrivere il cambiamento, non solo il desiderio. Se il team sta sistemando un sito web aziendale di 40 pagine, una landing page o un portale prodotto, il brief dovrebbe indicare cosa deve cambiare e cosa deve rimanere invariato.

Questo è importante perché il lavoro di redesign inizia con una realtà ereditata. Esiste già una mappa del sito, testi vecchi, codice di tracciamento, moduli e un CMS con abitudini consolidate. Un buon brief dice a un designer o a un'agenzia dove si trova il problema, quali parti sono stabili e quali parti sono pericolose da toccare senza un piano.

Pensalo come un documento di gestione del cambiamento. Sembra noioso, ma mantiene tutti onesti. Un freelance può valutare meglio il lavoro, un team interno può evitare di indovinare e il lato cliente può smettere di trattare ogni vecchia pagina come una tela bianca.

Se stai cercando di capire come scrivere un brief per un sito web per un progetto di redesign passo dopo passo, inizia decidendo che il brief è per una trasformazione, non per una scoperta da zero. Quella decisione cambia le domande che fai e i dettagli che raccogli.

Esegui un audit del sito attuale prima di scrivere qualsiasi cosa

Inizia con il sito attivo. Non screenshot dell'ultimo trimestre. Non un ricordo del “problema della homepage.” Apri le pagine attuali e annota cosa esiste, cosa è rotto e cosa nessuno dovrebbe dimenticare durante il redesign.

Fai un audit semplice con i numeri. Conta le pagine che rimarranno, le pagine che cambieranno e le pagine che verranno rimosse. Nota qualsiasi pagina con un forte traffico, qualsiasi modulo con abbandoni, qualsiasi sezione che confonde gli utenti e qualsiasi contenuto che è obsoleto da un anno o più.

Anche i vincoli tecnici appartengono a questo punto. Se il sito attuale dipende da un CMS legacy, da un flusso di checkout personalizzato o da un'integrazione fragile, il brief dovrebbe menzionarlo prima che qualcuno disegni un nuovo layout. Un redesign che ignora il sistema attuale spesso crea un secondo progetto: controllo dei danni.

Includi problemi concreti degli utenti. Ad esempio: i ticket di supporto menzionano problemi di ricerca su mobile; le vendite dicono che la pagina dei prezzi causa chiamate ripetute; il team editoriale non può aggiornare le FAQ senza l'aiuto degli sviluppatori. Quei dettagli sono migliori di affermazioni generali come “il sito è difficile da usare.”

Se hai già documentazione interna, collegala. Un team che gestisce una sicurezza del sito web revisione o una configurazione di tracciamento potrebbe già sapere dove si trovano i rischi attuali, e questo può far risparmiare ore in seguito.

Definisci i confini del redesign e gli obiettivi non inclusi

I brief di redesign falliscono quando l'ambito rimane vago. Scrivi cosa è incluso nell'ambito in termini semplici, poi scrivi cosa non è incluso. La seconda lista è importante quanto la prima, perché impedisce al team di deviare verso template extra, funzionalità extra e cicli di approvazione extra.

Sii specifico riguardo ai confini. Se la homepage, le pagine dei prodotti e il flusso di contatto sono inclusi, dillo. Se l'archivio del blog, le versioni linguistiche o l'area account non fanno parte di questa fase, dillo anche. Un redesign può toccare 12 template senza toccare l'intero sistema.

I non-obiettivi non sono un segno di pigrizia. Sono una protezione. Se la pulizia dei contenuti SEO è fuori ambito, dillo. Se la nuova fotografia non è inclusa, dillo. Se il redesign deve mantenere lo stesso fornitore di checkout, scrivilo chiaramente così nessuno propone una sostituzione nella settimana 3.

Una frase utile in un brief di redesign è: “Mantieni intatto il flusso di pagamento attuale.” Un'altra è: “Non cambiare il dashboard del cliente in questa fase.” Semplice. Diretto. Difficile da fraintendere.

Cattura il contesto aziendale, del marchio e degli utenti

Il brief di redesign ha bisogno di contesto, ma non di un manifesto del marchio. Riassumi il motivo commerciale in un breve blocco: obiettivi di fatturato, qualità dei lead, carico di supporto, esigenze di reclutamento o un lancio in un nuovo mercato. Se il redesign supporta una fusione, un rebranding o un passaggio da B2B a B2B2C, nomina il fatto.

Il contesto del marchio dovrebbe includere le parti che sono cambiate. Forse l'azienda è ora più orientata verso le imprese. Forse il tono è passato da giocoso a esperto. Forse il sistema visivo deve apparire più calmo perché il vecchio design sembrava troppo promozionale. Questi sono dettagli utili. “Moderno” non lo è.

Il contesto utente dovrebbe riflettere cambiamenti reali, non assunzioni. Se il pubblico è diventato più orientato verso il mobile, ciò cambia modelli e navigazione. Se i clienti di ritorno ora hanno bisogno di accesso all'account più velocemente rispetto ai visitatori per la prima volta che necessitano di istruzioni, la homepage, i menu e la dashboard dovrebbero riflettere quella gerarchia.

Una frase può fare molto qui: “Il redesign deve supportare tre pubblici—nuovi contatti, clienti esistenti e partner—senza far gravare tutta la responsabilità sulla homepage.” Questo dà al team un problema di design che possono risolvere, il che è meglio che consegnare loro uno slogan.

Per un progetto più grande, potrebbe essere utile fare riferimento a un progetto correlato sito web aziendaleesempio di struttura o di un sito di un'unità aziendale esistente in modo che il team comprenda come l'organizzazione si presenta già.

Specifica le esigenze a livello di pagina e la struttura del sito

Un brief di redesign non dovrebbe fermarsi a "nuova navigazione". Dovrebbe nominare la struttura del sito, i principali modelli e le pagine che necessitano di attenzione speciale. Inizia con un elenco della mappa del sito, anche se è approssimativa. Poi contrassegna prima le pagine prioritarie.

Ad esempio, un sito di 20 pagine potrebbe aver bisogno di una nuova homepage, due modelli di servizio, un layout per casi studio, un hub di risorse e una pagina di contatto con un modulo diverso. Un'azienda di prodotti potrebbe aver bisogno di una pagina di prezzi, di una pagina di confronto e di un flusso di registrazione per la prova. Un editore potrebbe aver bisogno di filtri per archivi e modelli di articoli con percorsi di lettura più forti.

Dì al team quali tipi di pagina sono ripetibili e quali sono eccezioni. Se il modello del blog può gestire 500 articoli ma il modello del caso studio necessita di narrazione personalizzata, scrivilo. Se la navigazione dovrebbe mostrare solo le prime 6 sezioni, dillo. I numeri aiutano qui.

Questo è anche il posto per i cambiamenti nella gerarchia dei contenuti. Una pagina può mantenere le stesse informazioni ma necessitare di un ordine diverso: prova prima, caratteristiche seconde, processo terzo, FAQ ultime. Questo tipo di indicazione previene che un redesign diventi uno scambio cosmetico con la stessa vecchia struttura sottostante.

Alcuni team abbozzano questo contro un piattaforma di analisi e monitoraggio del sito web o una mappa dei contenuti interna in modo da poter vedere quali pagine già portano il carico e quali sono sottoutilizzate.

Nota la migrazione dei contenuti, le approvazioni e la proprietà

La migrazione dei contenuti è dove i redesign diventano disordinati. Un brief dovrebbe indicare quali contenuti si spostano così come sono, quali vengono riscritti, quali vengono archiviati e quali devono essere creati da zero. Se ci sono 86 articoli vecchi e solo 20 dovrebbero migrare, dillo chiaramente.

La proprietà è altrettanto importante. Chi scrive il nuovo testo? Chi controlla il linguaggio legale? Chi approva il titolo della homepage? Se 4 persone approvano una pagina, il programma ne risentirà. Un brief dovrebbe nominare il proprietario per ogni passaggio, non solo per l'approvazione finale.

Le approvazioni visive necessitano della stessa attenzione. Il responsabile marketing può approvare il tono, il responsabile prodotto può approvare l'accuratezza delle caratteristiche e il fondatore può voler dare un'ultima occhiata al messaggio di alto livello. Va bene, purché il brief elenchi l'ordine. Altrimenti, il designer finisce per rivedere la stessa pagina tre volte per tre opinioni diverse.

La proprietà degli asset è pratica. Dì chi fornisce immagini, icone, diagrammi, testimonianze e video. Se il redesign dipende da 12 screenshot di prodotto e non sono pronti, questo è un rischio per il programma, non un piccolo dettaglio.

Elenca i requisiti tecnici, di accessibilità e di integrazione

Note tecniche appartengono al brief, anche se il designer non sta codificando tutto. Indica il CMS, la situazione di hosting, gli strumenti per i moduli, la configurazione dell'analitica e qualsiasi sistema a cui il redesign deve connettersi. Se il sito utilizza una sincronizzazione CRM personalizzata o uno strumento di fatturazione, il redesign non può ignorarlo.

I requisiti di accessibilità devono essere concreti. Menziona la navigazione da tastiera, il contrasto dei colori, le etichette dei moduli, gli stati di messa a fuoco, i sottotitoli e la compatibilità con i lettori di schermo dove pertinente. Se l'azienda ha uno standard formale, citalo. In caso contrario, chiedi al team di seguire le linee guida di accessibilità riconosciute e segnala eventuali pagine che potrebbero necessitare di ulteriore attenzione.

La SEO appartiene anche a questo punto, e non come un pensiero secondario. Il brief dovrebbe richiedere la gestione dei reindirizzamenti, i metadati preservati dove necessario e un piano per le pagine che vengono rinominate o rimosse. Una cattiva mappa di reindirizzamento può costare traffico per settimane.

Se il tuo team ha uno stack personalizzato o una configurazione privata, indicarlo. Un redesign per un infrastruttura di rete privata è molto diverso da un sito di brochure pubblico, e il brief deve riflettere quella restrizione prima che le idee di design inizino a moltiplicarsi.

I requisiti di test meritano di essere annotati. Indica se il team dovrebbe testare su 3 browser o 5, se i punti di interruzione mobile sono fissi o flessibili, e se il passaggio finale necessita di note QA documentate. Quei dettagli risparmiano tempo durante la settimana di lancio.

Aggiungi criteri decisionali e domande sui prossimi passi per il team

Un brief di redesign non dovrebbe finire con “si prega di proporre idee.” Dovrebbe chiedere al team di rispondere a domande specifiche. Quale approccio concettuale si adatta al problema attuale del sito? Quali rischi vedono? Cosa necessita di ulteriore scoperta? Quali pagine dovrebbero essere affrontate per prime e quali possono aspettare?

Chiedi stime in intervalli se è così che lavora il team. Chiedi dipendenze. Chiedi quali assunzioni contano di più. Un brief forte invita l'agenzia o il designer interno a rispondere con i pezzi mancanti, non solo con un mood board e un bel PDF.

Questa sezione può anche definire i criteri decisionali. Ad esempio: dare priorità alla chiarezza rispetto alla novità visiva, o dare priorità alla conversione sulla pagina di contatto rispetto alla decorazione sulla homepage. Se il brief dice che il redesign non deve rallentare le prestazioni della pagina di più di un limite dichiarato, il team sa quale compromesso conta di più. I numeri mantengono la discussione ancorata.

Buone domande sui prossimi passi includono: Quali template necessitano di test di prototipo? Quali aree di contenuto necessitano di un workshop di copy? Cosa può essere riutilizzato dal sistema di design attuale? Dove si trova il rischio di lancio più grande? Queste domande aiutano il team a passare dal brief al piano senza fingere che ogni incognita sia risolta.

Alcuni team chiedono anche un riferimento a scegliere un CMS se la scelta della piattaforma è ancora aperta, perché le restrizioni della piattaforma possono cambiare layout, flusso di editing e persino l'ambito del redesign stesso.

E se il brief influenzerà il supporto al lancio, aggiungi una riga su cosa succede dopo il go-live. Un redesign che cambia URL, moduli o integrazioni spesso necessita di supporto al sito web dopo il lancio per alcune settimane, non di un passaggio di un giorno.

Prima di inviare il brief, leggilo come se il team non avesse mai visto il sito. Se manca un conteggio delle pagine, se un non-obiettivo è vago, se un proprietario di approvazione non è nominato, sistemalo ora. Questa è la differenza tra un brief di redesign che guida il lavoro e uno che inizia solo una riunione.