Prima degli strumenti, un progetto.

Il problema dei pezzi scollegati

Un sito può essere curato e lasciare senza risposta una domanda fondamentale. Una campagna può portare visite a una pagina che non spiega il servizio. Un modulo può ricevere richieste che nessuno sa a chi assegnare. Il problema è il collegamento fra le parti.

L’architettura definisce quel collegamento: cosa deve capire una persona, in quale momento, con quali informazioni e quale azione deve poter compiere.

Business, persone, informazioni

Partiamo dall’attività: che cosa offre, a chi, dove e con quali condizioni. Poi osserviamo la persona che deve scegliere: dubbi, confronto, vincoli e motivi di fiducia. Solo dopo organizziamo pagine e funzioni.

• Business: risultato atteso e vincolo principale.
• Persone: bisogni e decisioni da accompagnare.
• Informazioni: contenuti, prove e dati realmente disponibili.
• Percorso: arrivo, comprensione, confronto e contatto.
• Tecnologia: lo strumento più semplice che sostiene quel percorso.

Un esempio concreto

Per un’impresa che installa impianti, il cliente può voler capire prima l’ambito di intervento, poi se l’azienda opera nella sua zona e infine quali informazioni servono per chiedere una valutazione. La pagina dovrebbe seguire quel bisogno. Un’animazione non può sostituire l’elenco dei servizi o una zona di intervento chiara.

È un esempio di ragionamento progettuale, non un caso cliente né una promessa di risultato.

Serve anche a un’attività piccola?

Sì, nella misura del problema. A volte bastano tre pagine ben organizzate. Altre volte occorre un sistema più articolato. L’obiettivo non è aumentare il numero di funzioni: è eliminare passaggi confusi e responsabilità indefinite.

Come diventa un progetto

Il risultato è un perimetro verificabile: pagine, contenuti, azioni, materiali, responsabilità e criteri di consegna. Il design rende visibile questa struttura. Il codice la realizza. La verifica controlla che funzioni nel browser.