Revisione di Usabilità e UX come Parte del QA
Se pensi che un buon design sia costoso, dovresti vedere quanto costa un cattivo design.
Dr. Ralf Speth, CEO, Jaguar Land Rover
Nell'ultimo decennio, l'esperienza utente è diventata il vero elemento distintivo tra applicazioni buone e applicazioni eccezionali.
L'aspetto tecnico della realizzazione di software è, in un certo senso, un problema ormai risolto. Le reali possibilità di un successo fuori misura con prodotti software risiedono nella UX. La prossima killer app avrà un'interfaccia immediatamente utilizzabile. Questo ha portato a un approccio orientato alla ricerca e incentrato sulla UX nello sviluppo dei prodotti.
I risultati di questa attenzione parlano da soli.
Ad esempio, ogni dollaro investito in UX genera 100 dollari di ritorno, secondo un rapporto di Forrester Research. Inoltre, su un periodo di 10 anni, uno studio mostra che le performance finanziarie delle aziende guidate dal design superano quelle dell'S&P del 219%.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
C'è anche la leggendaria storia di come il semplice cambiamento del testo su un solo pulsante abbia aggiunto 300 milioni di dollari alle vendite di una società di e-commerce in un solo anno!
Tuttavia, nonostante tutto questo entusiasmo e clamore, per ogni applicazione con una grande esperienza utente ce ne sono diverse che risultano carenti, o fortemente carenti, in quel reparto. Quelle terribili sono facili da individuare; ti fanno venire voglia di prendere a pugni lo schermo del laptop o di lanciare il telefono fuori dalla finestra. Di quelle si occupa Darwin.
La vera sfida sono le app con una UX "così così". Sono proprio quelle che danno la proverbiale "scheggia nella mente", esperienze di cui non riesci a capire il motivo per cui non ti piacciono!
Ti sento dire: "Tutto questo lo sappiamo già; sto leggendo The QA Lead, per l'amor del cielo, quindi cosa c'entra con me?" Sto arrivando a quello.
L'Importanza della UX
Nei miei primi anni da manager di team di ingegneria, stavamo lavorando a un grande progetto di software per uno dei nostri clienti. Era parte di una strategia più ampia di trasformazione digitale che veniva implementata per quel cliente. Si trattava di un tipico team tecnico composto principalmente da sviluppatori software e ingegneri QA che lavoravano secondo Scrum con sprint di 2 settimane.
C'era un piccolo team UX ma, per lo più, era condiviso tra più progetti. In genere, i ragazzi della UX partecipavano ai meeting del team nelle fasi iniziali del progetto ma, una volta che il cliente approvava il design visivo, consegnavano tutti i template per la grafica e i flussi, poi passavano ad altri progetti.
Durante la prima demo di sprint, il cliente sembrava principalmente preoccupato dal fatto che il design visivo e l'interfaccia utente non corrispondessero esattamente ai template di design. C'era anche una discrepanza tra la funzionalità proposta e quella effettivamente realizzata.
Attenzione, il divario non era grande ma, nonostante i tentativi di rassicurare il cliente che gli aspetti UX sarebbero stati sistemati in uno degli sprint successivi, il suo linguaggio del corpo dimostrava che la cosa non gli piaceva.
Per fortuna, la nostra QA lead si fece avanti, dicendo che si trattava di un'anomalia e che non sarebbe più successo. E poi fece qualcosa di straordinario. Ecco cosa fece, in breve:
- Si prese la responsabilità di approfondire le sue conoscenze sulla UX leggendo in modo intensivo.
- Fece personalmente una revisione euristica di base della UX della funzionalità consegnata, parlò con il team UX e chiese aiuto dove necessario.
- Creò nuovi task in JIRA per correggere il delta tra quanto promesso e quanto consegnato—in ottica UX.
- Organizzò una call con il nostro Chief UX e ottenne la sua approvazione affinché fosse istituito un nuovo processo che prevedeva la correzione degli aspetti visivi dell'applicazione in ogni sprint e non solo alla fine.
- Infine, fece sì che anche il nostro team QA comprendesse le basi della UX, in modo che potessero individuare problemi evidenti e aiutare il team a risolverli in anticipo.
Il tocco finale? Alla demo dello sprint successivo, il product owner/cliente era tutto sorrisi e dopo alcuni mesi, la nostra QA lead è stata promossa a QA Manager! 😉
Visione Romantica Versus Classica Della Realtà
Tutto questo episodio mi ha fatto riflettere sull'enorme distanza tra il modo in cui noi tecnici vediamo un'applicazione e come la vedono i clienti e gli utenti. Robert Pirsig, nel suo libro seminale Lo Zen e l'arte della manutenzione della motocicletta, parla di due prospettive della realtà: classica e romantica.
Secondo Pirsig, coloro che adottano principalmente una prospettiva romantica osservano le cose e le giudicano in base a come appaiono. Sono interessati principalmente a come sono le cose e non si preoccupano di come funzionano — l’ordine sottostante. Questa è la metà artistica della dicotomia arte/scienza.
D’altra parte, noi ingegneri & scienziati aderiamo alla visione classica in cui la bellezza si trova nei meccanismi che stanno alla base della forma esteriore. Gli ingegneri riescono a vedere bellezza nel codice python, o sotto il cofano di un’auto, che appare invece sgradevole a chi ha una visione romantica.
Come in ogni altra cosa, ovviamente non si tratta di una classificazione binaria ma di un continuum nel quale la maggior parte di noi preferisce principalmente una prospettiva.
Ci sono alcune implicazioni interessanti in questo modo di classificare il mondo:
1. La prospettiva dominante della maggior parte delle persone di default è o classica o romantica, non entrambe.
2. Le persone — pensiamo a clienti, interni o esterni — con la prospettiva romantica sono di gran lunga più numerose di quelle con prospettiva classica. Se ti è mai capitato di fare assistenza tecnica a familiari o amici, sai benissimo di cosa sto parlando!
3. Pochissimi riescono a cambiare modalità e, anche per loro, è un’attività che richiede impegno.
4. Realtà = classico + romantico. Non sono mutualmente esclusivi. Entrambi sono aspetti essenziali dell’insieme. La bellezza è funzionale. La funzione può essere bella.
Prendi i fiori, ad esempio. Hanno motivi talmente belli da sembrare privi di funzione. Eppure la bellezza che notiamo nei fiori ha una struttura sottostante radicata nella matematica: la successione di Fibonacci governa la struttura e i motivi che vediamo nei fiori. In natura, struttura e bellezza eterea vanno di pari passo.
E non si tratta solo di bellezza. La disposizione dei semi in un girasole segue la successione di Fibonacci e la Sezione Aurea per adattare il maggior numero possibile di semi nel fiore. Gli stessi principi si applicano all’ingegneria e alla user experience.
Questo, infine, ci porta al nocciolo di questo articolo: le persone che si occupano di quality engineering sono nella posizione ideale per beneficiare di entrambe queste prospettive apparentemente in competizione.
Il ruolo della QA Software in UX / Usabilità
Come professionista del testing, hai molta più esperienza con le interfacce rispetto allo sviluppatore o all’utente medio.
Hai testato così tante applicazioni con rigore e ripetutamente (fino alla nausea!) che potresti aver raggiunto il livello di pensiero di ordine superiore, o "4D" per quanto riguarda la UX, come il proverbiale grande maestro di scacchi che ragiona per posizioni, a differenza del sottoscritto che fatica a capire quale pezzo muovere! ;-)
Ed è per questo che, nonostante il grande spostamento verso l’automazione — una scelta più che valida, senza dubbio — c’è comunque da dire qualcosa a favore di un po’ di testing manuale. In fin dei conti, se a utilizzare un’applicazione saranno delle persone, ha senso inserire anche una prospettiva umana nel testing.
Come condurre una revisione UX / usabilità come test engineer
Se l’assicurazione qualità deve tenere conto dell’UX, bisogna cominciare in parallelo alla fase di design, cioè all’inizio del ciclo di vita. Ecco i passaggi che puoi seguire per inserire la revisione UX nei tuoi test e diventare un polimatematico della QA!
Euristiche di usabilità per la progettazione dell’interfaccia utente
Familiarizza con le 10 linee guida generali per la progettazione dell’interazione di Jakob Nielsen. Questo insieme di principi rappresenta un riferimento affidabile per qualsiasi revisione di usabilità. Considera questi principi sia nelle discussioni con il team UX che nella tua strategia di test. Puoi anche consultare uno dei tanti corsi base su usabilità e UX design.
Impara i principi dell’accessibilità
Potresti aver già effettuato test di accessibilità come parte del tuo piano di test in passato, ma comprendere i principi che stanno dietro all’accessibilità—percepibile, operabile, comprensibile, robusto—ti darà la capacità di vedere ciò che altri potrebbero non notare.
Il Team UX è il tuo nuovo punto di riferimento
Non essere un estraneo: conosci il team UX del progetto. Collabora con loro. Condividi il tuo piano di test e ricevi feedback su cosa potresti includere dal punto di vista dell'esperienza utente.
I vantaggi di questa interazione sono reciproci: il tuo piano di test darà al team di design informazioni sulla fattibilità delle funzionalità progettuali che desiderano proporre. Come QA lead, la tua collaborazione con il team UX deve essere stretta quanto quella con gli sviluppatori.
Includi gli Analytics nel tuo Piano di Test
Le analisi sugli utenti del prodotto che stai testando sono una miniera d’oro di informazioni per i tester. Gli analytics possono aiutarti a identificare aree di rischio e comportamenti degli utenti. Queste informazioni, a loro volta, possono aiutarti a individuare e dare priorità alle correzioni il prima possibile nel ciclo di vita del prodotto.
Fai Shift Left fino a non poter andare oltre
Il prodotto che stai testando è come un bambino. Devi assicurarti che riceva il sostegno necessario fin dalla sua concezione. Vai fino all’inizio.
Prima dello Sviluppo
Testa già in fase di design, appena il prototipo è pronto. Usa la tua esperienza con applicazioni e la conoscenza dei principi di usabilità e delle linee guida sull’accessibilità per verificare se è necessario apportare modifiche PRIMA che il prodotto passi allo sviluppo.
Se la QA non fa ancora parte della fase di design, fai in modo che vengano coinvolti, se possibile.
Testing Manuale Mirato
Ripercorri l’intera esperienza d’uso del prodotto dall’inizio alla fine come parte del test manuale. Concentrati sul porre le domande giuste, pensando sia come utente che come QA Engineer.
Inizia facendo un passo indietro e osservando il prodotto da una prospettiva più ampia. L’esperienza ti piace?
Poi analizza da vicino. È facile da usare? I flussi sono ovvi e intuitivi? Sono tediosi e lenti? Ci sono sovrapposizioni o duplicazioni di azioni che potrebbero risultare fastidiose per l’utente? Il design è usabile su diversi formati di schermo?
Infine
Il futuro del lavoro appartiene a chi possiede un insieme di competenze complementari che sono quasi impossibili da replicare con le macchine (ma dai un’occhiata al mio articolo su IA nell’automazione dei test per vedere cosa possono fare).
Diventare un QA poliedrico con competenze UX potrebbe essere un ottimo modo per valorizzare le tue capacità naturali e la tua esperienza, aggiungendo molto valore aggiuntivo senza troppi sforzi o senza uscire troppo fuori dagli schemi.
È qualcosa che ti entusiasma? O pensi che la UX sia solo marginale in questo campo? Fammelo sapere nei commenti qui sotto.
Se sei pronto ad approfondire, ecco un podcast che puoi leggere/ascoltare: COME IL SOFTWARE OPEN SOURCE SEMPLIFICA L’INTEGRAZIONE NELL’INGEGNERIA DELL’AUTOMAZIONE (CON JAMES WALKER E SANJAY KUMAR)
