Prima di riprogettare il tuo sito web, decidi cosa dovrebbe effettivamente cambiare

Prima di una riprogettazione, registra ciò che il sito attuale deve preservare, cosa presenta un problema documentato e come verrà controllata ogni modifica proposta. L'apparenza può motivare un’analisi, ma non dimostra che ogni parte del sito sia danneggiata.

Definisci la decisione in termini concreti: rendere comprensibile l’offerta, correggere il percorso di richiesta di contatto o organizzare le informazioni importanti. Se il problema è ancora un’ipotesi, includi l’indagine nel documento di progetto invece di presentare il design preferito come risposta dimostrata.

Per esempio, «rendere il sito più professionale» è difficile da verificare. «Spiegare cosa produce la valutazione prima del modulo di richiesta» dà al team qualcosa di concreto da preparare e controllare. Un aggiornamento visivo può essere una scelta aziendale valida; tieni questo scopo separato dalla promessa di risolvere problemi di vendite non misurati.

Annota ciò che ha dato origine al progetto: feedback, un servizio modificato, un fallimento riproducibile o una decisione di riposizionare l'azienda. Ogni motivo suggerisce un lavoro diverso. Ciò impedisce al team di progettazione di dover indovinare se l'attività riguarda principalmente la presentazione, il contenuto, la struttura o la funzionalità.

Elenca le pagine importanti, il loro scopo, i contenuti chiave e i percorsi utilizzati dai visitatori. Salva le osservazioni pertinenti con la loro pagina e il contesto. Laddove esistano dati autorizzati, registrare il periodo e le condizioni in modo che i confronti successivi abbiano una base significativa.

Includi gli URL correnti, le istruzioni di ricerca e le relazioni tra le pagine pertinenti nello stato iniziale. Si tratta di controlli da preservare e verificare nel piano di riprogettazione. Uno screenshot da solo non può catturare il comportamento del percorso, la consegna delle richieste o lo stato di indicizzazione segnalato da un motore di ricerca.

Inizia con la home page, le pagine principali dei servizi, una guida utile, i dettagli di contatto e il percorso di richiesta. Aggiungi pagine con visibilità di ricerca significativa o utilizzo aziendale noto quando il proprietario può fornire tali informazioni. Non dare per scontato che un basso numero di visite renda una pagina usa e getta: potrebbe rispondere a una domanda specialistica durante una vendita di valore.

Per ogni pagina selezionata, conserva l'indirizzo, la risposta principale, le affermazioni importanti e l'azione successiva. Salva la visualizzazione mobile dove espone un problema diverso. Se non disponi di analisi, il tuo stato iniziale può comunque descrivere accuratamente il sito Web corrente; lasciare le sue prestazioni non misurate.

• Scopo della pagina: la domanda o l'attività svolta dalla pagina.
• Materiale utile: spiegazioni, esempi, termini e informazioni di contatto da conservare.
• Viaggio: dove arrivano i lettori, cosa possono fare dopo e qualsiasi fallimento riproducibile.
• Dati del proprietario disponibili: periodo, fonte e richiesta pertinente o contesto di ricerca.
• Incognite: l'accesso o l'indagine necessari prima di una decisione di rimozione o sostituzione.

Conserva le spiegazioni utili, le prove fondate e i percorsi funzionanti, salvo che il nuovo brief giustifichi una modifica. Una sezione può avere un aspetto datato e rispondere comunque a una domanda d’acquisto importante. Registra il suo ruolo prima di eliminarla.

Distingui le prove di utilità dalla familiarità. Se un team afferma che una pagina funziona bene, chiedi quale osservazione supporta tale affermazione. Se tali prove non sono disponibili, la decisione di mantenerla può comunque essere ragionevole, ma dovrebbe rimanere un giudizio di pianificazione piuttosto che una conclusione misurata.

Una descrizione chiara del servizio non necessita di una nuova promessa semplicemente perché cambia la tipografia. Un caso rilevante dovrebbe mantenere il contesto che rende comprensibile il suo risultato. Se l'offerta cambia, rivedi sia la descrizione attuale che i suoi esempi di supporto in modo che le vecchie prove non supportino silenziosamente un servizio diverso.

Anche i contenuti di ricerca utili meritano una decisione ponderata. Registra a quali domande risponde una guida e in che modo i lettori continuano da essa. Se si sposta o viene fuso, il sostituto dovrebbe preservare la sua risposta utile e i percorsi che conducono ad essa. L'indirizzo stesso può essere importante per i collegamenti e i segnalibri esistenti.

Descrivi il problema e la conseguenza o il rischio irrisolto. Un’offerta senza una descrizione dell’ambito richiede una spiegazione confermata. Un modulo con un problema di convalida osservato richiede una correzione riproducibile. «Rendere il sito moderno» è un’istruzione troppo generica da verificare.

Mantieni visibili i diversi tipi di lavoro nel documento di progetto. Un nuovo layout non definisce le condizioni della tua attività, e un testo rivisto non ripara un invio che fallisce. I problemi possono sovrapporsi, ma il team deve sapere cosa deve risolvere ogni modifica.

Un confronto con la concorrenza può rivelare domande senza risposta, ma la presentazione di un altro sito non è la prova che copiarne il design funzionerà. Utilizza gli insight per scrivere un requisito originale basato sul tuo pubblico e sui fatti.

Chiedi quanto si estende il problema documentato. Una pagina in cui manca un risultato finale potrebbe richiedere una modifica editoriale. Un errore del modulo condiviso potrebbe richiedere una correzione comune su tutte le pagine. Un sistema di navigazione che non può ospitare i servizi attuali potrebbe richiedere lavori strutturali più ampi.

Considera le dipendenze, la manutenzione e l'aspetto. Il sito esistente può supportare i contenuti e i percorsi necessari? La squadra responsabile può mantenere il risultato? Se ogni correzione proposta richiede una soluzione alternativa, verificare se la struttura sottostante è parte del problema.

Una ricostruzione più ampia ha più senso quando è possibile nominare i vincoli che deve rimuovere. Prima di impegnarsi, confrontare il lavoro, i rischi di conservazione e i verifiche finali per una correzione mirata e una ricostruzione. Vale la pena considerare l'opzione meno estesa che soddisfa i requisiti effettivi.

Se le prove sono incomplete, indagare sulla parte che potrebbe cambiare la decisione. Ad esempio, verifica se l'errore di richiesta corrente influisce su un modulo condiviso prima di commissionare sostituzioni per ogni pagina di servizio. L'incertezza appartiene al brief piuttosto che diventare un'affermazione fiduciosa secondo cui l'intero sito deve essere sostituito.

Queste voci fittizie mostrano come un audit può restringere una riprogettazione. La colonna delle decisioni dà una direzione, mentre la colonna della verifica definisce cosa deve essere ancora vero dopo il lavoro. Una decisione di mantenimento può includere una nuova presentazione proteggendone il significato.

Usa una riga per ogni area importante. In «Pagina o area», inserisci l’indirizzo o il componente condiviso. In «Mantieni», descrivi il significato o il funzionamento da conservare; in «Cambia», indica l’attività concreta anziché una preferenza di stile. «Prova o motivo» deve spiegare perché esiste la riga.

In «Verifica dopo», indica come controllare il risultato. «Ruolo responsabile» identifica chi può fornire i fatti, effettuare la modifica o confermarne il completamento. Puoi indicare il responsabile del servizio, il redattore, il designer o lo sviluppatore senza inserire dati personali dei clienti nella scheda.

La riga riempita è un esempio illustrativo. Le righe vuote sono per le tue decisioni; iniziare con le aree che hanno maggiori probabilità di influenzare l’ambito della riprogettazione. Stampa la matrice prima di partire se ne hai bisogno di una copia. Memorizza le note solo mentre questa pagina rimane aperta e non invia un brief né implementa il lavoro.

Raggruppa attività correlate e identificare dipendenze, domande irrisolte e proprietari. Separare i controlli di conservazione obbligatori dagli esperimenti facoltativi. Un team dovrebbe essere in grado di vedere cosa necessita di una decisione prima dell'inizio della progettazione e cosa può essere controllato durante l'implementazione.

Includere la pagina corrente, il problema osservato, il materiale di supporto, la modifica proposta e il verifica finale. Aggiungi le informazioni che la riprogettazione deve preservare. Se il cambiamento suggerito è ancora un'ipotesi, di' cosa necessita di essere testato prima di considerarlo come la risposta definitiva.

Il brief immaginario riportato di seguito è volutamente ristretto. L'azienda può ancora scegliere un nuovo design visivo, ma questo requisito può essere valutato in modo indipendente. Evita di trasformare una descrizione incompleta in un'affermazione secondo cui un intero sito web ha causato una perdita di vendite.

La verifica finale deve corrispondere al requisito. Se l’attività chiarisce l’ambito, confronta il nuovo testo con i fatti approvati sul prodotto e verificane la comprensione. Se cambia un percorso, verifica la destinazione e i collegamenti pertinenti. Se modifica un modulo, usa un controllo autorizzato della compilazione, dell’invio e della ricezione.

Ricontrolla gli importanti percorsi di riferimento e le informazioni conservate sul sito pubblicato. Apri i vecchi indirizzi, segui la navigazione principale e i collegamenti correlati, controlla i termini principali del servizio e ripeti i controlli del modulo concordato su dispositivi mobili e desktop. Un'anteprima del progetto non può stabilire che il sito rilasciato si comporti allo stesso modo.

Per le pagine che devono apparire nella ricerca, chiedi allo specialista o al proprietario del sito di confrontare le impostazioni previste con le prove di indicizzazione disponibili. L’accesso pubblico è una condizione di idoneità; non dimostra l’indicizzazione effettiva. I requisiti tecnici di Google distinguono esplicitamente l’idoneità dall’indicizzazione garantita.

Conserva una breve nota del requisito, del risultato e del problema rimasto. Correggi un errore riproducibile dopo la pubblicazione prima di interpretarlo come un esperimento di marketing. Un sito riprogettato e un modulo funzionante richiedono comunque dati aziendali adeguati prima di poter affermare che le richieste qualificate sono aumentate.

Rivedi le aree modificate dopo il rilascio e rivisita il percorso più ampio quando cambiano l'offerta, il pubblico, la navigazione o il processo di richiesta. L'intervallo giusto segue il tuo scopo e la portata del cambiamento; non esiste un programma universale utile per ogni azienda.

Se confronti il comportamento in un secondo momento, mantieni le stesse definizioni e nota i cambiamenti nel traffico, nelle campagne e nei servizi. La verifica diretta chiede se la modifica richiesta funziona. La revisione delle prestazioni chiede cosa è successo agli utenti rilevanti e ai risultati aziendali. Conservateli entrambi, ma non sostituiteli l'uno con l'altro.

Un audit prima della riprogettazione aiuta a decidere cosa preservare e modificare. Un’analisi successiva verifica l’implementazione rispetto a queste decisioni e può individuare nuovi problemi. Nessuno dei due garantisce visibilità nella ricerca o crescita delle vendite.

Usa le osservazioni per definire il lavoro prima di modificare tutto il sito web. Se le domande su contenuti, ricerca e richieste di contatto si sovrappongono, un audit completo di Alytixx può aiutarti a esaminarle insieme e a rendere più chiaro il successivo documento di progetto.