Utente, contesto d’uso, casi reali

Una feature astratta (“gestione utenti”) non è progettabile. Una feature ancorata a una persona reale in un contesto specifico (“Marco, magazziniere di 50 anni, registra arrivi merce dal cellulare in piedi davanti agli scaffali, con guanti, in zona con segnale a tratti”) sì. Il salto da astratto a concreto è dove le decisioni di design diventano corrette o sbagliate.

Perché questa lezione conta

Senza utente concreto e contesto reale, ogni decisione UI/UX è arbitraria. Il modello AI (e tu) finisce a riempire i vuoti con default generici: form lunghi, click molteplici, layout desktop-first, errori in inglese tecnico. Risultato: feature che funziona in laboratorio e fallisce nel mondo reale, dove utenti hanno mani occupate, fretta, lingua diversa, dispositivi vecchi, connessione lenta.

Obiettivo operativo

Alla fine devi saper:

1. scrivere una persona minima utile (5 attributi essenziali);
2. descrivere un caso d’uso completo come sequenza azione → dato → decisione → risultato → errore;
3. scegliere il caso normale e il caso difficile da progettare prima di tutto.

Nucleo della lezione

1. Persona minima

Non servono persone elaborate da agenzia di marketing. Cinque attributi bastano:

• Ruolo: lavoro o relazione con il prodotto. Magazziniere, redattore, founder, studente, cliente finale.
• Competenza tecnica: principiante / intermedio / avanzato rispetto al dominio. Determina vocabolario e densità di info.
• Obiettivo principale: cosa vuole ottenere usando il prodotto, in una frase.
• Frequenza d’uso: quotidiano / settimanale / sporadico. Cambia tutto: shortcut keyboard servono solo a uso quotidiano.
• Frustrazione corrente: cosa va storto oggi, prima del tuo prodotto. È la leva di adozione.

Esempio:

Anna, redattrice freelance, intermedia con tool digitali, vuole organizzare bozze di articoli per più clienti, lavora 4 giorni settimana fra casa e bar, oggi perde 20 minuti a settimana cercando l’ultima versione di un articolo fra Drive, email e Notion.

40 parole. Sufficiente.

2. Caso d’uso reale

Un caso d’uso non è “feature”: è una sequenza con cinque elementi:

1. Trigger / situazione iniziale: quando, dove, in che stato. “Lunedì mattina, Anna apre il laptop, ha 3 articoli da consegnare entro venerdì.”
2. Azione: cosa fa l’utente, gesto concreto. “Apre l’app, clicca su ‘Articoli da consegnare’.”
3. Dato in ingresso: cosa porta. “Bozza Word di un articolo, due foto, brief del cliente.”
4. Decisione: cosa il sistema le propone, cosa lei sceglie. “Sistema propone tre stati: bozza, in revisione, consegnato. Anna sceglie ‘in revisione’.”
5. Risultato: cosa cambia osservabilmente. “Articolo appare nella vista ‘In revisione’ del cliente Y, scadenza visibile.”
6. Errore possibile: cosa può andare storto. “Internet cade durante upload foto. Cosa vede Anna?”

Un caso d’uso scritto così è progettabile. È direttamente traducibile in flusso UI, schema dati, gestione errori.

3. Caso normale + caso difficile

Errore di chi inizia: progettare per il caso normale e dimenticare il caso difficile. Errore di chi sovraingegnerizza: progettare 20 casi limite prima ancora di avere il caso normale.

Approccio bilanciato: esattamente due casi all’inizio.

• Caso normale (happy path): tutto fila, utente collaborativo, dati validi, rete funzionante. È la demo.
• Caso difficile (un solo problema): una cosa va storta in modo realistico. Rete lenta, dato mancante, due utenti modificano stesso elemento, file enorme, sessione scaduta.

Progetta entrambi prima di scrivere codice. Il caso difficile rivela molte assunzioni del caso normale e cambia spesso l’architettura iniziale.

Una volta che caso normale + caso difficile funzionano, aggiungi altri casi solo quando emergono da utenti reali, non da fantasia.

Procedura pratica

Per ogni feature significativa:

1. Persona minima (5 attributi, 40 parole).
2. Caso normale completo (sei elementi).
3. Caso difficile completo (sei elementi, con un solo problema realistico).
4. Verifica coerenza: la persona di sezione 1 vivrebbe davvero il caso di sezione 2 e 3?
5. Scrivi prompt allegando i tre artefatti come contesto.

L’AI con persona+casi produce design più rilevanti che con specifica astratta.

Laboratorio guidato

Stesso prodotto (es. app per gestire abbonamenti palestra), due varianti: con persona+casi vs senza.

Round A (senza): prompt “fammi un’app per gestire abbonamenti palestra”. Salva output.

Round B (con):

• persona: Mario, segretario di palestra di provincia, 55 anni, intermedio con computer, registra rinnovi e nuovi iscritti dal banco accoglienza, frequenza alta in fasce 17-21;
• caso normale: cliente arriva al banco, Mario lo cerca per cognome, vede scadenza abbonamento, registra rinnovo con metodo pagamento, stampa ricevuta;
• caso difficile: cliente non si ricorda il cognome esatto (errore di trascrizione su iscrizione), Mario deve trovarlo comunque, in fila ci sono altri 3 clienti.

Stesso prompt iniziale + i tre artefatti come contesto. Salva output.

Confronta: quale design è più pertinente? Quale tocca direttamente il problema? Quale ha gestito ricerca approssimata, layout per fila, errore di trascrizione?

Output atteso

Una scheda persona + casi d’uso (1 normale + 1 difficile) per il prossimo progetto, da allegare al prompt. Riusabile e modificabile man mano che l’utente reale emerge.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: ancorare il progetto a persone, situazioni e comportamenti concreti invece che a funzioni astratte. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Persona minima: ruolo, competenza, obiettivo, frequenza d’uso, frustrazione principale.
• Casi d’uso reali: azione, dato in ingresso, decisione, risultato, errore possibile.
• Priorità: progettare prima il caso normale e un caso difficile, non un elenco infinito di feature.

3. Applicazione: svolgi il laboratorio: scrivere due scenari d’uso completi per lo stesso prodotto: uno fluido e uno problematico. L’output da ottenere è: una scheda utente/casi d’uso che l’AI può usare come contesto stabile durante la generazione.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• ho una persona minima per ogni utente significativo del mio prodotto;
• ho almeno un caso normale e un caso difficile scritti;
• la persona è una persona, non un cluster (“le persone fra 25-45 anni che amano la produttività” non è una persona);
• il caso difficile è realistico, non catastrofico (rete lenta, sì; meteorite, no).

Errori comuni

Persona da brochure. “Sara, 32 anni, ama il caffè e la mindfulness”. Inutile. Servono attributi che cambiano il design.

Più persone all’inizio. “Abbiamo admin, manager, operatore, cliente, fornitore”. Per la prima versione: una persona, una. Le altre arrivano dopo.

Caso normale solo, niente caso difficile. Risultato: app che fa demo bene e si rompe a contatto col mondo.

Caso difficile catastrofico. “E se cade il datacenter durante un acquisto?” Realistico, ma per le edge case rare design dopo. Il difficile iniziale deve essere frequente, non drammatico.

Persona finta che giustifica decisioni già prese. Persona non è alibi. Se hai già deciso lo stack, non costruire una persona finta che lo richieda.

Prompt di lavoro

Sto progettando: [feature/prodotto].

Persona principale (per chi):
- ruolo: [...]
- competenza tecnica: [...]
- obiettivo: [...]
- frequenza d'uso: [...]
- frustrazione attuale: [...]

Caso normale:
- trigger: [...]
- azione: [...]
- dato in ingresso: [...]
- decisione: [...]
- risultato: [...]
- errore possibile: [...]

Caso difficile (un solo problema realistico):
- trigger: [...]
- azione: [...]
- dato in ingresso: [...]
- decisione: [...]
- risultato: [...]
- errore possibile: [...]

Voglio:
1. Verifica coerenza: la persona vivrebbe davvero entrambi i casi?
2. Domande che ti farei per chiarire ambiguità prima del design.
3. Solo dopo, proposta di flusso UI ad alto livello (no codice).

Se i casi rivelano problemi nella persona, segnalalo prima di proseguire.

Esercizio finale

Prendi un’app che usi quotidianamente e che funziona bene. Ricostruisci la persona principale e due casi d’uso (normale + difficile) che secondo te i designer hanno tenuto a mente. Poi prendi un’app che usi e che funziona male: quale persona o caso difficile hanno saltato? L’esercizio sviluppa l’occhio per riconoscere quando una feature ha base solida e quando galleggia su assunzioni astratte.