{"id":509,"date":"2015-01-06T09:21:18","date_gmt":"2015-01-06T08:21:18","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/user-testing-collaborativo-meno-preconcetti-migliore-ricerca\/"},"modified":"2015-01-06T09:21:18","modified_gmt":"2015-01-06T08:21:18","slug":"user-testing-collaborativo-meno-preconcetti-migliore-ricerca","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/user-testing-collaborativo-meno-preconcetti-migliore-ricerca\/","title":{"rendered":"User Testing collaborativo: meno preconcetti, migliore ricerca"},"content":{"rendered":"

Ho sempre lavorato in piccoli product team che facevano affidamento sul guerrilla user testing<\/a>. Il nostro obiettivo era reclutare il numero ottimale di partecipanti<\/a> per questi test. Ci assicuravamo che la fascia di popolazione riflettesse il nostro pubblico di riferimento. Usavamo un approccio informale per incoraggiare un comportamento pi\u00f9 naturale e per ridurre l’effetto dei pregiudizi<\/a> a cui potessero essere inclini i partecipanti.<\/p>\n

Ma sapete di cosa non avevamo quasi mai parlato? Di noi stessi. Dopo tutto, stavamo valutando un lavoro in cui eravamo coinvolti in maniera personale ed emotiva. A volte mi sono trovata a mettere in discussione quanto fossero davvero oggettivi i nostri risultati.<\/p>\n

\u00c8 venuto fuori che probabilmente non lo erano.<\/p>\n

In \u201cUsability Problem Description and the Evaluator Effect in Usability Testing<\/a>\u201d, Miranda G. Capra identifica una tendenza nella comunit\u00e0 del Regno Unito a concentrarsi sugli utenti quando si parla di test, mentre raramente si parla del ruolo del valutatore. L’assunzione \u00e8 che se gli stessi utenti fanno gli stessi task, i problemi riportati dovrebbero essere gli stessi indipendentemente da chi li valuta.<\/p>\n

Tuttavia, quando Capra studi\u00f2 44 valutazioni di professionisti dell’usabilit\u00e0 di sessioni pre-registrate, non osserv\u00f2 questo. I valutatori, composti da ricercatori esperti e studenti laureati, riportarono problemi che si sovrapponevano con una frequenza inaspettatamente bassa, solo il 22%. Diversi valutatori trovarono diversi problemi e assegnarono diversi livelli di severit\u00e0 a quelli. Concluse che il ruolo del valutatore era pi\u00f9 importante di quanto non fosse stato riconosciuto nella community del design e dell’UX.<\/p>\n

Se non si sono potuti raggiungere risultati oggettivi anche da professionisti dell’usabilit\u00e0 che stavano valutando le stesse registrazioni, cosa possiamo aspettarci da team non specializzati che pianificano, conducono e valutano i test utente?<\/p>\n

\n

Non si pu\u00f2 evitare di essere parziali<\/h2>\n

Da persone completamente immerse nel progetto, siamo soggetti a molti parzialit\u00e0 cognitive<\/a> che possono influenzare i risultati in qualunque fase della ricerca, dalla pianificazione all’analisi. Il confirmation bias<\/a> tra i valutatori inesperti \u00e8 comune. Questo ci porta a formulare domande che \u00e8 pi\u00f9 probabile che confermino quello che gi\u00e0 pensiamo o che diano inconsciamente priorit\u00e0 a certe risposte e ne ignorino altre. L’ho fatto io stessa e lo vedo anche nei miei colleghi. Per esempio, una volta avevo un collega che era particolarmente attivo nell’introdurre delle funzionalit\u00e0 di ricerca. Nonostante il fatto che solo una persona che aveva risposto aveva commentato della mancanza della ricerca, finirono il processo di test genuinamente convinti che la “maggior parte” delle persone stesse cercando la ricerca.<\/p>\n

Tutti noi vogliamo che la ricerca fornisca una guida affidabile per i nostri team. La maggior parte di noi non distorcerebbe volontariamente i dati, ma l’imparzialit\u00e0 viene spesso introdotta senza saperlo<\/a>, senza che il ricercatore ne sia cosciente. Nello scenario peggiore, risultati distorti o ingannevoli possono fuorviare la direzione del prodotto e danno al team un falsa fiducia nella sua decisione.<\/p>\n

La ricerca di Capra e altri studi hanno mostrato che il preconcetto si palesa di solito nella fase di pianificazione (quando si abbozzano i task e gli scenari di testing), durante la sessione stessa (quando si interagisce con i partecipanti e se ne osserva il comportamento) e nella fase di analisi (quando si interpretano i dati e si tirano le conclusioni). Sapendo questo, il mio team in FutureLearn<\/a>, una piattaforma online di learning, si \u00e8 proposto di ridurre l’evenienza di preconcetti nella nostra ricerca, oltre a continuare a fare la ricerca rapida ed efficiente di cui il nostro team ha bisogno per progredire. Mi piacerebbe condividere con voi il processo e le tecniche che abbiamo stabilito.<\/p>\n<\/div>\n

\n

Fate l’inventario delle vostre convinzioni e assunzioni<\/h2>\n

Prima di cominciare riconoscete onestamente le vostre convinzioni personali<\/a>, in particolar modo se state testando qualcosa verso cui nutrite \u201csentimenti forti\u201d. Registrate tali convinzioni e assunzioni e poi trascrivetele.<\/p>\n

Pensate che il pulsante “Save” dovrebbe stare sopra alla form piuttosto che alla fine dove non si vede? Vi hanno sempre dato fastidio i menu che scompaiono da un lato? Siete particolarmente compiaciuti e orgogliosi del nuovo elegante controllo che avete realizzato? Siete convinti che questa label confonda e che verr\u00e0 malinterpretata? Prendendo nota di queste cose, ne avrete maggiore coscienza. Se possibile, lasciate che sia qualcun altro a condurre quando verranno fatti i test in queste aree.<\/p>\n<\/div>\n

\n

Coinvolgete pi\u00f9 revisori durante la pianificazione<\/h2>\n

In FutureLearn, la nostra ricerca \u00e8 molto collaborativa: tutti nel team di prodotto (e spesso negli altri team) sono coinvolti attivamente. Cerchiamo di invitare diverse persone ad ogni attivit\u00e0 di ricerca e di includere svariati ruoli e competenze: designer, developer, project manager, produttori di contenuto, supporto e marketing.<\/p>\n

Cominciamo col condividere un piano di test in due parti in un Google Doc con chiunque si offra volontario per partecipare. Questo include:<\/p>\n