Da dove comincia davvero un buon progetto?
Nelle parti precedenti siamo giunti a una conclusione importante: non progettiamo un sito semplicemente perché l'azienda vuole una "nuova pagina".
Progettiamo uno strumento che deve risolvere un problema concreto.
A volte il problema è la scarsa vendita. A volte il numero troppo basso di richieste. A volte i clienti non riescono a trovare le informazioni. Altre volte i commerciali rispondono ogni giorno alle stesse domande perché il sito non trasmette le informazioni di base. Succede anche che l'azienda sia cresciuta e il sito precedente non corrisponda più alla sua reale dimensione.
Perciò la prima fase non dovrebbe essere Photoshop, Figma o la scelta del framework.
La prima fase dovrebbe essere una conversazione.
Prima conosciamo il business
Un buon progettista UX non deve diventare esperto in ogni settore per cui lavora. Deve però comprendere abbastanza bene il business del cliente per sapere quali problemi sta cercando di risolvere.
Per questo chiediamo cose che all'inizio possono sembrare non collegate al design;
- Da dove arrivano i clienti?
- Perché scelgono proprio questa azienda?
- Perché se ne vanno?
- Cosa chiedono più spesso prima dell'acquisto?
- Com'è il processo di vendita?
- Chi si occupa delle richieste?
- Cosa succede al lead dopo l'invio del form?
- Quali prodotti sono i più importanti?
- Quali servizi hanno il maggior potenziale?
- L'azienda vuole aumentare il numero di richieste, il valore degli ordini, il numero di clienti o principalmente migliorare la propria immagine?
Solo le risposte a queste domande permettono di stabilire cosa dobbiamo effettivamente progettare.
Discovery - prima della prima mockup
Nei progetti digitali si usa spesso il termine Discovery.
È la fase di conoscenza del problema, degli utenti, degli obiettivi di business, dei vincoli e delle possibilità tecnologiche prima di iniziare il vero e proprio design e lo sviluppo.
Non è una "perdita di tempo prima di iniziare il lavoro". In un progetto ben condotto la Discovery serve a ridurre il rischio di costruire qualcosa che starà bene esteticamente ma non risolverà il problema reale.
Possiamo scoprire, per esempio, che il cliente non ha affatto bisogno di un nuovo sito.
Potrebbe aver bisogno di una migliore architettura dell'informazione.
O della semplificazione del processo d'acquisto.
O dell'integrazione del sito con il CRM.
O dell'automatizzazione della gestione delle richieste.
O di un modo completamente diverso di presentare l'offerta.
Ed è proprio per questo che a volte vale la pena fermarsi prima di iniziare la produzione.
L'UX non inizia dall'aspetto
UX, cioè User Experience, significa l'esperienza dell'utente durante l'utilizzo di un prodotto o servizio.
Nel caso di un sito web include molto più dell'aspetto dell'interfaccia.
Include anche:
- la modalità di navigazione all'interno del sito,
- la facilità di trovare informazioni,
- la chiarezza dei messaggi,
- il processo d'acquisto,
- i moduli,
- la gerarchia dei contenuti,
- la velocità di completamento delle azioni,
- la reazione del sistema alle azioni dell'utente,
- l'accessibilità,
- la sensazione di sicurezza e fiducia.
Perciò l'UX comincia prima che qualcuno disegni il primo schermo.
Prima bisogna capire cosa l'utente cerca di ottenere.
User Flow - quale percorso deve fare l'utente per arrivare all'obiettivo?
Uno degli strumenti fondamentali del design UX è il User Flow. È la descrizione del percorso che l'utente compie per svolgere un certo compito.
Ad esempio, in un negozio può essere: pubblicità → pagina prodotto → scelta variante → carrello → spedizione → pagamento → conferma ordine.
In un'azienda di servizi: Google → pagina servizio → realizzazioni → referenze → form → contatto con il commerciale.
Nel caso di un produttore: motore di ricerca → prodotto → parametri tecnici → documentazione → richiesta offerta.
Ognuno di questi percorsi richiede decisioni progettuali diverse.
Se l'obiettivo principale dell'utente è acquistare, non possiamo costringerlo a leggere decine di schermate di testo. Se invece il prodotto è costoso, complesso e richiede una consulenza, indirizzarlo troppo velocemente al form può essere sbagliato.
Parte dell'UX consiste nel trovare il giusto livello di accompagnamento dell'utente.
Wireframe - prima di "abbellire"
La fase successiva può essere il wireframe, uno schema semplificato dello schermo che mostra la disposizione dei contenuti e delle funzioni.
Il wireframe non deve essere bello. E va bene così. In questa fase non si tratta di scegliere il colore del pulsante.
Si tratta di rispondere a domande:
- Cosa vedrà l'utente per primo?
- Cosa sarà più importante?
- Cosa dovrebbe stare più in alto?
- Dove posizioneremo le informazioni aggiuntive?
- Come l'utente passerà al passo successivo?
- Cosa succederà al clic?
È un po' come progettare un appartamento.
Prima decidiamo dove saranno muri, porte e stanze. Solo dopo scegliamo il colore delle pareti.
Design system - per evitare che il progetto sia un assemblaggio casuale di elementi
Nei progetti più grandi compare un altro elemento importante: il Design System.
È un insieme ordinato di regole, componenti e pattern che definiscono il modo di costruire l'interfaccia.
Può includere, tra l'altro:
- colori,
- tipografia,
- pulsanti,
- moduli,
- card,
- tabelle,
- messaggi,
- icone,
- spaziature,
- regole di responsive,
- comportamento dei componenti.
Perché? - Per rendere l'interfaccia coerente.
Se in una sottopagina un pulsante si comporta in un modo e in un'altra in modo completamente diverso, l'utente deve imparare l'interfaccia ogni volta da capo.
Il Design System aiuta anche il team di sviluppo. Invece di ricostruire il componente da zero ogni volta, può usare elementi già definiti.
Questo si traduce in maggiore coerenza, sviluppo più semplice e spesso anche costi di manutenzione più bassi.
E la tecnologia dove sta in tutto questo?
La tecnologia dovrebbe entrare in scena in tempo utile, ma non dovrebbe dettare l'intero progetto. È una distinzione importante.
Il progettista può inventare una funzione ottima dal punto di vista del business. Lo sviluppatore però può notare che la sua implementazione sarebbe molto costosa o creerebbe problemi di performance.
D'altra parte lo sviluppatore può proporre una soluzione tecnologica comoda da realizzare, ma che dal punto di vista dell'utente non risolve sufficientemente il problema.
Per questo i migliori progetti nascono dove UX, design, sviluppo e business parlano tra loro fin dall'inizio.
Non con la logica: "prima i designer, poi i developer".
Ma: "Riflettiamo insieme su come risolvere al meglio il problema".
La tecnologia non dovrebbe essere scelta perché è di moda
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, app native, PWA... si possono elencare molte tecnologie.
Il cliente però non compra tecnologia. Compra una soluzione.
Quindi la domanda: "Quale framework useremo?"
spesso è molto meno rilevante di: "Quali problemi deve risolvere il sistema?" Solo dopo si può scegliere l'architettura adeguata.
Una semplice pagina aziendale ha esigenze diverse rispetto a un negozio che gestisce migliaia di ordini, e ancora diverse da una piattaforma B2B con integrazioni complesse e permessi utente personalizzati.
La tecnologia dovrebbe derivare dai requisiti, non i requisiti dalla tecnologia.
Backend, frontend e la parte che l'utente non vede
È utile ricordare che un sito web non è solo ciò che vediamo nel browser.
Frontend è la parte con cui l'utente interagisce direttamente.
Backend è la logica lato server: elaborazione dei dati, comunicazione con il database, gestione dei processi e integrazioni.
E tra loro spesso ci sono molti elementi aggiuntivi;
- CRM.
- ERP.
- Gateway di pagamento.
- Piattaforma di mailing.
- Sistema di magazzino.
- API.
- Analytics.
- Automazioni.
- Sistema di assistenza clienti.
Se progettiamo un nuovo sito senza considerare questo ecosistema, possiamo creare un bel frontend che funzionerà come un'isola solitaria.
E l'obiettivo dovrebbe essere tutt'altro.
Un buon sito può fare molto più che "raccogliere form"
Un sito moderno può essere parte di un processo aziendale più ampio;
- L'utente invia una richiesta.
- Il sistema riconosce l'argomento.
- Il lead arriva al CRM.
- Il commerciale riceve una notifica.
- Il cliente riceve una conferma automatica.
- I dati vengono assegnati alla categoria corretta.
- Il sistema può verificare la disponibilità del prodotto.
- Può preparare informazioni per il commerciale.
- Può avviare un determinato workflow.
In un e‑commerce l'ordine può automaticamente passare attraverso le fasi di evasione. In un B2B il cliente può avere accesso a prezzi individuali, documenti e storico ordini.
A quel punto il sito smette di essere una "vetrina". Diventa parte dell'infrastruttura aziendale.
E l'AI?
L'AI può far parte di tale sistema. Ma, di nuovo, non va aggiunta solo perché "tutti oggi hanno AI".
Se un chatbot non risolve alcun problema reale, sarà solo un'altra finestra sul sito.
Se invece l'utente può grazie all'AI trovare più rapidamente il prodotto giusto, configurare un servizio, ottenere una risposta o attraversare il processo di scelta, allora la tecnologia ha una giustificazione.
Lo stesso vale per la personalizzazione.
Possiamo mostrare contenuti diversi a seconda del comportamento dell'utente, della sorgente di ingresso o della fase del processo d'acquisto. Possiamo analizzare i dati e prevedere meglio i bisogni dei clienti.
Ma dobbiamo sempre partire dalla domanda: "Quale problema stiamo risolvendo?"
Solo dopo: "L'AI è il modo migliore per risolverlo?"
Testiamo non solo se funziona
Uno degli errori più comuni è testare il sito solo alla fine. Allora scopriamo che il form è troppo lungo, il processo d'acquisto è poco intuitivo e l'utente non trova le informazioni più importanti.
Più tardi scopriamo il problema, più costosa sarà la sua correzione.
Perciò conviene testare il progetto a tappe. Possiamo verificare il prototipo. Possiamo osservare il comportamento degli utenti. Possiamo condurre test di usabilità. Possiamo analizzare i dati di Google Analytics o di altri strumenti analitici. Possiamo utilizzare registrazioni di sessione o mappe di calore, se implementate nel rispetto della privacy. Possiamo anche semplicemente parlare con i commerciali.
Quest'ultimo viene spesso sottovalutato.
Il commerciale ogni giorno sente le domande dei clienti; sa cosa non capiscono. Sa cosa li preoccupa. Sa quali informazioni vanno comunicate prima dell'acquisto.
Questa è una enorme conoscenza progettuale.
MVP non significa qualsiasi cosa
Nei progetti digitali spesso si parla di MVP - Minimum Viable Product.
Si tratta della prima versione del prodotto con il set minimo di funzionalità necessario per verificare le ipotesi e fornire valore agli utenti.
MVP non dovrebbe significare: "Facciamo qualcosa alla buona e poi vediamo".
Un buon MVP dovrebbe rispondere alla domanda: "Qual è la versione più piccola della soluzione che ci permetta di verificare se stiamo andando nella direzione giusta?"
Questo è molto importante anche per siti e applicazioni.
Invece di costruire subito trenta funzionalità, a volte è meglio lanciare le cinque più importanti e verificare come gli utenti le usano. Poi si sviluppa il sistema basandosi sui dati reali e non solo sulle ipotesi del primo incontro.
Il sito non finisce il giorno della pubblicazione
Questa è un'altra cosa che spesso dimentichiamo.
Il momento della pubblicazione è in realtà l'inizio della sua vita vera. Solo allora arrivano utenti reali. Solo allora vediamo quali contenuti funzionano. Solo allora capiamo quali elementi vengono ignorati. Solo allora possiamo vedere se sono aumentate le richieste, le vendite, il tempo speso sul sito o altri indicatori che avevamo definito in precedenza.
Perciò il progetto dovrebbe essere sviluppato continuamente;
- Analisi.
- Conclusioni.
- Cambiamento.
- Test.
- Nuova analisi.
Somiglia più a un ciclo che a un evento unico.
Cosa dovrebbe essere misurato?
Dipende dall'obiettivo del progetto.
Per un negozio online possono essere:
- tasso di conversione,
- valore medio dell'ordine,
- abbandoni del carrello,
- fatturato,
- valore del cliente nel tempo.
Per un'azienda di servizi:
- numero di lead di valore,
- tasso di conversione del form,
- numero di consulenze fissate,
- costo per acquisizione del lead,
- qualità delle richieste.
Per un sito informativo:
- trovare informazioni specifiche,
- engagement degli utenti,
- numero di ritorni,
- download di materiali.
Non tutto va misurato. Bisogna però sapere cosa è importante.
Perché se l'azienda vuole aumentare il numero di richieste di valore, aumentare il traffico non significa necessariamente successo. Possiamo avere dieci volte più visite e nessun cliente in più.
L'errore più grande? Progettare senza rispondere alla domanda "perché?"
Si può creare un sito visivamente eccellente.
Si può adottare uno stack tecnologico moderno.
Si possono preparare animazioni perfette.
Si può curare ogni pixel.
Eppure il progetto può non portare i risultati attesi al business. - Perché?
Perché è mancata la risposta alla domanda più importante: Perché facciamo tutto questo?
Se la risposta è: "Perché il sito vecchio è brutto",
è un po' poco.
Se invece la risposta è: "Vogliamo aumentare il numero di richieste dai clienti B2B, ridurre il tempo per arrivare al servizio giusto e alleggerire il reparto vendite dalle risposte a domande ripetitive",
allora abbiamo un problema concreto da risolvere.
E possiamo progettare una soluzione.
In Web24 non vogliamo solo consegnare siti
È la differenza tra eseguire un incarico e collaborare tecnologicamente.
Se il cliente arriva con un'idea precisa, non significa che il nostro compito sia realizzarla acriticamente.
Il nostro compito è anche dire: "Ha senso".
O: "Si può fare meglio".
O: "Tecnicamente possiamo costruirlo, ma non vediamo una giustificazione di business".
O: "Prima di farlo, verifichiamo se gli utenti ne hanno davvero bisogno".
A volte la miglior decisione è aggiungere una funzione. A volte è rimuoverla. A volte è cambiare completamente le ipotesi di base.
Ed è proprio qui che entra l'esperienza del team: non nel fatto che possiamo costruire tutto, ma nel saper riconoscere cosa vale davvero la pena costruire.
Non ci sono due progetti uguali
Torniamo al punto di partenza.
Possiamo avere due clienti dello stesso settore. Due produttori. Due negozi. Due studi legali. Due software house.
I loro siti possono sembrare simili. Ma non dovrebbero essere identici solo perché operano nella stessa categoria.
Li differenziano le persone. La strategia. Il processo di vendita. L'offerta. Il budget. La tecnologia. I clienti. Gli obiettivi.
Ecco perché ogni progetto richiede decisioni proprie.
Non sempre spettacolari. Non sempre rivoluzionarie. Ma consapevoli.
Il sito come strumento, non come decorazione
Un sito ben progettato dovrebbe essere per l'azienda qualcosa di più di un biglietto da visita digitale.
Dovrebbe aiutare l'utente a prendere una decisione. Facilitare la vendita. Rispondere alle domande. Costruire fiducia. Supportare i dipendenti. Integrarsi con altri sistemi quando ha senso.
E soprattutto dovrebbe realizzare un obiettivo di business concreto.
Perciò non esiste una risposta unica alla domanda: "Com'è fatto un buon sito?"
Meglio chiedersi: "Come deve lavorare il sito di questa specifica azienda per aiutarla a raggiungere i propri obiettivi?"
Ed è da questa domanda che dovrebbe partire ogni buon progetto.
In conclusione - la regola più importante
Non progettiamo il sito affinché il cliente possa dire: "Che bello".
Lo progettiamo affinché dopo alcuni mesi il cliente possa dire: "Questo ci aiuta davvero a fare business".
Perché la differenza tra una pagina bella e un buon prodotto digitale spesso non è visibile nella prima schermata.
Si vede nei risultati.
Riassunto dell'intera serie
In questa serie abbiamo esaminato perché non progettiamo due siti uguali.
Siamo partiti da un assunto semplice: stesso settore non significa stesso business.
Poi abbiamo mostrato come strategia aziendale, processo di vendita, target e bisogni degli utenti influenzino UX, architettura dell'informazione e funzionalità.
Nell'ultima parte abbiamo percorso il processo progettuale - dalla Discovery e conoscenza del business, passando per User Flow, wireframe e Design System, fino a tecnologia, integrazioni, test, analytics e sviluppo continuo.
Perché un progetto su misura non significa solo "un aspetto diverso".
Significa decisioni diverse nate da problemi diversi.
Ecco perché ogni azienda dovrebbe ricevere una soluzione progettata per lei, non per la "media delle aziende del settore".
