Come si progetta un sito web

Progettare non significa iniziare dalla homepage

Quando si parla di creare un sito, la prima immagine è spesso una pagina già disegnata. Ma una homepage è il risultato visibile di molte decisioni precedenti. Prima di stabilire colori e disposizione dei blocchi occorre capire quale cambiamento il sito deve produrre, per quali persone e in quale contesto.

Un progetto può servire a presentare un'attività, qualificare richieste, supportare una rete commerciale, raccogliere dati, distribuire documenti o offrire un servizio. Queste finalità non conducono automaticamente alla stessa struttura. Per questo la progettazione parte dalle domande, non dal catalogo dei componenti.

Definire obiettivi osservabili

“Essere presenti online” non basta a guidare il lavoro. Un obiettivo utile descrive cosa una persona dovrebbe poter capire o fare e quale segnale consentirà di valutarlo.

• capire se il servizio risponde al proprio problema;
• confrontare soluzioni senza chiedere subito assistenza;
• inviare una richiesta con le informazioni necessarie;
• accedere a documenti o dati in modo controllato;
• trovare l'attività da uno smartphone durante uno spostamento.

Gli obiettivi non devono trasformarsi subito in numeri arbitrari. Prima serve una base di misurazione credibile. Devono però essere abbastanza concreti da aiutare a scegliere contenuti e funzioni.

Conoscere pubblico e contesto

Il pubblico non è una descrizione demografica generica. Conta ciò che le persone sanno già, le domande che portano, il dispositivo che usano e il rischio percepito nella decisione.

Una persona che arriva da una ricerca informativa richiede spiegazioni diverse da chi conosce già il servizio. Un cliente esistente che cerca assistenza non dovrebbe attraversare lo stesso percorso di un nuovo contatto. La progettazione individua questi scenari e decide quali meritano percorsi dedicati.

Organizzare contenuti e architettura

La sitemap non è soltanto l'elenco delle pagine. Rende esplicita la relazione tra argomenti, servizi, pubblici e azioni. Una buona architettura evita sia la pagina unica che tenta di dire tutto, sia decine di pagine quasi identiche create per intercettare parole diverse.

Dall'intento alla pagina

Ogni URL dovrebbe avere una responsabilità riconoscibile. Se due pagine rispondono alla stessa domanda con lo stesso contenuto, probabilmente devono essere consolidate. Se una pagina serve pubblici differenti, può aver bisogno di percorsi interni o di una separazione motivata.

Titoli, navigazione e collegamenti interni nascono insieme alla struttura. Le etichette devono essere comprensibili anche a chi non conosce il lessico dell'organizzazione.

Il contenuto verifica la sitemap

Scrivere una prima versione dei contenuti rivela spesso categorie troppo vaghe, pagine sottili o passaggi mancanti. Per questo architettura e copy procedono per iterazioni. Il testo non riempie una struttura già conclusa: contribuisce a verificarla.

Progettare percorsi e interfaccia

La UX stabilisce ordine, priorità e comportamento. Chiarisce come si passa da una domanda a una risposta, dove collocare una CTA, quali campi chiedere e cosa accade dopo un errore.

Il design visuale rende queste relazioni percepibili attraverso tipografia, spazio, contrasto, immagini e componenti. Non dovrebbe introdurre rumore né nascondere una gerarchia debole dietro effetti decorativi.

Mobile come vincolo progettuale

Su uno schermo piccolo spazio e attenzione sono limitati. Progettare mobile-first costringe a chiarire priorità, ma non significa eliminare informazioni importanti. Il contenuto sostanziale deve restare disponibile; cambiano disposizione e modalità di interazione.

Scegliere tecnologia e modello dei dati

La tecnologia viene valutata quando requisiti e modalità di gestione sono più chiari. Un sito editoriale può partire da contenuti strutturati senza database. Un'area riservata, un workflow o dati con relazioni e accessi concorrenti richiedono un'architettura diversa.

La scelta considera anche chi aggiornerà il sistema, quali integrazioni esistono, quali dati sono sensibili e come il progetto verrà distribuito e monitorato. Le tecnologie utilizzate sono mezzi per soddisfare questi vincoli.

Integrare SEO e accessibilità

SEO tecnica e accessibilità condividono molte fondamenta: HTML semantico, gerarchie chiare, link comprensibili, immagini descritte, pagine raggiungibili e prestazioni adeguate. Non sono controlli da applicare soltanto prima della pubblicazione.

Intenti di ricerca, URL, canonical, dati strutturati e sitemap influenzano l'architettura. Tastiera, focus, contrasto, messaggi di errore e tecnologie assistive influenzano componenti e contenuti.

Sviluppare per incrementi verificabili

Lo sviluppo traduce il progetto in comportamento. Procedere per parti verificabili permette di controllare presto routing, rendering, dati, moduli e componenti. I test automatici proteggono regole stabili; le verifiche manuali osservano leggibilità, dispositivi e casi che non si riducono a un'asserzione.

Pubblicare e continuare a osservare

Prima della messa online vanno controllati dominio, HTTPS, redirect, status code, metadata, sitemap, robots, form, errori e strumenti per webmaster. La pubblicazione non rende definitivo il progetto: rende disponibili dati reali.

Analytics, richieste ricevute, ricerche interne e nuove esigenze aiutano a decidere cosa migliorare. L'evoluzione dovrebbe mantenere la stessa disciplina iniziale: problema, ipotesi, intervento e verifica. La pagina come lavoriamo descrive questo processo in modo operativo.