Il cliente afferma di aver bisogno di un sito web. Sembra una richiesta specifica, ma non lo è. Non è ancora chiaro perché il sito web debba esistere, a chi debba servire, cosa debba cambiare all'interno dell'azienda o come faremo a sapere se ha raggiunto i suoi obiettivi. "Voglio un sito web" è l'inizio di una conversazione, non una specifica.

Il cliente non deve essere uno sviluppatore web. Conosce la sua attività, i suoi clienti e i suoi problemi, ma non ha bisogno di comprendere le interrelazioni tra contenuti, usabilità, accessibilità, prestazioni, SEO, infrastruttura e successiva manutenzione. Né dovrebbe fingere di farlo. Il compito dello sviluppatore non è convertire acriticamente ogni richiesta in codice. È comprendere l'obiettivo aziendale, tradurlo in requisiti e spiegare al cliente le implicazioni delle decisioni disponibili.

Pertanto, il colloquio preliminare non è una formalità di vendita. È la prima fase del processo di progettazione.

Il cliente descrive la soluzione, ma tu devi scoprire il problema

Ho osservato lo stesso principio molte volte: il cliente non sa ancora esattamente cosa vuole. A volte ha solo un'idea generale. A volte mostra il sito web di un concorrente e chiede un elemento simile. Altre volte, presenta un requisito molto specifico che si rivela essere un anti-pattern, ovvero una soluzione popolare o familiare che non raggiunge il suo vero scopo.

Non è colpa del cliente. Nessuno vive nella testa di un'altra persona. Finché le aspettative non vengono espresse, non possono essere soddisfatte in modo onesto. Anche un'aspettativa dichiarata deve comunque essere collegata alla domanda: "Cosa dovrebbe ottenere questo per l'utente o per l'azienda?". I metodi di service design più maturi separano anche il bisogno dalla soluzione proposta e raccomandano di comprendere prima il contesto completo dell'utente (GOV.UK, "Imparare a conoscere gli utenti e le loro esigenze").

Un cliente potrebbe dire di aver bisogno di un blog. Tuttavia, un blog è semplicemente un meccanismo per pubblicare contenuti. Non crea automaticamente competenza del marchio, traffico o vendite. Richiede contenuti di valore, lavoro sistematico e coinvolgimento del pubblico. Google afferma esplicitamente che anche il rispetto dei requisiti tecnici e delle best practice non garantisce l'indicizzazione o la visualizzazione di una pagina nei risultati di ricerca (Google Search Essentials). Raccomanda inoltre di creare contenuti utili per le persone e di informare attivamente le community di riferimento sul sito (Google, "Creare contenuti utili, affidabili e incentrati sulle persone").

Un blog ha senso quando aiuta un potenziale cliente a comprendere meglio il problema, a valutare le competenze dell'azienda e a prendere una decisione di acquisto più consapevole. Se un'azienda non intende creare o promuovere contenuti, questo dovrebbe essere specificato prima del preventivo, non mesi dopo aver lanciato una sezione "News" vuota.

Una sola intervista non è sufficiente, perché il sito è strutturato su più livelli. Suddivido l'intervista in diverse aree. Innanzitutto, è necessario comprendere le esigenze generali e determinare il tipo di implementazione: se si tratta di un semplice sito web, un sito personale, un sito aziendale, un negozio online, o se il problema richiede un'applicazione più complessa. Allo stesso tempo, è fondamentale comprendere il panorama digitale del cliente: dominio, hosting, database, email, certificato SSL, CDN e i sistemi esistenti con cui la soluzione verrà integrata.

Le fasi successive riguardano funzionalità, design, contenuti, costi e tempistiche. Ogni fase affronta una questione diversa. La funzionalità descrive cosa l'utente e l'amministratore dovrebbero essere in grado di fare. Il design combina l'interfaccia, l'esperienza utente e l'identità del marchio. I contenuti includono testo, foto, grafica, video, audio, traduzioni e la responsabilità della loro preparazione. Il budget e le tempistiche indicano cosa può essere implementato ora, cosa deve essere ridimensionato e cosa dovrebbe essere consapevolmente rimandato alla fase successiva.

Il concetto di "standard più elevati" deve essere scomposto in requisiti specifici. Il W3C sviluppa numerosi standard web e le WCAG definiscono criteri di accessibilità verificabili ai livelli A, AA e AAA (W3C, "Accessibility Standards Overview"; W3C, "WCAG 2 Overview"). Un campo "conforme al W3C" non è sufficiente. La specifica dovrebbe indicare quale standard stiamo utilizzando, quale livello di conformità stiamo adottando e come lo verificheremo. Reattività, prestazioni, sicurezza, backup, privacy e criteri di accettazione dovrebbero essere trattati in modo analogo.

Un cliente potrebbe non rendersi conto che un modulo di contatto implica obblighi relativi ai dati, messaggi post-invio, gestione degli errori e link a piè di pagina appropriati. Non dovrebbe scoprire queste dipendenze solo dopo l'implementazione. Il ruolo del processo è quello di collegare il contributo del cliente con gli elementi derivanti dalla progettazione della soluzione e dallo standard concordato.

Dopo ogni fase, non basta una semplice nota informativa, ma è necessario prendere una decisione.

Una conversazione senza un riepilogo si trasforma rapidamente in un insieme di ricordi disomogenei. Il cliente ricorda una cosa, il fornitore un'altra, e l'agente di intelligenza artificiale potrebbe riceverne una terza interpretazione. Pertanto, per ogni area dovrebbe essere creato un breve documento: una descrizione dei risultati, delle ipotesi, delle decisioni in sospeso e delle implicazioni per i costi e altri aspetti del progetto.

Il cliente riceve questo documento, fornisce commenti e conferma di aver compreso il risultato atteso. Non si tratta di fornirgli un insieme di regole da seguire. L'accettazione dovrebbe confermare una comprensione condivisa: cosa verrà fatto, cosa non verrà fatto in questa fase, quali materiali il cliente dovrà fornire e come entrambe le parti riconosceranno il risultato corretto.

Una validazione precoce non elimina tutti gli errori, ma permette di individuarli quando la modifica è ancora relativamente economica. Il Manuale di Ingegneria dei Sistemi della NASA raccomanda di validare aspettative e requisiti il ​​prima possibile e in modo iterativo, perché l'individuazione tardiva di una soluzione errata porta a ingenti rilavorazioni (NASA, "Systems Engineering Handbook"). Il sito web di una piccola azienda non è un'astronave, ma il meccanismo di errore rimane lo stesso: più tardi ci accorgiamo di aver costruito la cosa sbagliata, più lavoro dovrà essere scartato o rifatto.

I livelli approvati costituiscono le specifiche di esecuzione. Queste stesse specifiche servono a stimare il lavoro, i tempi e i costi, e diventano quindi il contesto per le persone o gli agenti che implementano il progetto. Invece di un ordine generico di "realizzare il sito web", il fornitore riceve obiettivi, funzioni, contenuti, aspetto, vincoli, standard e criteri di accettazione concordati.

La maggior parte del lavoro può essere svolta in quello che sembra essere un numero di clic.

La fase di budgeting è complessa perché il cliente vede solo il risultato finale. Potrebbe pensare che un sito web si crei con blocchi predefiniti e pochi clic. Tuttavia, anche il titolo nella prima sezione della pagina richiede una scelta ponderata. Deve ispirare fiducia, attrarre il pubblico giusto, spiegare il valore dell'offerta e integrarsi con il design complessivo. Una frase come "siamo fantastici" può essere digitata in un minuto, ma di solito non invoglia il destinatario a proseguire la lettura.

Esistono decine di elementi apparentemente insignificanti, ognuno dei quali può influenzare altre parti del sito. Pertanto, una stima affidabile non si basa sul numero di sottopagine o blocchi, bensì sul lavoro necessario per raggiungere il risultato concordato, tenendo conto delle interdipendenze e verificando che il tutto funzioni correttamente.

Una buona valutazione non ha lo scopo di garantire che nulla nel progetto cambierà mai, ma di assicurare che il cambiamento sia consapevole. Se, dopo l'avvio dell'implementazione, il cliente desidera aggiungere un negozio a un blog precedentemente pianificato, non si tratta di una semplice modifica. È una nuova fase con le sue caratteristiche, i suoi pagamenti, i suoi ordini, i suoi contenuti, i suoi rischi, i suoi costi e le sue tempistiche. Dovrebbe essere sottoposto a un colloquio separato, anche se utilizza lo stesso sito web e ha lo stesso rapporto con il cliente.

Le obiezioni del fornitore possono essere parte integrante di un buon servizio.

A volte le esigenze del cliente entrano in conflitto con i suoi obiettivi, il budget o i suoi standard di qualità. In questi casi, un professionista non dovrebbe nascondersi dietro la frase "il cliente ha sempre ragione" o imporre arbitrariamente il proprio gusto. È necessario un dialogo, che presenti entrambi i lati della questione: cosa otterrà il cliente, a cosa dovrà rinunciare, quali rischi è disposto ad accettare e quale alternativa meglio raggiunge i suoi obiettivi.

Si tratta anche di un'occasione di apprendimento. Il cliente non ha bisogno di conoscere il gergo del settore, ma deve capire per cosa sta pagando e perché la proposta viene presentata in questo modo. Solo allora potrà approvare consapevolmente una soluzione o accettare le conseguenze di una scelta diversa.

Tuttavia, non tutti i conflitti possono essere risolti. Preferisco non iniziare un progetto piuttosto che accettare denaro per un sito web che so in anticipo non soddisferà il cliente. Nel breve termine, questo significa perdere il lavoro. Nel lungo termine, protegge entrambe le parti da delusioni, conflitti e da un progetto che non vorrei presentare come opera mia.

La qualità può favorire la fiducia, le raccomandazioni e le collaborazioni future, ma non garantisce automaticamente nulla. Il mercato, la visibilità, l'offerta e l'attività successiva del cliente sono comunque fondamentali. Ecco perché non voglio vendere un sito web come una macchina magica per acquisire clienti. Posso progettare un buon strumento e spiegare onestamente come usarlo. Non posso promettere un risultato indipendente dall'intera azienda.

La definizione delle specifiche è la fine del colloquio e l'inizio della responsabilità

Il risultato del processo non è un file con le risposte del cliente. È un manuale di implementazione approvato: una combinazione di obiettivo aziendale, esigenze dei futuri utenti, requisiti del cliente, competenze del fornitore, standard, budget, tempistiche e criteri di accettazione.

Sulla base di questo, è possibile avviare le attività, redigere report di avanzamento, condurre il progetto, effettuare l'accettazione del progetto, formare il cliente e pianificare l'assistenza, gli aggiornamenti e i backup. Senza di esso, l'implementazione si basa su supposizioni. Anche con questo metodo, la sfida rimane, ma almeno sappiamo quale problema stiamo risolvendo e chi ha approvato il metodo utilizzato per raggiungere il risultato.

Il cliente dovrebbe ricevere tutto ciò che ha specificamente richiesto, così come gli elementi necessari per garantire che l'intero sistema funzioni secondo lo standard concordato. Non si tratta di aggiungere funzionalità di cui non ha bisogno. L'obiettivo è garantire che, una volta completato il progetto, il cliente non scopra di aver acquistato solo una parte del sistema senza che nessuno gli avesse comunicato le altre componenti.

Un sito web creato solo per il gusto di averne uno è inutile. Uno strumento ha senso quando il suo scopo, la sua portata e il suo utilizzo previsto sono compresi da entrambe le parti prima dell'inizio dei lavori. ## Bibliografia

✦Costruire sistemi per una maggiore autonomia.