UX design per startup

La tavola
Cos'è un design system, in concreto?
È l'insieme di regole e pezzi riutilizzabili (colori, caratteri, griglia, componenti, movimento) che designer e sviluppatori condividono, con un nome e un valore per ciascuno. Questa tavola è il design system di questo sito: i valori sono quelli che usa il codice, letti dal CSS mentre guardi.
Passa sopra un pezzo, o premi +, per leggerne le specifiche.
- Token
- --font-d
- Valore
- Panchang, peso 300
- Uso
- Titoli grandi: largo e leggero, regge da solo una pagina
- Token
- --bg
- Valore
- #e5e9ed
- Uso
- Il fondo di tutto il sito: un grigio freddo, mai crema
- Token
- --ink
- Valore
- #0d1017
- Uso
- Testi e linee; contrasto 15,6:1 sullo sfondo
- Token
- --accent
- Valore
- #6d63e6
- Uso
- Focus, passaggio del mouse, dettagli. 3,8:1 sullo sfondo: buono per titoli grandi ed elementi d'interfaccia, non per i paragrafi
- Regola
- :focus-visible
- Valore
- contorno 2px --accent, distanza 4px
- Uso
- Chi naviga da tastiera sa sempre dove si trova
- Classe
- .k-link
- Valore
- riga di 1px, freccia, lilla al passaggio in 0,3 s
- Uso
- Ogni invito all'azione del sito: niente bottoni a pillola
- Colonne
- 12
- Spazio tra colonne
- --gutter: clamp(12px, 1.8vw, 28px)
- Margine
- --margin: clamp(16px, 4.6vw, 88px)
- Token
- --font-t
- Valore
- Geist, pesi 400 e 500
- Uso
- Tutto ciò che si legge: righe di 62 caratteri al massimo
- Gradini
- --step--1 … --step-5, fluidi con clamp()
- --step-3
- clamp(2.3rem, 1.3rem + 3.9vw, 5.4rem)
- --step-5
- clamp(3.4rem, 0.8rem + 10.5vw, 13rem)
- Token
- --font-serif
- Valore
- Fraunces Italic, peso 330
- Uso
- Titoli di sezione occasionali, sempre in inchiostro, mai colorati
- Elemento
- <details> e <summary>
- Valore
- riga di 1px, + che ruota in 0,5 s
- Uso
- Si apre anche senza JavaScript, una domanda alla volta
- --ease-out
- cubic-bezier(0.16, 1, 0.3, 1)
- --ease-io
- cubic-bezier(0.76, 0, 0.24, 1)
- Uso
- Entrate morbide, passaggi decisi; con "riduci movimento" attivo si ferma tutto
Il processo
Come si progetta l'esperienza di un prodotto digitale?
In sei passaggi: ricerca, flussi, wireframe, prototipo, test con utenti e handoff agli sviluppatori. Ogni passaggio produce qualcosa che si può guardare, discutere e decidere prima di passare al successivo.
Ricerca
Parliamo con chi userà il prodotto e con chi lo vende: cosa fa oggi, dove perde tempo, cosa lo convincerebbe a cambiare. Ne escono i problemi da risolvere, in ordine di importanza.
Flussi
Disegniamo il percorso che porta l'utente al risultato: da dove entra, quali scelte fa, dove può bloccarsi. Qui si decide cosa entra nella prima versione e cosa può aspettare.
Wireframe
Schermate in bianco e grigio, senza colori né caratteri definitivi: servono a discutere struttura e priorità senza farsi distrarre dall'estetica.
Prototipo
Il wireframe diventa un prototipo cliccabile con il design vero, abbastanza realistico da sembrare il prodotto finito senza una riga di codice.
Test con utenti
Mettiamo il prototipo davanti a persone del tuo pubblico, con un compito preciso, e le guardiamo usarlo. Dove esitano si corregge, finché correggere costa poco.
Handoff
Consegniamo il design system, i componenti con tutti i loro stati e le specifiche. Se lo sviluppo lo facciamo noi, designer e sviluppatori lavorano nello stesso team.
Lo facciamo anche per noi. Athleex, il SaaS del gruppo per personal trainer, ha due utenti da progettare insieme: il coach, che lavora da una dashboard con schede, clienti e numeri del suo business, e l'atleta, che apre l'app ogni giorno per allenarsi.
Cosa ricevi
Cosa consegna il design in ogni fase?
Documenti che servono a decidere, non presentazioni da archiviare: ogni fase lascia qualcosa che il team, gli investitori o gli sviluppatori usano subito dopo.
| Fase | Cosa ricevi | A cosa ti serve |
|---|---|---|
| Ricerca | Sintesi delle interviste, problemi in ordine di priorità, profili degli utenti | Decidere per chi costruisci e cosa conta davvero |
| Flussi | Mappa dei percorsi e architettura dell'informazione | Fissare il perimetro della prima versione |
| Wireframe | Schermate in bassa fedeltà dei percorsi principali | Discutere struttura e priorità prima dell'estetica |
| Prototipo | Prototipo cliccabile in alta fedeltà | Mostrare il prodotto a clienti, team e investitori |
| Test con utenti | Note delle sessioni e lista delle correzioni, in ordine di gravità | Sapere cosa cambiare prima di sviluppare |
| Handoff | Design system, componenti con i loro stati, specifiche | Sviluppare senza tirare a indovinare |
Poi il design diventa codice: lo sviluppiamo nell'MVP, nella web app o nel sito, con lo stesso team.
Da evitare
Quali errori di UX fanno le startup?
Ricorrono spesso gli stessi: progettare per tutti invece che per il primo cliente, chiedere troppo prima di dare qualcosa, dimenticare i momenti in cui il prodotto è vuoto o va in errore.
- Progettare per tutti
- Un prodotto che prova a piacere a tutti non convince nessuno. Il primo design va cucito sul primo tipo di cliente: quello con il problema più urgente.
- Chiedere troppo all'iscrizione
- Carta di credito, dieci campi, conferme a catena prima di vedere il prodotto. Ogni richiesta in più deve guadagnarsi il suo posto.
- Dimenticare lo stato vuoto
- Il primo accesso è uno schermo senza dati. Se non dice cosa fare per primo, l'utente nuovo non sa da dove partire, e spesso non torna.
- Errori senza via d'uscita
- Messaggi tecnici, moduli che si svuotano, nessun modo di tornare indietro. Un buon errore dice cosa è successo e cosa fare adesso.
- Disegnare solo per il desktop
- Il link arriva da una notifica, da un messaggio, da un social: si apre sul telefono. Se lì il prodotto non funziona, la prima impressione è persa.
- Decidere senza guardare nessuno
- Le discussioni interne su un bottone si chiudono in un pomeriggio di test con utenti veri. Le opinioni del team non sono dati.
Domande sul design di prodotto
Quanto costa il design UX per una startup?
Dipende da quanti percorsi e schermate servono, da quanta ricerca è già stata fatta, dal numero di test con utenti e da quanto deve essere completo il design system. Non pubblichiamo listini: i fattori sono spiegati nella pagina prezzi e tempi.
Abbiamo già un design: potete svilupparlo?
Sì. Prima lo rivediamo per trovare i casi mancanti (stati vuoti, errori, versione mobile, accessibilità), poi lo sviluppiamo. Se serve, lo ordiniamo in un design system con componenti riutilizzabili, così il prodotto resta coerente quando cresce.
Che differenza c'è tra UX e UI?
La UX (user experience) è come funziona il prodotto per chi lo usa: percorsi, priorità, quanto è facile arrivare al risultato. La UI (user interface) è come appare: colori, caratteri, componenti. Una bella interfaccia sopra un'esperienza confusa resta un prodotto difficile da usare.
Serve un design system già per un MVP?
Uno piccolo sì: colori, caratteri, spaziature e una manciata di componenti con i loro stati. Costa poco all'inizio e fa risparmiare tempo a ogni schermata successiva; quello completo cresce insieme al prodotto.
Serve la ricerca con gli utenti se il budget è poco?
Sì, in proporzione al budget: anche poche interviste ben fatte e un test sul prototipo evitano di sviluppare la funzione sbagliata. È la parte del design che costa meno e che può far risparmiare settimane di sviluppo.
Prima di scrivere codice, disegniamo cosa serve davvero.
Rispondiamo entro un giorno lavorativo.
Parliamone
