Settimana scorsa ho visto questa scena (ormai classica): designer passa wireframe a dev, dev sviluppa in sprint, QA automatico tutto verde, si rilascia. Due ore dopo: “Il pulsante non fa niente quando cambio variante prodotto”.
Il pulsante funzionava. Semplicemente, nessuno aveva mai testato quella sequenza di azioni. Nessuno aveva chiesto a un utente reale “Ti è chiaro come funziona?”. Nessuno aveva fatto usability testing prima dello sviluppo.
Perché? Perché in tantissime realtà (soprattutto PMI, startup, progetti interni) la sequenza è questa:
- Idea
- Wireframe veloce
- Sviluppo
- QA tecnico
- Deploy
- 🔥
Manca tutta la fase di UX research. Niente interviste utenti, niente test di usabilità, niente validazione flussi. Si va dritti dal mockup al codice.
Il problema vero: nessuno ha parlato con gli utenti
Diciamolo chiaramente: la stragrande maggioranza delle app/software non viene progettata, viene “buttata giù”.
Non perché i team siano incompetenti, ma perché:
- Budget ristretti (“UX research? Non possiamo permettercelo”)
- Timeline aggressive (“Usability test? Slitta di 3 settimane!”)
- Cultura aziendale (“Ma noi siamo gli utenti, sappiamo cosa serve”)
- Competenze mancanti (dev bravi, designer assente, nessuno sa fare interviste)
Risultato: si sviluppa basandosi su ipotesi non validate. “Gli utenti capiranno”, “È ovvio come funziona”, “Se serve aggiungiamo tooltip”.
E qui entra il QA tecnico, che però testa solo una cosa: “Il codice fa quello che deve?”. Non testa “Ma un essere umano ci riesce? Capisce? Non si blocca?”.
Cosa succede quando salti la progettazione UX
Ho visto questi pattern ripetersi per anni:
Scenario 1 – Il flusso “ovvio” che non è ovvio Dev: “Premi su Account, poi su Profilo, poi modifica email, poi conferma via link email, poi re-login.”
Utente: “…dove clicco per cambiare email?”
→ Tecnicamente funziona perfetto. Umanamente è un labirinto.
Scenario 2 – Il campo che esiste ma nessuno lo trova Designer: “Abbiamo messo il filtro avanzato nel menu hamburger in alto a destra.”
Utente: usa la ricerca base per 6 mesi, non sa che esiste filtro avanzato
→ Feature sviluppata, testata, deployata. Zero utilizzo.
Scenario 3 – L’edge case che è “normale” per il 30% degli utenti PM: “Nessuno cambierà indirizzo a metà checkout.”
Realtà: 30% degli utenti lo fa (regalo, azienda/casa, correzione typo).
→ Bug critico che nessun test automatico intercetta perché nessuno l’ha pensato.
Questi problemi non esisterebbero con proper UX research. Ma visto che siamo nel mondo reale…
Dove entra il QA UX
Facciamo chiarezza: il QA UX non sostituisce la progettazione. Se hai budget/tempo per fare user research, interviste, usability testing prima dello sviluppo, fallo. Sempre. È la cosa giusta.
Il QA UX serve quando:
- Hai già sviluppato senza UX research (la maggioranza dei casi)
- Hai una deadline che non permette ricerca a monte
- Stai per rilasciare e vuoi una rete di sicurezza pre-produzione
- Non hai competenze UX in team ma vuoi almeno un controllo
È una rete di sicurezza tardiva, non la soluzione ideale. Ma qualcuno che ha competenze in UX e UI ed è estranea al prodotto, può intercettare problemi in staging che anziché in produzione.
Cosa fa concretamente:
- Testo i flussi principali come farebbe un utente reale (no script, esplorazione)
- Identifico edge case che sfuggono al QA tecnico (es. “cambio idea a metà processo”)
- Valuto chiarezza interfaccia (“Capisco cosa devo fare? Le label sono ambigue?”)
- Documento blocchi/frustrazioni con screenshot e severità
Cosa NON fa:
- Non è ricerca generativa (non ti dico cosa costruire)
- Non è redesign (non modifico UI)
- Non sostituisce user interview pre-sviluppo
- Non valida il business case
Pensa a me come a un utente in prestito per una settimana, che prova tutto prima che lo facciano i tuoi clienti reali. E ti dice dove si incastra.
Leggi “user” al posto di “scientist”😂
Perché il QA Automatico è fondamentale ma non basta
Il QA automatico è veloce, ripetibile, efficiente. Ma ha un limite strutturale:
| Test Automatico | Test UX Manuale |
|---|---|
| “Il pulsante submit manda i dati?” ✅ | “L’utente capisce quale pulsante premere?” |
| “Il form valida email corrette?” ✅ | “Il messaggio errore è chiaro o frustrante?” |
| “Il checkout completa transazione?” ✅ | “Un utente distratto si blocca a metà?” |
L’automatico testa conformità al codice. Il manuale testa esperienza reale.
Esempio: un form che tecnicamente valida tutto ma mostra 8 errori in rosso contemporaneamente (“Password debole”, “Email invalida”, “Nome troppo corto”…). Il QA automatico dice “Passa”. L’utente chiude la pagina frustrato.
Come funziona il servizio
Setup (settimana 1)
- 1 call di 30-60 min: mi spieghi cosa fa il prodotto, chi sono gli utenti, quali flussi prioritari
- Mi dai accesso staging + credenziali test
- Ti mando checklist di cosa testerò (la personalizzi se serve)
Testing (settimane 2-3)
- Eseguo test esplorativi sui flussi principali + edge case
- Documento tutto: screenshot, step per riprodurre, severità (blocker/major/minor)
- Comunicazione asincrona: Slack/mail per dubbi, no meeting salvo urgenze
Report (settimana 4)
- Documento strutturato: cosa funziona, cosa si rompe, dove l’utente si blocca
- Prioritizzazione: cosa fixare subito vs cosa può aspettare
- 30 min di Q&A per chiarimenti
Totale tempo tuo investito: ~2 ore su 4 settimane.
Quanto costa e cosa include/non include
€800/mese
Fatturazione mensile, cancellabile con 30gg preavviso.
Include:
- ~20 ore testing su staging
- Report strutturato fine mese
- Template checklist UX (personalizzabile)
- Comunicazione asincrona illimitata
Non include:
- Accesso produzione (solo staging)
- Testing performance/security
- Redesign o modifiche UI
- Support utenti finali
Prerequisito: Devi avere ambiente staging funzionante. Non faccio testing su localhost o mockup.
Per chi NON è questo servizio
Trasparenza totale. Non ti serve se:
- Hai già UX researcher in team che fa usability testing regolarmente → Continua così, stai facendo la cosa giusta
- Hai budget per assumere UX designer full-time → Investi lì, è più efficace
- Il prodotto è in fase concept (pre-sviluppo) → Ti serve UX research, non QA
- Cerchi qualcuno che “sistemi” il design → Non tocco UI, solo segnalo problemi
Ti serve se:
- Hai saltato UX research e ora stai per rilasciare
- Non hai competenze UX in team
- Vuoi ridurre bug di esperienza in produzione
- Il supporto clienti riceve ticket tipo “Non riesco a…” e nessuno sa perché
Il ROI reale
Non ti dico “risparmierai 50k€” perché non lo so. Dipende da troppi fattori.
Quello che so è questo:
- 1 bug critico UX in produzione (es. checkout non completabile in edge case) = 4-8 ore dev urgente + stress + reputazione
- 1 mese di QA UX = €800, intercetta 5-15 problemi prima del release
Fai i conti tu. Se rilasci ogni 2 settimane con utenti reali sopra, probabilmente ti conviene. Se rilasci una volta l’anno con 10 beta tester interni, forse no.
Partiamo?
Se vuoi attivare un mese pilota, scrivimi. Ti mando:
- Template checklist (anonimi ma reali da progetti passati)
- Report esempio (dati oscurati)
- 3 domande per capire se ha senso per il tuo caso
Zero pressione. Se dopo aver visto i materiali pensi “Non fa per me”, nessun problema. Preferisco 10 “no grazie” che 1 cliente insoddisfatto perché aveva aspettative sbagliate.
Contatto: info@mirandagiaccon.it
P.S. — Se stai pensando “Ma io non ho saltato la UX, ho fatto tutto giusto”, questo articolo non è per te. Continua così. Questo è per chi sa di aver skippato step e vuole almeno un safety net prima del go-live.
e 
, come i software che progetterò per te!