C’è un momento nella vita di ogni designer in cui un cliente ti chiede un sito web con un budget che a malapena coprirebbe una cena per due da Cracco. E tu, invece di scappare urlando, accetti. Perché sei un professionista. O forse perché l’affitto non si paga da solo e il tuo conto in banca è più asciutto della pizza surgelata che hai dimenticato in forno.
Ma ecco la verità che nessuno ti dice: fare web design con budget risicati non significa fare web design di merda. Significa essere creativi in un modo diverso. È come cucinare con gli avanzi del frigo: puoi fare un pastone disgustoso, oppure puoi tirare fuori un piatto che farebbe piangere Carlo Cracco di commozione. Dipende tutto da come approcci la cosa.
Il doppio approccio: quando devi essere sia ingegnere che artista
Il segreto dei piccoli progetti web che funzionano davvero sta in un approccio che io chiamo “il metodo Jekyll e Hyde del web design”. Da una parte devi essere il Dr. Jekyll della UX: metodico, razionale, ossessionato dalla funzionalità. Dall’altra devi liberare il Mr. Hyde creativo: quello che vuole stupire, emozionare, far dire al visitatore “cazzo, questo sito è figo”.
Il punto è questo: un sito che stupisce è un sito che diventa memorabile. E un sito memorabile è un sito che funziona meglio. È matematica, non magia. Se il tuo sito è indistinguibile dalla massa di template WordPress che popolano internet come erbacce in un giardino abbandonato, congratulazioni: hai appena creato l’equivalente digitale di un volantino per la sagra del cinghiale.
Step 1: capire cosa diavolo deve fare ‘sto sito
Prima di aprire Figma, prima di pensare ai colori, prima di tutto: siediti col cliente e cerca di capire cosa gli serve. Sembra banale, vero? Eppure il 90% dei disastri nel web design nasce da questo momento saltato a piè pari.
L’incontro col cliente è come il primo appuntamento: devi fare le domande giuste senza sembrare un interrogatore della CIA. Cosa deve fare il sito? Chi lo userà? Quali sono gli obiettivi? Se il cliente ti risponde “voglio un sito bello”, preparati a scavare più a fondo. “Bello” non significa niente. Bello come? Bello tipo Apple? Bello tipo MySpace nel 2006? Bello tipo il sito del comune del tuo paese fatto dal nipote del sindaco?
La chiave è uscire da questi incontri con una lista chiara di funzionalità e una comprensione di chi saranno gli utenti. Sì, lo so che “user persona” suona come una roba da presentazione PowerPoint noiosa, ma fidati: sapere se il tuo utente tipo è un pensionato che cerca informazioni sulla bocciofila o un ventenne che vuole prenotare un taglio di capelli cambia completamente l’approccio.
Step 2: UX research per poveri (ma dignitosi)
Ora, in un mondo ideale, a questo punto faresti una bella UX research con focus group, interviste, analisi comportamentali e tutto l’ambaradan. Peccato che il budget del tuo progetto sia quello che è, e il cliente ti guarderebbe come se avessi appena proposto di sacrificare una capra in suo onore.
Ma ecco il plot twist: puoi fare UX research anche a budget zero. Come? Con un po’ di creatività e zero vergogna.
Google Analytics e Search Console: Se il cliente ha già un sito (anche se fa schifo), questi strumenti gratuiti sono una miniera d’oro. Scopri da dove arriva il traffico, quali pagine vengono visitate di più, dove la gente abbandona il sito come un ex tossico che abbandona le cattive abitudini. Questi dati valgono oro.
Hotjar (versione free): Ti mostra dove la gente clicca, fin dove scrolla, dove si incazza e chiude tutto. È come avere le telecamere di sorveglianza, ma per il tuo sito e senza violare alcuna legge a patto che la gente clicchi “Accetta tutti i cookie”.
Test con persone che conosci: Sì, lo so, non è scientifico. Ma far testare il sito alla zia, al vicino di casa, al barista sotto casa è comunque meglio che non testarlo affatto. L’importante è scegliere persone che siano simili al target reale, non tua nonna se stai facendo il sito per una discoteca techno.
Analisi della concorrenza: Gratis e illuminante. Vai sui siti dei competitor del tuo cliente e guardali con occhio critico. Cosa funziona? Cosa fa schifo? Cosa puoi fare meglio? È come copiare i compiti del secchione, ma in modo creativo.
Step 3: il carattere prima del wireframe (ovvero: fare le cose al contrario funziona)
E qui arriva la parte che mi fa sentire un ribelle del web design: prima di fare il wireframe, io faccio il progetto creativo. Sì, lo so, va contro ogni manuale di UX design mai scritto. Ma sentitemi.
Il wireframe è uno strumento fantastico, non fraintendetemi. Ma se lo fai troppo presto, rischi di imprigionarti in una struttura che poi dovrai forzare per farci entrare la creatività. È come scrivere la sceneggiatura di un film e poi cercare di renderlo visivamente interessante: funziona, ma stai lavorando con le mani legate.
Invece, prova a capire prima il carattere del sito. Che personalità deve avere? È serio e professionale come un avvocato in tribunale? È scanzonato e amichevole come il tuo amico che ti consiglia i ristoranti? È minimalista e zen come un monaco buddista con un MacBook?
Questo carattere influenzerà non solo i colori e i font (che è la roba facile), ma anche la struttura stessa del sito. Pensateci: la forma segue la funzione, certo, ma nei progetti migliori la forma E la funzione si influenzano a vicenda.
Il metodo Nolan: quando la struttura diventa contenuto
Permettetemi un paragone nerd che probabilmente vi farà alzare gli occhi al cielo: pensate ai film di Christopher Nolan. In “Memento” la struttura narrativa frammentata non è un vezzo stilistico: È il film stesso. Ti fa sentire confuso come il protagonista. In “Dunkirk” le tre linee temporali che si intrecciano non sono solo un modo figo di montare: creano la tensione e il senso di caos della guerra.
Ecco, nel web design dovrebbe funzionare allo stesso modo. La struttura del tuo sito non è solo un contenitore per le informazioni: può diventare parte dell’esperienza. Un sito per un musicista potrebbe avere una navigazione che ricorda uno spartito. Un sito per un’azienda di logistica potrebbe visualizzare le informazioni come un percorso di spedizione. Un sito per un ristorante potrebbe essere strutturato come un menu degustazione.
Non sto dicendo di fare cose assurde e inutilizzabili. Sto dicendo che prima di buttarti sul wireframe standard con header-hero-servizi-chi siamo-contatti, chiediti: c’è un modo in cui la struttura stessa può raccontare qualcosa del brand?
Step 4: lo schema delle pagine (o direttamente il prototipo)
Ok, a questo punto hai:
- Una lista di funzionalità necessarie
- Dei dati (anche approssimativi) su come gli utenti si comportano
- Un’idea chiara del carattere del sito
Ora puoi fare uno schema rapido delle pagine o, se ti senti temerario, buttarti direttamente sul prototipo grafico. In progetti piccoli, onestamente, spesso il wireframe dettagliato è uno step che puoi saltare. Non hai il budget per fare tre round di revisione su wireframe E tre round su design. Sii pragmatico.
Questo è il momento in cui devi fare lo sforzo di stupire, ma anche di essere utile. E qui c’è un punto fondamentale che molti dimenticano: nei piccoli progetti, le funzionalità sono spesso basilari. Non stai costruendo il prossimo Amazon. Stai facendo un sito per un idraulico che vuole essere trovato su Google e avere un numero di telefono ben visibile.
Quindi dove puoi fare la differenza? Nei contenuti e in come li presenti. Un sito per un idraulico può essere noioso come un manuale di istruzioni, oppure può avere personalità, raccontare una storia, far sorridere il visitatore. Indovina quale verrà ricordato.
Il nemico pubblico numero uno: Lorem Ipsum
E arriviamo al mio consiglio più importante, quello che vorrei tatuarmi sulla fronte per ricordarmelo ogni volta che mi guardo allo specchio: quando crei il prototipo su Figma (o sul compianto Adobe XD, RIP), cerca di farlo sembrare VERO.
Il Lorem Ipsum è il male. È quella scorciatoia che tutti prendiamo e che poi ci fotte sistematicamente. Perché quando presenti al cliente un mockup pieno di testo finto, lui non riesce a capire come sarà davvero il sito. E tu non riesci a capire se il layout funziona davvero con contenuti reali.
Scrivi contenuti verosimili. Usa foto reali (anche se stock). Metti numeri di telefono inventati ma credibili. Scrivi testi che potrebbero essere quelli finali, anche se poi verranno riscritti. Questo ti costringe a pensare davvero a come le informazioni si presentano, e al cliente permette di visualizzare il risultato finale.
È più fatica? Sì. Ma è quella fatica che fa la differenza tra un sito che sembra progettato e un sito che sembra… beh, un template riempito con Lorem Ipsum.
Bonus: altre cose che ho imparato sbagliando
Mobile first, ma per davvero: Non progettare il desktop e poi adattare al mobile. Il 70% del traffico web è mobile. Parti da lì. Lo sai perché non vuoi farlo? Perché i siti su mobile sono tutti uguali e fanno cagare. E invece su desktop sono fighi. Questa è l’unica verità che nessuno ti dirà, tranne io. Guarda il 90% dei template di Themeforest o dei siti che vincono persino gli Awwwards e vedrai che su mobile non sono nulla di che. Ok adesso verrà la UX Police ad arrestarmi ma ormai è troppo tardi, l’ho detto e tutti lo sapranno.
La velocità è UX: Un sito bello che ci mette 8 secondi a caricare è un sito che nessuno vedrà mai. Ottimizza le immagini, riduci gli script inutili, non mettere video in autoplay da 50MB in homepage.
Il cliente non ha sempre torto: Sì, lo so, è difficile da accettare. Ma a volte il cliente conosce i suoi utenti meglio di te. Ascolta prima di impuntarti, anche perché alla fine farai quello che dice lui.
Il gran finale: cose tecniche per chi è un one man band (ovvero: perché stai impazzendo e va bene così)
Fare un sito web è sottovalutato. Le pubblicità ci dicono che è facile farselo da soli. La verità è che farlo bene (o almeno in modo decente) è un’impresa che farebbe sembrare le dodici fatiche di Ercole una passeggiata al parco. Lo dico per esperienza diretta: l’ho fatto e ogni tanto lo faccio ancora. Ma io sono fatto così, sono fondamentalmente un folle con tendenze masochistiche e una relazione tossica con le deadline.
La verità è che un sito web richiede competenze in almeno sei o sette campi diversi: sviluppo, grafica, UX design, SEO, copywriting, ottimizzazione delle performance, sicurezza… La lista continua come i titoli di coda di un film Marvel.
Pensateci: nemmeno il CEO di Google sa fare tutte queste cose insieme.
Ma ecco il punto: se il cliente ha scelto te, singolo professionista, invece di un’agenzia con un team di specialisti, ci sono solo due possibilità. O sta cercando di risparmiare (legittimo, siamo tutti sulla stessa barca che affonda), oppure è convinto che tu sia una specie di Leonardo da Vinci del digitale capace di eccellere in ogni campo. Spoiler: non lo sei. Non lo è nessuno.
La matematica è semplice e brutale: queste aree sono talmente vaste che padroneggiarne anche solo due o tre ad alto livello richiede anni di studio e pratica. Magari sei un mago della grafica e te la cavi col codice, ma la SEO per te è un mistero più fitto della trama di “Inception”. Oppure sei uno sviluppatore coi fiocchi ma non riesci a capire perché in realtà i template di Canva fanno schifo.
Il mio consiglio? Onestà brutale. Col cliente, ma soprattutto con te stesso.
Prima di accettare un progetto, fai un inventario delle tue skill reali. Non quelle che scrivi su LinkedIn per fare bella figura, quelle vere. Quelle che useresti se qualcuno ti puntasse una pistola alla tempia e ti chiedesse “ma tu SAI fare questa cosa?”.
Poi, quando parli col cliente, sii chiaro: “Guarda, io sono forte su grafica e sviluppo, ma per la SEO e il copywriting potresti aver bisogno di consultare qualcun altro”. Sembra controintuitivo, vero? Tipo ammettere una debolezza durante un colloquio di lavoro. Ma in realtà stai facendo due cose intelligentissime: primo, stai gestendo le aspettative (niente è peggio di un cliente deluso); secondo, stai dimostrando professionalità (i ciarlatani promettono tutto, i professionisti sanno dire “questo non è il mio campo”).
E se il cliente ti guarda male e dice “ma io voglio tutto da te”? Beh, a quel punto hai due opzioni: o ti fai pagare abbastanza da poter subappaltare le parti in cui fai schifo a qualcun altro, oppure accetti consapevolmente che alcune aree del progetto saranno “abbastanza buone” invece che eccellenti. L’importante è che sia una scelta consapevole, non una sorpresa amara a progetto finito.
Ah, e un ultimo consiglio: costruisciti una rete di collaboratori fidati. Quel SEO specialist che hai conosciuto a quel meetup noioso, quella copywriter che ti ha scritto una volta su LinkedIn, quello sviluppatore che fa le cose che tu non sai fare. Tienili buoni. Perché quando ti arriva il progetto che richiede competenze che non hai, poter dire “conosco qualcuno che può aiutarci” è molto meglio che fingere di saper fare tutto e poi consegnare un disastro.
P.S. Se questo articolo ti ha fatto sentire personalmente attaccato perché anche tu alle tre di notte stavi googlando “come centrare un div” mentre fingevi di essere un esperto di sviluppo web, sappi che non sei solo. Siamo un esercito di impostori che in qualche modo continuano a consegnare progetti. E onestamente? È quasi eroico.
Lascia un commento