Dove va davvero il tempo in un progetto software.
Chiedete a uno sviluppatore senior quanto tempo passa a scrivere logica di business rispetto a costruire interfacce. La risposta, quasi invariabilmente, è scomoda: la logica — le regole, i calcoli, le integrazioni, il database — si scrive in tempi relativamente prevedibili. L'interfaccia no.
Non perché l'interfaccia sia tecnicamente complessa. Ma perché è il punto in cui l'astratto diventa concreto. È il momento in cui il cliente vede per la prima volta cosa sta comprando, e inizia a capire cosa voleva davvero. Il form che sembrava ovvio sulla carta richiede tre iterazioni perché l'utente reale non segue il flusso immaginato. Il menu che andava bene nel wireframe non funziona su mobile. I colori approvati in design review sembrano diversi in produzione. Il testo che il cliente ha fornito non entra nell'etichetta del bottone.
La UX/UI è il confine tra il progetto e la realtà. E quel confine è sempre più accidentato di quanto sembri prima di arrivarci.
Il cliente guarda il flusso, non l'interfaccia.
Quando un'azienda commissiona un software, ha in testa un flusso: inserisco il dato, il sistema lo elabora, ottengo il risultato. Questo è il valore che percepisce — la funzionalità, il processo automatizzato, il tempo risparmiato. L'interfaccia è lo strato che lo avvolge, e viene data per scontata esattamente come si dà per scontato che la luce si accenda quando si preme l'interruttore.
Questo crea un disallineamento strutturale. Il team di sviluppo ha speso settimane a ragionare su come organizzare le informazioni, dove mettere i controlli, come rendere leggibili i dati, come gestire gli errori in modo comprensibile. Il cliente fa una demo di venti minuti e dice: "Sì, funziona." Poi chiede perché costi così tanto.
Non è cinismo. È un problema di visibilità. Il backend è invisibile e viene percepito come complesso. Il frontend è visibile e viene percepito come semplice. La percezione è esattamente l'opposto della realtà del lavoro.
"Il backend è invisibile e sembra complesso. Il frontend è visibile e sembra semplice. La percezione è l'opposto della realtà."
Gli utenti si sono abituati agli standard dei grandi.
C'è un secondo livello di complessità, più sottile. Gli utenti — quelli reali, che useranno il software ogni giorno — non arrivano da un universo vergine. Arrivano da anni di utilizzo di Google, Apple, Spotify, WhatsApp, Amazon. Hanno interiorizzato pattern di interazione precisi: dove sta il menu, come funziona la ricerca, cosa significa un'icona a forma di cestino, come si conferma un'azione.
Questi pattern sono stati definiti e raffinati da aziende con team di design da centinaia di persone, budget di ricerca utente nell'ordine dei milioni, e la possibilità di fare A/B testing su miliardi di utenti. Non sono convenzioni arbitrarie — sono il risultato di anni di ottimizzazione su scala industriale.
Una piccola software house non può competere su questo terreno. Non ha la massa critica per imporre un nuovo paradigma di interazione. Se l'interfaccia si discosta troppo da quello che gli utenti si aspettano, il software verrà percepito come difficile — indipendentemente da quanto sia potente o ben costruito internamente. Torneranno all'Excel. O al foglio di carta. O al WhatsApp del gruppo operativo.
Il vibe coding non risolve il problema — lo redistribuisce.
Negli ultimi mesi ho osservato con attenzione cosa produce il vibe coding in termini di interfacce. La risposta è: produce interfacce riconoscibili. Card con ombra, bottoni arrotondati, sidebar a sinistra, navbar in alto. Il risultato visivo di un modello che ha visto milioni di interfacce è una sorta di media statistica di tutte quelle interfacce — funzionale, prevedibile, mai sorprendente.
C'è qualcosa di positivo in questo: quelle interfacce rispettano i pattern che gli utenti si aspettano. L'adozione è più semplice. La curva di apprendimento è più bassa. Ma c'è anche qualcosa che viene perso: la capacità di costruire un'interfaccia realmente su misura per il flusso specifico di quell'azienda, per quella tipologia di utente, per quel contesto operativo.
Il vibe coding sposta il costo della UX. Non lo elimina. Prima, il costo era nelle ore di un designer e di uno sviluppatore frontend. Ora è nel tempo necessario a raffinare i prompt, iterare sulle varianti, adattare il risultato al caso specifico. Qualcuno deve pur conoscere la differenza tra un'interfaccia che funziona e una che funziona per quegli utenti specifici. E quella conoscenza non viene dal modello — viene dall'osservazione diretta di chi userà il sistema.
Non è un argomento contro la UX — è un argomento per renderla esplicita.
Quello che ho imparato, dopo anni di progetti, è che la UX/UI non può restare implicita nel preventivo. Se viene inclusa senza essere nominata, diventa invisibile — e tutto quello che è invisibile viene contestato quando il conto arriva.
La soluzione non è sacrificare la qualità dell'interfaccia per stare nei costi. È rendere esplicito il lavoro che c'è dietro: i wireframe, le sessioni di test con gli utenti reali, le iterazioni sul feedback, le decisioni di design che hanno conseguenze sull'adozione. Non come voce di costo da giustificare, ma come parte del valore consegnato.
Perché alla fine, un software che nessuno usa non vale nulla — indipendentemente da quanto sia potente sotto il cofano. E gli utenti non usano ciò che non capiscono, non si fidano di ciò che sembra strano, e non imparano ciò che richiede troppo sforzo. La UX è il punto in cui queste tre cose si decidono.
Il fatto che gli utenti si siano abituati agli standard dei grandi player non è solo un problema di costo della UX. È un segnale di qualcosa di più profondo: il gap crescente tra il software che si usa nella vita privata e quello che si usa al lavoro. Un gap che ha conseguenze concrete sull'adozione, sulla produttività e sulla resistenza alla digitalizzazione.
Ne parlo in modo specifico nell'articolo sulla convergenza dell'esperienza utente →