Cum se configurează smartphone-uri și PC-uri. Portal informativ
  • Acasă
  • Sfat
  • Testare de utilizare pe cont propriu. Colectarea datelor cantitative despre comportamentul utilizatorului

Testare de utilizare pe cont propriu. Colectarea datelor cantitative despre comportamentul utilizatorului

) există o etapă de evaluare a designului, în această etapă pot fi efectuate teste de utilizare de înaltă calitate.

Am fost forțat să scriu acest articol din cauza problemelor apărute când făceam teste de utilizare. Sper că pot ajuta pe cineva să stabilească cu mai multă precizie când să folosească testarea de utilizare și cum să evite unele dintre probleme atunci când o efectuează.

Reproiectarea site-ului

Când merită să faceți teste de utilizare și ce o precede?

În cazul unui site web deja dezvoltat, problema efectuării testelor de utilizare apare atunci când simțiți sau descoperiți că ceva nu este în regulă cu site-ul. În orice caz, trebuie să instalați Google Analytics(carte: Google Analytics. Analiza profesională a traficului site-ului) sau alt serviciu de analiză a vizitelor pe site. Nu voi vorbi despre de ce ar trebui să instalați un astfel de serviciu, deoarece subiectul a fost epuizat de mult și nu recomandă instalarea servicii similare doar leneș. După instalarea Google Analytics, aveți deja date specifice despre statisticile vizitelor, punctele de intrare și ieșire ale vizitatorilor site-ului și alte informații.

Următorul pas ar trebui să fie definirea KPI-urilor (Wikipedia: Key Performance Indicators - key performance indicators). Este necesar să se analizeze ceea ce este important pentru afacere și să se determine obiectivele pe care site-urile trebuie să le atingă.

Exemplu: pentru unii pot fi comenzi de marfa, pentru altii pot fi cereri prin formularul de feedback cu orice intrebare etc.

Dacă până în acest moment recomandările au fost obligatorii, adică în orice caz, acești pași vor ajuta la dezvoltarea și promovarea site-ului, atunci vin recomandări ulterioare dacă înțelegeți cu adevărat că site-ul nu este eficient.

Al treilea pas este identificarea directă a paginilor și funcțiilor cu probleme. Pur și simplu efectuarea testării de utilizare este ineficientă, trebuie să înțelegeți unde apar problemele, pe ce pagină, cu ce funcție și apoi să efectuați teste pentru a determina exact ce este greșit pe pagină și cum să o rezolvați. Google Analytics vă va ajuta din nou, aici puteți determina ce pagini părăsesc utilizatorii, ce pagini sunt ignorate și ce funcții nu sunt utilizate.

Pregătirea pentru testarea de utilizare

Deci, în acest moment s-a stabilit deja că site-ul necesită reproiectare am găsit pagini și funcții cu care utilizatorii au probleme. Tot ce rămâne este să înțelegem de ce utilizatorii au probleme și cum să le rezolvi.

Al patrulea pas ar trebui să fie formarea de ipoteze despre ce este în neregulă cu pagina, iar pe baza acestuia este necesar să se determine metrici (Wikipedia: ISO 9126 - Software Product Evaluation) prin care vor fi testate funcțiile (există un expert). metoda de evaluare in care expertul propune ipoteze pentru imbunatatirea interfetei site-ului si, pe baza acestora, site-ul este reproiectat, cu toate acestea, se poate verifica daca aceasta ipoteza este cu adevarat adevarata doar dupa implementarea modificarilor, ceea ce presupune un cost ridicat de eroare).

Exemplu: cu folosind Google analytics, am stabilit că utilizatorii accesează pagina de înregistrare, dar nu o completează. Este posibil ca utilizatorii să nu poată afla ce informații să introducă în câmpuri sau să nu știe ce să facă în continuare după completarea câmpurilor. Aceasta înseamnă că trebuie să testăm această pagină pe baza valorilor de înțelegere. mesajele de sistemși secvența operațională.

După stabilirea metricilor prin care vom testa zonele cu probleme de pe site, este necesar să se determine caracterul și scenariul de lucru (carte: Alan Cooper on the Interface. Fundamentals of Interaction Design) conform căruia se va efectua testarea de uzabilitate. Acest pas necesar pentru a atrage respondenții potriviți și pentru a selecta o sarcină pentru testarea gradului de utilizare. Dacă acest punct este ratat, atunci un respondent care nu este utilizatorul țintă poate trece cu succes prin zona cu probleme, iar utilizatorul care utilizează efectiv această pagină va avea probleme reale. mari probleme. Rezultatul va fi o reproiectare a interfeței fără a lua în considerare datele, dar problema va rămâne. Definirea precisă a scenariului va ajuta să îi ofere respondentului sarcina potrivită. Adică, dacă sarcina este de a cumpăra un telefon mobil, iar respondentul nu se înregistrează deloc (și testăm înregistrarea în mod special), atunci testarea de utilizare este inutilă.

Notă: selectați scenariul astfel încât să fie testate cât mai multe zone cu probleme.

Urmează selecția respondenților în funcție de personajul selectat. Cu cât respondentul se potrivește mai mult cu portretul personajului, cu atât mai bine. Un număr suficient de respondenți este de 5-8 persoane. În alegerea cantității, mă bazez pe recomandarea lui Jakob Nielsen și pe propria mea experiență.

Imediat înainte de testarea de utilizare în sine, solicitați respondentului să completeze un chestionar pentru a verifica dacă personajul selectat și respondentul corespund caracteristicilor cerute. Efectuați un briefing introductiv, în timpul căruia descrieți contextul utilizării site-ului și sarcina (cărți: Web Design: cartea lui Steve Krug sau „Don’t Make Me Think!”).

Exemplu de misiune: caută ceva nou telefon mobil Ai ajuns pe acest site printr-un motor de căutare. Găsiți telefonul de care aveți nevoie (de asemenea, cereți respondentului să descrie telefonul pe care l-ar căuta).

Efectuarea în sine a testării de utilizare (program: Usability Studio) nu este ceea ce pare sarcină dificilă. Ai nevoie de un laptop cu cameră și mai multe programe pentru a capta mișcările utilizatorilor și a înregistra activitatea pe ecran. Cereți respondentului să comenteze toate acțiunile și emoțiile sale. După cum arată practica, el va face oricum acest lucru (și acest lucru nu este surprinzător, deoarece chiar și acasă, utilizatorilor le place adesea să mustre sau, dimpotrivă, să îngrijească diverse forme și alte elemente de pe site-uri).

După finalizarea testului, intervievați respondentul despre impresiile sale, ce dificultăți a întâmpinat și ce i s-a părut incomod. Nu recomand să folosiți datele sondajului ca lege pentru a schimba ceva ce nu-i place. Trebuie să asculți utilizatorii, dar să fii foarte neîncrezător în ei. opinie subiectiva. Este mai bine dacă, pe baza rezultatelor sondajului, apare o ipoteză cu privire la necesitatea schimbării interfețelor, a adăuga un alt element la lista zonelor cu probleme și a-l testa în următoarea iterație.

Prelucrarea datelor de testare a gradului de utilizare

În continuare, trebuie să vizualizați materialele video colectate, să analizați rezultatele testării de utilizare și să determinați cerințele pentru interfața pentru reproiectare (carte: Web design. Ușurința de utilizare a site-urilor Web). Modificările care vor fi făcute pe baza anumitor cerințe ar trebui verificate în timpul următoarelor teste de utilizare. Numărul de astfel de iterații ar trebui să depindă în mare măsură de obiectivele și bugetul alocat pentru reproiectarea site-ului.

Exemple: adăugați sfaturi în formularul de înregistrare, evidențiați butonul de achiziție, adăugați câmpul „platformă” la formular pentru selectarea unui telefon după parametri etc.

Proiectare de site-uri

Dacă proiectarea a fost realizată conform standardului ISO 9241-210, atunci efectuarea testelor de utilizare nu ar trebui să fie un proces costisitor și consumator de timp datorită bazei analitice pregătite. Principalele etape ale testării de utilizare atunci când proiectați un site web de la zero rămân aceleași cu cele descrise mai sus, cu excepția unor aspecte:
  1. Formarea de ipoteze
  2. Definirea valorilor pentru testare
  3. Definirea personajelor și scenariilor
  4. Selectarea respondenților
  5. Completarea formularului
  6. Instructaj de debut
  7. Efectuarea testelor de utilizare
  8. Sondajul respondenților
  9. Analiza rezultatelor
  10. Determinarea cerințelor pentru proiectarea site-ului
Principala problemă pe care am întâlnit-o cu testarea de utilizare în acest caz a fost testarea unui design static, mai degrabă decât a unui site web cu drepturi depline. În realitate, este mai bine să testați un site proiectat și chiar programat, dar costul iterației designului va fi mare. Cu cât se găsește mai devreme o problemă în interfață, cu atât costul remedierii acesteia este mai mic. Cum se efectuează testarea completă de utilizare a unei imagini statice? Soluția la această problemă a fost programul Axure. Cea mai ieftină și de succes modalitate a fost plasarea artificială a link-urilor pe o imagine statică a designului site-ului și generarea acesteia în pagina HTML. Aceasta metoda face posibilă testarea site-ului fără a cheltui resurse chiar și pentru aspect. Desigur, paginile generate nu au aproape nicio funcționalitate, se afișează doar într-o anumită formă, dar acest lucru este suficient pentru a identifica un număr mai mare de probleme.

Nu iau în considerare opțiunea testării cantitative de utilizare, deoarece ne permite să determinăm ergonomia generală a interfeței, dar nu ne permite să stabilim ce probleme apar, de ce și cum să le remediam.

P.S. Aștept cu nerăbdare critici constructive cu privire la soluția propusă pentru testarea de înaltă calitate a utilizării designului, deoarece nu am văzut niciodată o astfel de soluție nicăieri. Dacă aveți sugestii despre cum să efectuați teste de utilizare de înaltă calitate, ieftin și vesel, voi fi bucuros să o citesc.

Pregătire, interviuri și colectare de date

La marcaje

Natalia Sprogis, șefa de cercetare UX la Mail.Ru Group, a vorbit pe blogul companiei despre Habrahabr despre pregătirea și desfășurarea testelor de utilizare: ce să includeți în scriptul de testare, cum să alegeți o metodă de colectare a datelor, să creați sarcini și să colectați impresiile respondenților .

Un plan de testare este, pe de o parte, un set de sarcini, întrebări și chestionare pe care le oferiți fiecărui respondent, iar pe de altă parte, este baza metodologică a studiului: metrici și ipoteze pe care le testați și le înregistrați, instrumentele selectate.

Testarea este cu adevărat necesară?

În primul rând, trebuie să fii sigur că în această etapă proiectul are nevoie de testare de utilizare. Prin urmare, clarificați în ce scop vă contactează echipa de proiect. Testarea de utilizare nu este atotputernică și, de la început, trebuie să înțelegeți ce poate aduce produsului. Pregătește-ți imediat echipa de proiect pentru a ști la ce întrebări poți răspunde și la care nu poți. Au existat cazuri în care fie le-am oferit clienților o altă metodă (de exemplu, interviurile aprofundate sau studiile de jurnal sunt mai bune acum), fie le-am recomandat să abandoneze complet studiul și să facă un test divizat.

De exemplu, nu testăm niciodată „atractivitatea” unei caracteristici sau a unei opțiuni de design în cercetarea calitativă. Putem colecta feedback de la utilizatori, dar există riscul prea mare ca răspunsurile lor să fie influențate de dezirabilitatea socială. Oamenii sunt întotdeauna înclinați să spună că ar folosi chiar și ceea ce nu vor folosi. Și dimensiunea mică a eșantionului nu ne permite să avem încredere în astfel de răspunsuri. De exemplu, am avut o experiență nereușită la testarea paginilor de destinație pentru jocuri: pagina de destinație aleasă ca cea mai atractivă în test a avut rezultate mult mai proaste în timpul testării A/B.

Testarea prototipurilor și a conceptelor are, de asemenea, o serie de limitări. Când planificați, trebuie să înțelegeți ce puteți obține cu adevărat din acest test. Este grozav atunci când un proiect are posibilitatea de a testa prototipuri sau modele înainte de implementare. Cu toate acestea, cu cât prototipul este mai puțin detaliat și funcțional, cu atât nivelul de abstractizare al respondentului este mai mare, cu atât se pot obține mai puține date din test. Cel mai bine este să testați prototipurile pentru a identifica problemele cu denumirea și metaforele icoanelor, adică toate problemele de înțelegere. Capacitatea de a testa orice dincolo de aceasta depinde în mare măsură de natura proiectului și de detaliul prototipului.

Baza pentru scrierea unui script de testare a utilizabilității

Planificarea testului începe nu cu scrierea textului sarcinilor, ci cu o elaborare detaliată a obiectivelor și întrebărilor de cercetare împreună cu echipa de proiect. Iată baza pentru a face un plan:

Scenarii importante. Acestea sunt acele scenarii de utilizator (sarcini sau cazuri de utilizare) care afectează afacerea sau sunt legate de scopul testării. Chiar dacă echipa suspectează probleme în anumite zone, deseori merită să verificați cazurile subiacente. În acest caz, următoarele scenarii pot fi considerate importante pentru test:

  • cele mai frecvente (de exemplu, trimiterea unui mesaj în messenger);
  • afectarea obiectivelor de afaceri (de exemplu, lucrul cu un formular de plată);
  • legate de actualizare (cei afectați de reproiectare sau introducerea de noi funcționalități).

probleme cunoscute Adesea, cercetarea trebuie să ofere răspunsuri la cauzele problemelor de afaceri ale unui serviciu. De exemplu, producătorul este îngrijorat de fluxul mare de jucători după prima oră de joc. Și uneori, zonele cu probleme ale interfeței sunt deja cunoscute de echipă și trebuie să aduni detalii și detalii. De exemplu, serviciul de asistență este adesea contactat cu întrebări despre forma de plată.

Întrebări. Echipa poate avea și întrebări de cercetare: de exemplu, utilizatorii observă un banner publicitar Servicii aditionale; O anumită secțiune este numită clar?

Ipoteze.În asta sunt traduse problemele și întrebările cunoscute ale echipei. Este bine dacă clientul vine la tine cu ipoteze gata făcute - de exemplu, „Clienții noștri plătesc doar telefonic cu comision. Este posibil ca utilizatorii să nu mai vadă alegerea mod profitabil plată." Dacă nu există ipoteze, dar există doar dorința de a testa proiectul în mod abstract „pentru utilizare”, sarcina dumneavoastră este să formulați aceste ipoteze.

Gândiți-vă împreună cu echipa de proiect la locurile în care utilizatorii nu se comportă conform așteptărilor (dacă există astfel de informații). Aflați dacă există elemente de design care au fost dezbătute mult și s-ar putea dovedi problematice. Efectuați propriul audit al produsului pentru a găsi probleme potențiale pentru utilizatori, care sunt importante de testat. Toate acestea vă vor ajuta să faceți o listă cu acele elemente (sarcini, întrebări, verificări) care ar trebui incluse în scriptul final.

Metoda de colectare a datelor

Este important să luați în considerare modul în care veți colecta date despre ceea ce se întâmplă în timpul testului pentru o analiză ulterioară. Următoarele opțiuni sunt utilizate în mod tradițional:

Observare.În timpul îndeplinirii sarcinilor, respondentul rămâne singur cu produsul și se comportă așa cum crede de cuviință. Comentariile respondentului sunt colectate prin chestionare și comunicarea cu moderatorul după test. Aceasta este cea mai „curată” metodă; oferă un comportament mai natural al respondentului și capacitatea de a măsura corect o serie de metrici (de exemplu, timpul de finalizare a unei sarcini).

Cu toate acestea, există o mulțime de date calitative utile în culise. După ce ați văzut acest comportament al unui respondent, nu puteți înțelege de ce acționează în acest fel. Desigur, puteți întreba despre asta la sfârșitul testului, dar cel mai probabil respondentul își va aminti bine doar ultima sarcină. În plus, în timpul îndeplinirii sarcinilor, părerea lui despre sistem se poate schimba și veți obține doar imaginea finală, și nu primele impresii.

Gândește cu voce tare (gânduri cu voce tare). Multă vreme, această metodă a fost folosită cel mai des în testarea utilizabilității. Jakob Nielsen l-a numit odată principalul instrument de evaluare a gradului de utilizare. Ideea este că îi cereți respondentului să își exprime toate gândurile care apar în timpul lucrului cu interfața și să comenteze toate acțiunile sale. Arată cam așa: „Acum voi adăuga acest articol în coșul meu. Unde e butonul? Ah, iată-o. Oh, am uitat să mă uit ce culoare era.

Metoda ajută la înțelegerea de ce utilizatorul se comportă într-un fel sau altul și ce emoții îi evocă interacțiunea curentă. Este ieftin și simplu, chiar și un cercetător fără experiență se poate descurca.

Cu toate acestea, are dezavantajele sale. În primul rând, nu este foarte natural ca oamenii să „gândească cu voce tare” tot timpul. Ei vor deveni adesea tăcuți și va trebui să le reamintiți constant să vorbească în continuare. În al doilea rând, sarcinile cu această metodă durează puțin mai mult decât în viata reala. În plus, unii respondenți încep să folosească produsul mai atent. Articulând motivele acțiunilor lor, ei încearcă să acționeze mai rațional și pur și simplu nu vor să arate ca niște idioți și este posibil să nu prinzi unele momente intuitive ale comportamentului lor.

Intervenția moderată activă. Metoda este ideală pentru testarea conceptelor și prototipurilor. În timpul îndeplinirii sarcinilor, moderatorul interacționează activ cu utilizatorul: la momentele potrivite el află motivele comportamentului său și pune întrebări clarificatoare. În unele cazuri, moderatorul poate chiar emite sarcini neplanificate care decurg din dialog.

Această metodă vă permite să colectați suma maxima date calitative. Cu toate acestea, poate fi folosit doar dacă aveți încredere în profesionalismul moderatorului dvs. Formulat incorect sau la momentul nepotrivit întrebări puse poate influența foarte mult comportamentul și impresiile respondentului și chiar invalida rezultatele testului. De asemenea, atunci când utilizați această metodă, aproape nicio măsurătoare nu poate fi măsurată.

Gândește cu voce tare retrospectivă, RTA (retrospectivă). Aceasta este o combinație a primelor două metode. Utilizatorul finalizează mai întâi toate sarcinile fără interferențe, apoi este redat un videoclip cu munca sa în fața lui, iar el comentează comportamentul său și răspunde la întrebările moderatorului. Principalul dezavantaj al metodei este că timpul de testare crește foarte mult. Cu toate acestea, există momente când este optim.

De exemplu, odată ne-am confruntat cu sarcina de a testa mai multe tipuri de mafioți (monstri de joc) într-un singur RPG. Desigur, nu am putut distrage atenția respondenților cu întrebări și nici nu-i puteam forța să comenteze acțiunile lor în timpul bătăliei. Acest lucru ar face imposibil să joci un joc în care este nevoie de concentrare pentru a câștiga. Pe de altă parte, utilizatorul cu greu și-ar putea aminti după o serie de contracții dacă a observat că toporul strălucește roșu la primul șobolan. Prin urmare, în acest test am folosit metoda RTA. Cu fiecare utilizator, am trecut în revistă bătăliile sale și am discutat ce efecte ale monștrilor a observat și cum le-a înțeles.

Încercați să vă gândiți cum să obțineți suficiente date menținând în același timp naturalețe maximă în comportamentul respondentului. În ciuda simplității și versatilității metodei „gândește cu voce tare”, care a fost mult timp cea mai populară în testarea utilizabilității, încercăm din ce în ce mai mult să o înlocuim cu observație. Dacă moderatorul vede un comportament interesant al respondentului, el va aștepta până când va finaliza sarcina și va pune o întrebare după aceea. Imediat după sarcină, este mai probabil ca respondentul să-și amintească de ce a făcut-o.

Un eye tracker ajută foarte mult în această chestiune. Văzând focalizarea atenției actuale a respondentului, puteți înțelege mai bine comportamentul acestuia fără a pune întrebări inutile. În general, eye tracker îmbunătățește semnificativ calitatea moderației, iar acest rol, în opinia mea, nu este mai puțin important decât capacitatea de a construi hitmaps.

Metrici

Metricurile sunt indicatori cantitativi ai gradului de utilizare. Ca rezultat al testării, veți obține întotdeauna un set de probleme găsite în interfață. Metricurile vă permit să înțelegeți cât de bun sau rău este totul și, de asemenea, să îl comparați cu un alt proiect sau cu versiunile anterioare ale designului.

Care sunt valorile?

Conform ISO 9241-11, principalele caracteristici ale utilizabilității sunt eficiența, productivitatea și satisfacția. Diferite valori pot fi relevante pentru proiecte diferite, dar toate sunt legate cumva de aceste trei caracteristici. Voi scrie despre cei mai des folosiți indicatori.

Îndeplinirea cu succes a sarcinilor. Puteți folosi un cod binar: a făcut față sarcinii sau a eșuat. Urmăm adesea abordarea lui Nielsen și distingem trei tipuri de evaluări de succes:

  • a finalizat sarcina practic fără probleme - 100%;
  • a întâmpinat probleme, dar a finalizat sarcina în mod independent - 50%;
  • a eșuat sarcina - 0%.

Dacă din 12 respondenți 4 au finalizat sarcina cu ușurință, 6 au avut probleme și 2 au eșuat, atunci rata medie de succes pentru această sarcină va fi de 58%.

Uneori vei întâlni o situație în care grupa mijlocie Există respondenți cu grade foarte diferite de „problematică”. De exemplu, un respondent s-a luptat cu fiecare câmp al formularului, în timp ce celălalt a făcut doar o mică greșeală la sfârșit. Îți poți da scorul la discreția ta, în funcție de ceea ce s-a întâmplat la test. De exemplu, 25% - dacă respondentul tocmai a început să finalizeze sarcina, sau 80% - dacă a făcut o greșeală minoră.

Pentru a evita prea multă subiectivitate, luați în considerare scalele de punctaj în avans, mai degrabă decât să decideți pentru fiecare respondent după test. De asemenea, merită să luați în considerare ce să faceți cu erorile. De exemplu, ați dat sarcina de a cumpăra bilete de film în proiectul Cinema Mail.Ru. Unul dintre respondenți a cumpărat din greșeală un bilet nu pentru mâine, ci pentru astăzi și nu l-a observat. Este încrezător că a îndeplinit sarcina și are un bilet în mână. Dar greșeala lui este atât de critică încât nu va intra în film, așa că i-aș da „0%”, în ciuda faptului că biletul a fost achiziționat.

Rata de succes este o măsură foarte simplă și clară și vă recomand să o folosiți dacă sarcinile dvs. au obiective clare. O privire asupra graficului de succes al sarcinii vă permite să identificați rapid cele mai problematice zone ale interfeței.

Timpul de finalizare a sarcinii. Această valoare este doar indicativă pentru comparație. Cum știi dacă un utilizator finalizează o sarcină în 30 de secunde este bine sau rău? Dar faptul că timpul a fost redus în comparație cu versiunea anterioara designul este deja bun. Sau faptul că înregistrarea pe proiectul nostru durează mai puțin decât concurenții. Există interfețe în care reducerea timpului pentru finalizarea sarcinilor este critică - de exemplu, interfața de lucru a unui angajat al unui call center.

Cu toate acestea, această măsurătoare nu este aplicabilă pentru toate sarcinile. Să ne luăm sarcina de a selecta un produs într-un magazin online. Utilizatorii ar trebui să găsească rapid filtre și alte elemente de interfață asociate cu căutarea produselor, dar procesul de selecție în sine le va lua timp diferit, și asta este complet normal. Atunci când aleg pantofi, femeile sunt gata să se uite prin 20 de pagini cu rezultatele căutării. Și asta nu înseamnă neapărat că nu au fost produse relevante pe primele pagini sau că nu au văzut filtrele. Adesea vor doar să vadă toate opțiunile.

Frecvența problemelor. Orice raport de testare a gradului de utilizare conține o listă a problemelor pe care le-au întâlnit respondenții. Numărul de respondenți care au întâmpinat o problemă este un indicator al frecvenței acesteia în cadrul testului. Această valoare poate fi utilizată numai dacă utilizatorii dvs. au efectuat exact aceleași sarcini.

Dacă au existat variații în test sau sarcinile nu au fost clar formulate, ci au fost compilate pe baza unui interviu, atunci va fi dificil de calculat frecvența. Va fi necesar nu numai să se numere pe cei care au întâlnit-o, ci și să se estimeze câți respondenți ar putea întâmpina problema (a efectuat o sarcină similară, a mers la aceeași secțiune). Cu toate acestea, această caracteristică permite echipei să înțeleagă care probleme ar trebui rezolvate mai întâi.

Satisfacția subiectivă. Acest evaluare subiectivă confortul utilizatorului sau confortul lucrului cu sistemul. Acesta este dezvăluit folosind chestionare pe care respondenții le completează în timpul sau după testare. Există chestionare standard. De exemplu, Scala de utilizare a sistemului, Chestionar de utilizare post-studiu sau Chestionar privind experiența jocurilor pentru jocuri. Sau vă puteți crea propriul chestionar.

Acestea sunt departe de singurele valori posibile. De exemplu, o listă de 10 metrici UX pe care Jeff Sauro le evidențiază. Pentru produsul dvs., valorile pot fi diferite: de exemplu, la ce nivel înțeleg respondenții regulile jocului, câte greșeli fac atunci când completează formulare lungi. Amintiți-vă că decizia de a utiliza mai multe valori impune o serie de limitări testării. Respondenții trebuie să acționeze cât mai natural posibil și în aceleași condiții. Prin urmare, ar fi bine să oferiți:

  • Puncte de plecare comune. Aceleași sarcini pentru diferiți respondenți ar trebui să înceapă din același punct de interfață. După fiecare sarcină, puteți cere respondenților să revină la pagina principală.
  • Nicio intervenție. Orice comunicare cu un moderator poate afecta valorile de performanță dacă moderatorul sugerează ceva respondentului fără să vrea și crește timpul necesar pentru a finaliza sarcina.
  • Ordinea sarcinilor. Pentru a compensa efectul de învățare în testare comparativă, asigurați-vă că modificați ordinea de introducere a produselor comparate pentru diferiți respondenți. Lăsați jumătate să înceapă cu proiectul dvs. și jumătate cu unul competitiv.
  • Criterii de succes. Gândiți-vă dinainte la ce fel de comportament considerați de succes pentru sarcină: de exemplu, este acceptabil ca respondentul să nu folosească filtre atunci când selectează un produs într-un magazin online.

Interpretarea metricilor

Amintiți-vă că testarea clasică de utilizare este un studiu calitativ, iar valorile pe care le obțineți sunt în primul rând ilustrative. Acestea oferă o imagine de ansamblu asupra diferitelor scenarii dintr-un produs, permițându-vă să vedeți punctele dureroase. De exemplu, crearea unui cont provoacă mai multe dificultăți decât înregistrarea în sistem. Ele pot arăta dinamica schimbării dacă le măsurați în mod regulat. Adică, valorile ne permit să înțelegem că noul design ne permite să îndeplinim sarcina mai rapid. Aceste relații sunt mult mai indicative și de încredere decât valorile absolute ale valorilor găsite.

Jeff Sauro, un expert statistic în cercetarea UX, sfătuiește să nu reprezinte valorile ca medii, ci să folosești întotdeauna intervale de încredere. Acest lucru este mult mai corect, mai ales dacă există variații în rezultatele respondenților. Pentru a face acest lucru, puteți folosi calculatoarele sale online gratuite: pentru succes și pentru timpul de finalizare a sarcinilor. Nu te poți lipsi de procesarea statistică atunci când compari rezultatele.

Când sunt necesare valorile?

Nu toate rapoartele de testare a gradului de utilizare conțin valori. Colectarea și analiza lor necesită timp și impun limitări metodelor de testare. Iată cazurile în care sunt cu adevărat necesare:

  • Dovedi. Adesea este nevoie să se demonstreze că trebuie făcute modificări unui produs, mai ales în companiile mari. Pentru factorii de decizie, numerele sunt vizuale, ușor de înțeles și familiare. Când arăți că 10 din 12 respondenți nu au putut să plătească pentru un articol sau că înregistrarea în sistem durează în medie de două ori mai mult decât concurenții, se acordă rezultatelor cercetării mai multă pondere.
  • Comparaţie. Dacă vă comparați produsul cu alții de pe piață, aveți nevoie și de valori. În caz contrar, vei vedea avantajele și dezavantajele diferitelor proiecte, dar nu vei putea evalua unde se situează produsul tău printre ele.
  • Vezi modificările. Valorile sunt bune pentru testarea regulată a aceluiași produs după ce au fost făcute modificări. Ele vă permit să vedeți progresul după reproiectare și să acordați atenție acelor locuri care au rămas fără îmbunătățiri. Puteți utiliza din nou acești indicatori ca bază de dovezi care vor arăta managementului ponderea investițiilor în reproiectare. Sau doar pentru a înțelege că ai obținut rezultate și mergi în direcția bună.
  • Ilustrați, puneți un accent. Numerele funcționează bine pentru a ilustra probleme importante. Uneori le numărăm pentru cele mai izbitoare și importante momente ale testului, chiar dacă nu folosim metrici în toate sarcinile.

Cu toate acestea, nu folosim valori în fiecare test. Te poți descurca fără ele dacă cercetătorul lucrează îndeaproape cu echipa de proiect, există încredere internă și echipa este suficient de matură pentru a prioritiza corect rezolvarea problemelor.

Metoda de înregistrare a datelor

S-ar părea că ce este rău la un bloc de note și un stilou sau doar document deschis Cuvânt? În lumea de dezvoltare Agile de astăzi, cercetătorii UX trebuie să încerce să-și aducă descoperirile înapoi echipei cât mai repede posibil.

Pentru a optimiza timpul de analiză, este bine să pregătiți în prealabil un șablon pentru introducerea notelor în timpul testului. Am încercat să facem asta într-un specialist software(de exemplu, Noldus Observer sau Morae Manager), dar în practică tabelele s-au dovedit a fi cele mai flexibile și versatile. Marcați în prealabil în tabel întrebările pe care intenționați să le adresați, locurile de introducere a problemelor găsite în sarcini, precum și ipotezele (pentru fiecare respondent veți marca dacă a fost confirmat sau nu). Semnele noastre arată astfel:

Ce altceva poți folosi:

  • . Personalizat Șablon Excel pentru a introduce observații pentru fiecare respondent. Există un cronometru încorporat care măsoară timpul necesar pentru finalizarea sarcinilor, iar graficele de timp și de succes sunt generate automat.
  • Rainbow Spreadsheet de Tomer Sharon de la Google. Tabel vizual pentru colaborare cercetător și echipă. Linkul duce la un articol care descrie metoda și există, de asemenea, un link către o foaie de calcul Google cu un șablon.

Cu experiență, majoritatea notelor pot fi luate în timpul testului. Dacă nu ați ajuns la timp, este mai bine să notați tot ce vă amintiți imediat după test. Dacă reveniți la analiză după câteva zile, cel mai probabil va trebui să vizionați din nou videoclipul și să petreceți mult mai mult timp.

Pregătirea pentru testare

Pe lângă metodă, metrici și protocolul de testare în sine, trebuie să decideți asupra următoarelor lucruri:

Format de comunicare cu moderatorul. Moderatorul poate fi în aceeași cameră cu participantul la test. În acest caz, îi va fi ușor să pună întrebări la timp. Totuși, prezența unui moderator poate influența respondentul: acesta va începe să-i pună întrebări moderatorului, provocându-l să-l solicite explicit sau implicit.

Încercăm să lăsăm respondentul singur cu produsul pentru cel puțin o parte a testului. Astfel comportamentul lui devine mai relaxat și mai natural. Și pentru a nu alerga înainte și înapoi dacă ceva nu merge bine, puteți lăsa orice messenger cu conexiune audio activată, astfel încât moderatorul să poată contacta respondentul din camera de observație.

Metoda de stabilire a sarcinilor. Sarcinile pot fi anunțate de un moderator. Dar în acest caz, în ciuda protocolului uniform de testare, textul sarcinii poate fi pronunțat ușor diferit de fiecare dată. Acest lucru este valabil mai ales dacă testul este efectuat de mai mulți moderatori. Uneori, chiar și mici diferențe de formulare pot pune respondenții în condiții de plecare diferite.

Pentru a evita acest lucru, puteți fie să „antrenați” moderatorii să citească întotdeauna textele sarcinii, fie să le oferiți respondenților sarcini pe bucăți de hârtie sau pe ecran. Diferențele de redactare încetează să mai fie o problemă dacă folosești un scenariu flexibil, când sarcinile sunt formulate în timpul testului, pe baza unui interviu cu moderatorul.

Puteți utiliza instrumentele produsului pentru a stabili sarcini. De exemplu, la testarea ICQ, respondenții au primit sarcini printr-o fereastră de chat cu un moderator, iar la testarea Mail.Ru Mail, le-au primit prin scrisori. Acest mod de stabilire a sarcinilor a fost cât se poate de firesc pentru aceste proiecte și am testat și scenarii de corespondență de bază de multe ori.

Crearea unui context natural. Chiar dacă vorbim de teste de laborator, gândiți-vă cum să aduceți mai aproape utilizarea produsului în test de conditii reale. De exemplu, dacă testați dispozitive mobile, cum le vor ține respondenții? Pentru imagine bunaÎn înregistrările video, este mai bine atunci când telefonul sau tableta sunt fixate pe un suport sau întinse pe o masă. Cu toate acestea, acest lucru nu arată clar dacă toate zonele sunt accesibile și convenabil de apăsat, deoarece telefoanele sunt adesea ținute cu o singură mână, iar cu tabletele se află pe canapea.

Merită să vă gândiți la mediul în care va fi utilizat produsul: există ceva care distrage atenția persoanei, este zgomotos, există o conexiune bună la internet. Toate acestea pot fi simulate în laborator.

Plan de testare pentru client. Aceasta este, de asemenea, o fază de pregătire importantă, deoarece implică echipa de proiect. Nu trebuie să spuneți clientului toate caracteristicile metodologice ale testului (cum veți comunica cu respondentul, înregistrați datele etc.). Dar asigurați-vă că îi arătați care vor fi sarcinile și ce veți testa pentru ele. Poate că nu ați ținut cont de unele caracteristici ale proiectului, sau poate că echipa de proiect va avea idei suplimentare si ipoteze. De obicei ajungem cu un semn ca acesta:

Planul de raportare. Desigur, raportul este scris pe baza rezultatelor studiului. Dar este o bună practică să întocmești un plan de raport înainte de a efectua teste, pe baza scopurilor și obiectivelor studiului. Cu un astfel de plan în fața dvs., puteți verifica scriptul pentru a-ți verifica caracterul complet, precum și să pregătești cele mai convenabile formulare pentru a capta date pentru o analiză ulterioară. Puteți decide că un raport nu este necesar și că un dosar general de observații este suficient pentru dumneavoastră și echipă. Și dacă îți motivezi echipa să o completeze cu tine, asta va fi absolut grozav.

Desigur, puteți doar „lăsați prietenul să folosească produsul” și să vedeți ce dificultăți are. Dar un scenariu bine scris vă va permite să nu ratați problemele importante și să nu împingeți accidental respondentul la răspunsurile de care aveți nevoie. La urma urmei, testarea de utilizare este un experiment simplificat și, în orice experiment, pregătirea preliminară este importantă.

Protocolul pentru orice testare de utilizare constă din următoarele părți:

  • Instruire sau briefing (bun venit, descrierea evenimentului, semnarea documentelor).
  • Interviu introductiv (test de screening, interviu scurt despre utilizarea produsului, context și scenarii).
  • Lucrul cu produsul (sarcini de testare).
  • Colectarea impresiilor finale ale produsului pe baza experienței de testare.

Instruire sau briefing

Indiferent de subiectul testării, orice studiu începe la fel. Ce ar trebui făcut:

Creați o atmosferă. Cunoaște persoana, oferă-i ceai, cafea sau apă, arată-i unde este toaleta. Încercați să relaxați puțin respondentul, deoarece poate fi nervos înainte de eveniment. Aflați dacă a fost ușor să vă găsesc, întrebați cum vă simțiți.

Descrieți procesul. Spuneți-ne ce fel de eveniment îl așteaptă pe respondent, cât timp va dura, din ce părți constă și ce veți face. Asigurați-vă că îi subliniați respondentului că contribuția acestuia va ajuta la îmbunătățirea produsului și că nu testați abilitățile unei persoane. Dacă înregistrați video, avertizați respondentul despre acest lucru și spuneți-i că datele nu vor apărea online. Eu zic cam asa:

Ne aflăm în biroul Grupului Mail.Ru. Astăzi vom vorbi despre proiectul XXX. Acest lucru va dura aproximativ o oră. Mai întâi vom vorbi puțin, apoi vă voi ruga să încercați să faceți ceva în proiectul în sine, apoi vom discuta despre impresiile dvs. Vom înregistra ce se întâmplă în cameră și pe ecranul computerului. Înregistrarea este necesară doar pentru analiză, nu vă veți vedea pe Internet.

Facem cercetări pentru a îmbunătăți proiectul XXX, pentru a înțelege ce trebuie să fie fixat în el și în ce direcție ar trebui să se dezvolte. Prin urmare, vă rog să exprimați deschis orice comentarii: atât pozitive, cât și negative. Nu-ți fie teamă să ne jignești. Dacă ceva nu îți merge în timp ce studiezi un proiect, ia-l cu calm. Aceasta înseamnă că am găsit o problemă pe care echipa de proiect trebuie să o rezolve. Principalul lucru este să vă amintiți că nu vă testăm, voi testați produsul. Dacă sunteți gata, vă sugerez să începeți.

Să semneze documente. De regulă, acesta este consimțământul pentru prelucrarea datelor cu caracter personal și, uneori, și un acord privind nedezvăluirea informațiilor despre testare. Pentru testele cu minori, este necesar acordul părinților pentru ca copilul lor să participe la studiu. De obicei o trimitem părinților în avans și le rugăm să-l aducă cu ei. Asigurați-vă că explicați de ce solicitați să semnați documentele și acordați-le timp să le examineze. În Rusia, oamenii se feresc de orice documente care trebuie semnate.

Configurați echipamentul. Dacă utilizați urmărirea ochilor, echipamente biometrice sau pur și simplu înregistrați videoclipuri, acum este momentul să activați totul. Avertizați respondentul când începeți înregistrarea.

Interviu introductiv

Rezolvă următoarele probleme:

Verificați recrutarea. Pentru a fi sigur, începeți întotdeauna de acolo - chiar dacă aveți încredere în agenția sau persoana care a găsit respondentul. De mai multe ori în timpul testului am aflat că respondentul a înțeles greșit întrebările și de fapt nu a folosit produsul exact așa cum aveam nevoie. Încercați să evitați formalitățile și să evitați să puneți întrebări din chestionarul de screening: persoana poate ști deja ce să răspundă.

Scenarii și context pentru utilizarea produsului. Chiar dacă nu ai mult timp pentru test, nu sări peste acest pas. Cel puțin în general, află de la respondent ce probleme rezolvă cu ajutorul produsului, dacă folosește proiecte similare, în ce condiții interacționează cu acestea și de pe ce dispozitive. Răspunsurile vă vor ajuta să înțelegeți mai bine motivele comportamentului respondentului și, dacă utilizați un scenariu flexibil, atunci formulați sarcini adecvate. Dacă aveți suficient timp, cereți respondentului să arate ce și cum face de obicei. Aceasta poate fi o sursă de întrebări și perspective suplimentare.

Așteptări și relații.Începutul testării este un moment bun pentru a afla ce știe respondentul despre produs, ce simte despre acesta și ce așteptări de la acesta. După test, vei putea compara așteptările tale cu impresia finală.

Pentru majoritatea testelor, această structură introductivă a interviului va funcționa. Dacă testați un produs nou, poate doriți să omiteți întrebările introductive. Dacă intrați în prea multe detalii despre un subiect, acesta poate crea anumite așteptări pentru utilizator cu privire la produs. Prin urmare, lăsați doar câteva întrebări generale pentru a stabili contactul cu respondentul și treceți imediat la sarcini și este mai bine să discutați scenarii, relații și context după ce utilizatorul a studiat inițial produsul.

Lucrul cu produsul, scrierea sarcinilor

Care sunt sarcinile?

Să ne imaginăm că vrei să testezi un magazin online. Aveți scenarii importante (căutarea și selecția mărfurilor, procesul de comandă), probleme cunoscute (erori frecvente în formularul de plată) și chiar o ipoteză că proiectantul a greșit cu filtrul de preț. Cum să formulezi sarcini?

Sarcini concentrate. Pare evident să faci așa ceva: „Alege maşină de spălat vase 45 de centimetri lățime cu o funcție „grindă pe podea” care nu costă mai mult de 30 de mii de ruble. Acest lucru îl motivează pe respondent să folosească filtre și să compare produsele între ele. Puteți verifica filtrul de preț pentru toți respondenții și puteți analiza scenariul cheie pentru selectarea unui produs. Astfel de sarcini au dreptul la viață și sunt bune pentru testarea unor ipoteze specifice (ca și în cazul filtrului de preț).

Cu toate acestea, dacă întregul test constă din ele, atunci riscați următoarele:

  • Verificarea interfeței la fața locului. Veți găsi doar probleme care sunt legate de detaliile postului (filtrați după preț și lățime). Nu veți vedea alte probleme - cum ar fi sortarea produselor sau alte filtre - decât dacă le subliniați și ele. Dar este puțin probabil să reușiți să finalizați sarcini pentru toate elementele site-ului.
  • Lipsa de implicare. Utilizatorii efectuează adesea astfel de sarcini mecanic. Când văd primul produs care corespunde criteriilor, se opresc. Poate că respondentul nu a ales niciodată o mașină de spălat vase în viața sa și nu-i pasă ce este o „grindă pe podea”. Cu cât o sarcină este mai asemănătoare cu o situație din viața reală și cu cât oferă mai mult context pe care utilizatorul îl poate înțelege, cu atât sunt mai mari șansele de a implica un respondent care va pretinde că alege cu adevărat un produs. Iar un utilizator implicat „trăiește” mai bine interfața, lasă mai multe comentarii, își crește șansele de a găsi probleme și de a oferi cunoștințe utile despre comportamentul și caracteristicile publicului.
  • Gamă restrânsă de perspective. În viața reală, utilizatorul ar selecta probabil un produs complet diferit. De exemplu, nu aș folosi filtre deloc (și aici le-ați subliniat). Sau as cauta un produs pe baza unor criterii care nu sunt pe site. Oferind sarcini rigide, concentrate, nu veți afla despre contextul real al utilizării produsului, nu veți găsi scenarii pe care echipa de proiect ar putea să nu le fi prevăzut și nu veți colecta date despre nevoile de conținut și funcționalități.

Sarcini cu context. O modalitate de a implica mai bine utilizatorii este să o adăugați la o sarcină uscată poveste adevaratași context. De exemplu, în loc de „Găsiți o rețetă de plăcintă cu prune pe site”, sugerați următoarele: „Veți avea oaspeți într-o oră. Găsiți ceva de coacere în această perioadă. Aveți de toate pentru biscuiți la frigider, precum și câteva prune. Dar, din păcate, nu există unt.”

O abordare similară poate fi utilizată cu un magazin online. De exemplu: „Imaginați-vă că alegi un cadou pentru sora ta. Uscatorul ei de par s-a stricat recent si ar fi bucuroasa sa-si ia unul nou. Trebuie să îndeplinești 7 mii de ruble.” Este important ca respondentul să aleagă cu adevărat o persoană reală căreia îi va „cumpăra” cadoul (dacă nu există soră, sugerați o altă rudă sau un prieten). Factorul cheie pentru astfel de sarcini este realitatea și claritatea contextului. Este ușor să-ți imaginezi că alegi un cadou pentru familia ta, dar este mult mai dificil să-ți imaginezi că ești „un contabil care pregătește un raport anual”.

Un exemplu izbitor al acestei abordări este „metoda Bollywood”, care a fost inventată de expertul indian UX Apala Lahiri Chavan. Ea susține că indienilor, la fel ca mulți asiatici, le este greu să vorbească deschis despre interfață. Dar, imaginându-se ca eroi ai situațiilor dramatice fictive (ca în filmele lor preferate), se deschid și încep să participe activ la testare. Prin urmare, sarcinile pentru indieni ar trebui să arate cam așa:

Imaginează-ți că tânăra ta nepoată iubită se căsătorește. Și apoi afli că viitorul ei soț este un fraudator și, de altfel, căsătorit. Trebuie să cumpărați urgent două bilete de avion spre Bangalore pentru dvs. și pentru soția înșelatorului, pentru a supăra nunta și a salva familia de rușine. Grabă!

Sarcini bazate pe experiența respondenților. Să vă reamintim: pentru testarea cu succes, respondenții trebuie să corespundă publicului proiectului. Prin urmare, pentru a verifica un magazin online de electrocasnice, îi recrutăm pe cei care au ales recent electrocasnice sau le aleg acum. Este exact ceea ce vom folosi atunci când creăm sarcini pe baza experienței respondenților. Există două opțiuni pentru utilizarea acestei abordări:

  • Parametrii respondentului. În acest caz, adaptați sarcinile fixe respondenților. De exemplu, în cazul unui magazin de electrocasnice și a unei sarcini de lucru cu filtre, îl întrebi pe persoană ce anume a achiziționat recent. Aflați criteriile (preț, funcții) și propuneți să repetați „cumpărarea” pe site-ul dvs.
  • Scenariile respondenților. Sarcinile sunt complet formate pe baza experienței participanților. Pentru a înțelege ce scenarii să verifice, moderatorul află exact cum a rezolvat persoana problema în viață și sugerează să o facă pe site. De exemplu, un cumpărător a petrecut mult timp comparând mai multe modele înainte de a alege. Chiar dacă site-ul nu are o funcție adecvată, invitați respondentul să compare produse pentru a înțelege pe ce parametri se va baza. Poate că veți obține idei despre cum ar trebui să arate funcția de comparare și, de asemenea, veți adapta pagina produsului la acest scenariu.

Astfel de sarcini dau multe exemple reale efectuarea operațiunilor de bază în produs. Acest lucru dă adesea naștere la o gamă mult mai largă de probleme și constatări. În plus, vă permite să testați produsul pe noi scenarii pe care nu le-ați considerat de bază sau nici măcar nu le-ați gândit.

Când am testat proiectul Mail.Ru Real Estate, sarcinile bazate pe experiența respondenților ne-au ajutat să facem multe descoperiri. Am văzut că atunci când caută un apartament în regiunea Moscovei, oamenii indică în geofiltru stațiile finale de metrou, adică acestea sunt stații la care se poate ajunge din regiune. Ne asteptam ca filtrul de metrou sa caute un apartament langa statie. De asemenea, am aflat cum diferă scenariile de căutare pentru clădiri noi de cele secundare, ceea ce a ajutat la mutarea căutării clădirilor noi într-o altă secțiune a site-ului - cu propriile filtre și propriul concept de descriere a apartamentelor. De asemenea, vă recomand să citiți articolul excelent al lui Jared Spool despre beneficiile unor astfel de sarcini.

Misiuni fără sarcini. Uneori este mai bine să nu oferi utilizatorilor sarcini pentru a lucra cu proiectul, ci să vezi unde încep ei înșiși să se familiarizeze cu produsul. Oferă respondentului o introducere: „Imaginați-vă că vă decideți să încercați acest produs. Te las câteva minute. Fă ceea ce ai face în viața reală. Nu vă dau nicio sarcină”.

Este important ca moderatorul să părăsească sala în acest moment. În caz contrar, utilizatorul este tentat să întrebe imediat ceva, să clarifice: „Trebuie să mă înregistrez? Cum pot face acest lucru?" și așa mai departe.

Acest tip de sarcină este util pentru produse complet noi. Îl folosim adesea pentru aplicații și jocuri mobile. Așa aflăm dacă utilizatorii citesc materiale de instruire, ce detalii atrag imediat atenția, ce înțeleg oamenii despre conceptul de produs și cum îi descriu apoi capacitățile. După sarcina gratuită sunt planificate scenarii specifice.

Un alt domeniu de aplicare pentru sarcinile gratuite sunt proiectele de conținut. Dacă vrei să înțelegi cum sunt citite articolele tale (unde zăbovesc mult timp, ce opresc, la ce elemente din pagină acordă atenție), atunci pur și simplu lasă respondentul singur cu proiectul pentru câteva minute. Numai fără ca un moderator să se uite peste umăr, utilizatorul se va relaxa și va citi textul în același mod ca de obicei. Așa testăm proiectele „Mail.Ru News”, „Mail.Ru Lady” și altele. Această abordare a făcut posibilă identificarea diferitelor modele de comportament pe site, diferite modele de citire a articolelor și înțelegerea tipurilor de materiale care ar trebui formatate diferit.

Efectuarea unor sarcini bune

Prima sarcină este simplă.Începeți testarea cu sarcini introductive și simple. Respondentul trebuie să se simtă confortabil cu formatul testului, mai ales dacă utilizați metoda gândirii cu voce tare: trebuie să se obișnuiască să fie nevoit să își verbalizeze gândurile și sentimentele. Nu ar trebui să aruncați imediat toată durerea și suferința interfeței pe ea.

Nu-mi da niciun indiciu. Formulați sarcini pentru a nu solicita respondentul actiuni corecte. Dacă doriți să testați capacitatea de a adăuga produse la favorite într-un magazin online, faceți fără sarcina „Să adăugăm acest televizor la favorite”, mai ales dacă butonul este numit astfel. Respondentul, după ce a citit sarcina, va găsi pur și simplu un buton pe ecran cu semnătura dorită - poate chiar fără să înțeleagă ce face exact.

Este mai bine să explicați sensul sarcinii fără a recurge la termeni din interfață. De exemplu: „Pe site puteți salva produsele care vă plac și apoi alegeți pe care să le comandați. Să încercăm să facem asta cu așa și cu un televizor.”

Urmăriți terminologia. Nu folosiți cuvinte și simboluri neclare. Acest lucru pare evident, dar noi, obișnuiți cu anumiți termeni, uităm adesea că puțini oameni din afara comunității IT îi cunosc. De exemplu, la testarea noii funcționalități de fire (lanțuri de litere) în Mail.Ru Mail, am avut o perioadă dificilă. La urma urmei, utilizatorii care nu sunt familiarizați cu această funcție pur și simplu nu au în cap un termen care să desemneze fire.

Până la urmă, nu le-am numit nimic. Pur și simplu le-am arătat respondenților o cutie cu lanțuri conectate și am discutat despre asta noua oportunitateși a permis utilizatorilor să-și aleagă propriul cuvânt pentru a desemna fire. Acest lucru ne-a ajutat să folosim mai târziu cele mai înțelese texte în materiale promoționale educaționale.

Urmăriți nu numai temele, ci și întrebările moderatorului, în special cele care vin de la echipă în timpul testării. De exemplu, atunci când discutați despre funcții, nu ar trebui să utilizați cuvântul „bară de instrumente”: nu toată lumea este familiarizată cu el. Cu doar câțiva ani în urmă, nu toți utilizatorii cunoșteau nici măcar cuvântul „browser”. Cel mai bun mod de a formula sarcini depinde de publicul de testare. Nu ar trebui să mergi la cealaltă extremă, explicând toți termenii la rând. De exemplu, jucătorii cu experiență nu trebuie să explice ce sunt „buff”, „frag”, „respawn” și așa mai departe.

Mai puține teste. Este adesea tentant să creați un cont de testare pentru respondent în sistem și să efectuați testarea acestuia. La urma urmei, puteți testa totul în acest cont în avans, evitați problemele și nu pierdeți timpul cu înregistrarea sau autorizarea unui respondent. Este adesea, de asemenea, mult mai ușor de activat din punct de vedere tehnic design nou bazat pe date de testare, nu pe date reale.

Cu toate acestea, cu această abordare riști să obții rezultate mult mai puțin utile, deoarece acțiunile de testare nu au consecințe reale. Situația devine complet artificială, este dificil pentru utilizatori să o proiecteze în experiența reală.

De exemplu, când lucrezi în propriul cont pe o rețea de socializare, respondenții, ca și în viața reală, vor face cu atenție tot ceea ce pot vedea prietenii lor (publică link-uri, trimite mesaje). La setare cutie proprie prin poștă vor încerca să nu ștergă scrisorile importante. La testarea magazinelor online, uneori se folosește o abordare în care recompensa trebuie cheltuită direct în timpul testului. În acest caz, respondentul nu va atinge primul produs care se potrivește sarcinii, ci va selecta ceea ce are de fapt nevoie.

Cu doar date de testare, veți găsi probleme asociate numai cu acestea, mai degrabă decât să testați funcționalitatea pe diferite variante. De exemplu, când am testat panoul social al browserului Amigo, unul dintre respondenți, care și-a conectat contul VKontakte la panou, a observat imediat că îi era incomod să citească în acest fel. Aproape întregul feed a constat din abonamente la grupuri cu fotografii erotice. Și în panoul îngust din imagini era pur și simplu imposibil să vezi ceva.

O altă problemă cu datele de testare este că este dificil de înțeles sistemul, deoarece totul în jur este neobișnuit. De exemplu, un utilizator al rețelei sociale este obișnuit să-și recunoască pagina prin propria fotografie. Chiar și atunci când testăm prototipuri, încercăm să le personalizăm cât mai mult posibil. De exemplu, atunci când testăm prototipuri pe care se poate face clic în Odnoklassniki, le adaptăm întotdeauna pentru fiecare utilizator, inserând numele și fotografia acestuia și, uneori, ultimele știri, pe pagină.

Nu vă lăsați limitat de interfață. Nu uitați că interacțiunea cu un produs nu se limitează adesea doar la interfață. Dacă este posibil, testați produse sau servicii conexe și conexiunile dintre ele. Când testăm jocuri, încercăm să verificăm nu numai jocul, ci și site-ul său web și descărcările asociate, înregistrarea în joc și căutarea de informații pe forum. Și când am testat un magazin online, am verificat și apelul operatorului după plasarea unei comenzi, care dădea recomandări pentru call center.

Gândește-te la sincronizare. Pentru un scenariu bun, este important să prioritizați sarcinile. Cel mai probabil, dacă sistemul este mare și testul are multe obiective, vei dori să faci o mulțime de sarcini. Cu toate acestea, un respondent obosit nu va mai fi de folos. Bun test durează nu mai mult de o oră și jumătate, două este maxim. Excepția sunt poate jocurile. Și amintiți-vă că obiectivele dvs. nu sunt doar sarcini, ci și interviuri, chestionare, amenajarea echipamentelor și semnarea documentelor. Toate acestea durează de obicei cel puțin o jumătate de oră.

Dacă sunt prea multe sarcini și nu vrei să renunți la unele, poți să le pui pe cele mai puțin prioritare în rotație, adică să arăți doar părți din respondenți. Sau faceți o parte din test obligatorie pentru toată lumea și urmăriți restul doar cu cei cu timp suficient. Dar aceștia vor fi cel mai probabil cei mai de succes respondenți.

Evaluați utilitatea sarcinii. Luați în considerare dacă într-adevăr se potrivește ipotezelor dvs. De exemplu, doriți să testați funcția de abonare la știri pe un site web. Sarcina „Abonare la newsletter” va verifica doar dacă newsletter-ul poate fi găsit de cei care îl caută. Cu toate acestea, oamenii vin rar pe site pentru a se abona la știri. Sarcina nu se aplică vieții reale. Trebuie să înțelegeți dacă oportunitatea de a vă abona este observată de cei care îndeplinesc sarcini complet diferite.

Acest lucru poate fi verificat în diferite moduri, în funcție de implementarea funcției. Dacă o persoană a fost angajată în sarcini în care ar fi văzut opțiunea de abonament, întreabă-l dacă se află pe site. Asigurați-vă că clarificați unde a văzut această oportunitate sau cum a fost implementată pentru a vă asigura că respondentul nu este doar de acord cu dvs.

Dacă o ofertă de abonament este inclusă în procesul de înregistrare sau de plată, vedeți dacă respondentul profită de ea și discutați-o după sarcină. Există foarte puține șanse ca în condiții de laborator oamenii să se aboneze efectiv la liste de corespondență, dar puteți verifica dacă o persoană a acordat atenție acestei oportunități, ce așteaptă de la lista de corespondență și așa mai departe.

Culegere de impresii finale

Scopul fazei finale de testare este de a colecta impresii despre lucrul cu produsul, de a înțelege ce i-a plăcut utilizatorului și ce l-a supărat și de a evalua satisfacția subiectivă. De obicei, această parte a testului folosește o combinație între un interviu cu un moderator și completarea chestionarelor formale.

Interviu cu moderatorul

În interviul final, le punem întotdeauna respondenților aproximativ aceleași întrebări: „Care au fost impresiile tale?”, „Ce ți-a plăcut și ce nu?”, „A fost ceva care părea dificil sau incomod?”, „Ce a fost lipsește?” , „Ce ați dori să schimbați în produs?” Este timpul să clarificați aspectele neclare ale comportamentului respondentului dacă nu ați făcut acest lucru în timpul testului. Dacă, înainte de test, ați aflat de la utilizatori atitudinea lor față de marcă sau produs și așteptările lor de la acesta, aflați dacă s-a schimbat ceva. La interviu, acordați atenție următoarelor:

Dezirabilitatea socială. Gestionați cu mare atenție rezultatele interviului. Dacă în timpul testului auziți adesea comentarii impulsive sub influența problemelor, atunci în interviul final va înflori dezirabilitatea socială.

Unii oameni simt că atunci când vorbesc despre problemele unui produs, își recunosc propria incompetență. Alții pur și simplu nu vor să supere un moderator plăcut. Foarte des, respondenții (în special femeile) care au suferit întregul test spun că totul este, în principiu, normal. Feedback-ul negativ poate fi dictat și de dezirabilitatea socială: dacă respondentul crede că scopul testului este de a găsi defecte, el încearcă cu sârguință să le găsească.

Citate și priorități. Deși toate cuvintele testatorilor din interviul final trebuie adesea împărțite la doi sau chiar zece, asta nu înseamnă că sunt inutile. Pe baza modului în care respondenții își rezumă impresiile, puteți deduce priorități. Produs - " este nasol"? Ce anume a influențat asta? Care dintre multele probleme își amintește cel mai mult respondentul și le consideră cele mai enervante?

Cu toate acestea, luați în considerare faptul că ultima sarcină este cel mai bine reținută. De asemenea, este foarte util să urmăriți ce adjective folosesc respondenții pentru a descrie produsul și cu ce își compară experiența.

Să nu uităm de bine. Foarte des, un raport de testare a gradului de utilizare este o listă lungă de probleme găsite în timpul testului. În general, găsirea problemelor este una dintre sarcinile principale ale cercetării. Dar nu uita de aspecte pozitive produs.

În primul rând, un raport fără rezultate pozitive pur și simplu demotivează echipa. Și, în al doilea rând, este util să știm ce le place utilizatorilor la produs: ce se întâmplă dacă în timpul următoarei reproiectări ei decid să elimine caracteristica care le-a plăcut atât de mult tuturor. Prin urmare, asigurați-vă că întrebați respondenții despre aspectele pozitive ale produsului, chiar dacă au criticat interfața pe parcursul testării.

Atitudine față de „dorințe”. Cel mai probabil, respondenții, pe lângă impresiile lor, își vor exprima dorințe și idei. Sarcina ta este să înțelegi ce problemă se află în spatele propunerilor. Pentru că soluțiile oferite de utilizatori, cel mai probabil, nu ți se potrivesc. La urma urmei, participanții la testare nu sunt designeri, nu sunt conștienți de caracteristicile și limitările dezvoltării. Cu toate acestea, în spatele oricărei astfel de solicitări există o nevoie pe care trebuie să o captezi. Dacă un respondent spune că are absolut nevoie de un buton verde mare aici, asigurați-vă că întrebați: de ce?

Măsura satisfacției

Adesea, conform cuvintelor respondentului din interviul final, este greu de înțeles dacă produsul i-a plăcut sau nu și cu atât mai dificil de comparat atitudinea mai multor respondenți care au remarcat atât avantaje, cât și dezavantaje. Aici chestionarele vin în ajutorul cercetătorului. În primul rând, la completarea chestionarului (mai ales înainte de a vorbi cu moderatorul), influența notoriei dezirații sociale este puțin mai mică, deși nu veți scăpa complet de ea. În al doilea rând, chestionarul vă oferă parametri clari pentru compararea scenariilor, produselor sau etapelor proiectului.

Alcătuirea unui chestionar bun este un subiect separat și foarte amplu. Formularea, scalele și multe altele sunt importante aici. Chestionarele gata făcute și dovedite pot fi de mare ajutor: au fost deja perfectionate și testate de multe ori. Singura problemă este că aproape toate aceste chestionare nu au traduceri oficiale în rusă. Desigur, le puteți traduce singur, dar din punct de vedere metodologic, traducerile trebuie testate pentru a verifica corectitudinea formulării. Cu toate acestea, chestionarele pot servi drept ghid atunci când vă creați propriile chestionare.

Există chestionare care sunt date după fiecare sarcină pentru a evalua satisfacția față de scenarii specifice. De exemplu:

  • Chestionarul după scenariu (ASQ). Trei întrebări despre complexitate, productivitate și indicii în sistem.
  • Întrebare simplă unică (SEQ) . O întrebare despre complexitatea scenariului.

Și există chestionare care sunt folosite deja în faza finală a testării. Iată câteva exemple pe care le folosim atunci când este necesar:

  • Scala de utilizare a sistemului și Chestionarul de utilizare a sistemului post-studiu. Două chestionare clasice și populare create cu mai bine de 20 de ani în urmă. Ambele constau în declarații. Respondenții trebuie să indice nivelul lor de acord cu ei. Toate aceste afirmatii cu laturi diferite caracterizează capacitatea de utilizare a produsului. De exemplu: „Aș putea găsi cu ușurință informațiile de care aveam nevoie”, „ Diverse posibilități sistemele sunt ușor accesibile” și așa mai departe.
  • . Un chestionar care ne ajută adesea în timpul testelor. Utilizatorului i se pune la dispoziție un set de adjective din care le selectează pe cele care pot caracteriza produsul. Ca rezultat, obțineți un nor de cuvinte - caracteristici ale proiectului dumneavoastră. Adesea, această tehnică aduce rezultate foarte interesante.
  • Chestionar privind experiența jocului. Chestionarele clasice de utilizare nu pot fi aplicate la jocuri: implicarea în joc este mult mai importantă decât înțelegerea interfețelor. Prin urmare, ar trebui să creați întotdeauna chestionare speciale pentru jocuri sau să utilizați Chestionarul privind experiența jocului. Chestionarul conține mai multe module: un modul de bază, un bloc în joc, un post-chestionar și un chestionar oportunități sociale jocuri.
  • Material publicat de utilizator. Faceți clic pe butonul „Scrie” pentru a vă împărtăși opinia sau a vorbi despre proiectul dvs.

Pregătire, interviuri și colectare de date

La marcaje

Natalia Sprogis, șefa de cercetare UX la Mail.Ru Group, a vorbit pe blogul companiei despre Habrahabr despre pregătirea și desfășurarea testelor de utilizare: ce să includeți în scriptul de testare, cum să alegeți o metodă de colectare a datelor, să creați sarcini și să colectați impresiile respondenților .

Un plan de testare este, pe de o parte, un set de sarcini, întrebări și chestionare pe care le oferiți fiecărui respondent, iar pe de altă parte, este baza metodologică a studiului: metrici și ipoteze pe care le testați și le înregistrați, instrumentele selectate.

Testarea este cu adevărat necesară?

În primul rând, trebuie să fii sigur că în această etapă proiectul are nevoie de testare de utilizare. Prin urmare, clarificați în ce scop vă contactează echipa de proiect. Testarea de utilizare nu este atotputernică și, de la început, trebuie să înțelegeți ce poate aduce produsului. Pregătește-ți imediat echipa de proiect pentru a ști la ce întrebări poți răspunde și la care nu poți. Au existat cazuri în care fie le-am oferit clienților o altă metodă (de exemplu, interviurile aprofundate sau studiile de jurnal sunt mai bune acum), fie le-am recomandat să abandoneze complet studiul și să facă un test divizat.

De exemplu, nu testăm niciodată „atractivitatea” unei caracteristici sau a unei opțiuni de design în cercetarea calitativă. Putem colecta feedback de la utilizatori, dar există riscul prea mare ca răspunsurile lor să fie influențate de dezirabilitatea socială. Oamenii sunt întotdeauna înclinați să spună că ar folosi chiar și ceea ce nu vor folosi. Și dimensiunea mică a eșantionului nu ne permite să avem încredere în astfel de răspunsuri. De exemplu, am avut o experiență nereușită la testarea paginilor de destinație pentru jocuri: pagina de destinație aleasă ca cea mai atractivă în test a avut rezultate mult mai proaste în timpul testării A/B.

Testarea prototipurilor și a conceptelor are, de asemenea, o serie de limitări. Când planificați, trebuie să înțelegeți ce puteți obține cu adevărat din acest test. Este grozav atunci când un proiect are posibilitatea de a testa prototipuri sau modele înainte de implementare. Cu toate acestea, cu cât prototipul este mai puțin detaliat și funcțional, cu atât nivelul de abstractizare al respondentului este mai mare, cu atât se pot obține mai puține date din test. Cel mai bine este să testați prototipurile pentru a identifica problemele cu denumirea și metaforele icoanelor, adică toate problemele de înțelegere. Capacitatea de a testa orice dincolo de aceasta depinde în mare măsură de natura proiectului și de detaliul prototipului.

Baza pentru scrierea unui script de testare a utilizabilității

Planificarea testului începe nu cu scrierea textului sarcinilor, ci cu o elaborare detaliată a obiectivelor și întrebărilor de cercetare împreună cu echipa de proiect. Iată baza pentru a face un plan:

Scenarii importante. Acestea sunt acele scenarii de utilizator (sarcini sau cazuri de utilizare) care afectează afacerea sau sunt legate de scopul testării. Chiar dacă echipa suspectează probleme în anumite zone, deseori merită să verificați cazurile subiacente. În acest caz, următoarele scenarii pot fi considerate importante pentru test:

  • cele mai frecvente (de exemplu, trimiterea unui mesaj în messenger);
  • afectarea obiectivelor de afaceri (de exemplu, lucrul cu un formular de plată);
  • legate de actualizare (cei afectați de reproiectare sau introducerea de noi funcționalități).

probleme cunoscute Adesea, cercetarea trebuie să ofere răspunsuri la cauzele problemelor de afaceri ale unui serviciu. De exemplu, producătorul este îngrijorat de fluxul mare de jucători după prima oră de joc. Și uneori, zonele cu probleme ale interfeței sunt deja cunoscute de echipă și trebuie să aduni detalii și detalii. De exemplu, serviciul de asistență este adesea contactat cu întrebări despre forma de plată.

Întrebări. Echipa poate avea, de asemenea, întrebări de cercetat: de exemplu, utilizatorii observă un banner care reclamă servicii suplimentare? O anumită secțiune este numită clar?

Ipoteze.În asta sunt traduse problemele și întrebările cunoscute ale echipei. Este bine dacă clientul vine la tine cu ipoteze gata făcute - de exemplu, „Clienții noștri plătesc doar telefonic cu comision. Este posibil ca utilizatorii să nu vadă opțiunea unei metode de plată mai profitabile.” Dacă nu există ipoteze, dar există doar dorința de a testa proiectul în mod abstract „pentru utilizare”, sarcina dumneavoastră este să formulați aceste ipoteze.

Gândiți-vă împreună cu echipa de proiect la locurile în care utilizatorii nu se comportă conform așteptărilor (dacă există astfel de informații). Aflați dacă există elemente de design care au fost dezbătute mult și s-ar putea dovedi problematice. Efectuați propriul audit al produsului pentru a găsi probleme potențiale pentru utilizatori, care sunt importante de testat. Toate acestea vă vor ajuta să faceți o listă cu acele elemente (sarcini, întrebări, verificări) care ar trebui incluse în scriptul final.

Metoda de colectare a datelor

Este important să luați în considerare modul în care veți colecta date despre ceea ce se întâmplă în timpul testului pentru o analiză ulterioară. Următoarele opțiuni sunt utilizate în mod tradițional:

Observare.În timpul îndeplinirii sarcinilor, respondentul rămâne singur cu produsul și se comportă așa cum crede de cuviință. Comentariile respondentului sunt colectate prin chestionare și comunicarea cu moderatorul după test. Aceasta este cea mai „curată” metodă; oferă un comportament mai natural al respondentului și capacitatea de a măsura corect o serie de metrici (de exemplu, timpul de finalizare a unei sarcini).

Cu toate acestea, există o mulțime de date calitative utile în culise. După ce ați văzut acest comportament al unui respondent, nu puteți înțelege de ce acționează în acest fel. Desigur, puteți întreba despre asta la sfârșitul testului, dar cel mai probabil respondentul își va aminti bine doar ultima sarcină. În plus, în timpul îndeplinirii sarcinilor, părerea lui despre sistem se poate schimba și veți obține doar imaginea finală, și nu primele impresii.

Gândește cu voce tare (gânduri cu voce tare). Multă vreme, această metodă a fost folosită cel mai des în testarea utilizabilității. Jakob Nielsen l-a numit odată principalul instrument de evaluare a gradului de utilizare. Ideea este că îi cereți respondentului să își exprime toate gândurile care apar în timpul lucrului cu interfața și să comenteze toate acțiunile sale. Arată cam așa: „Acum voi adăuga acest articol în coșul meu. Unde e butonul? Ah, iată-o. Oh, am uitat să mă uit ce culoare era.

Metoda ajută la înțelegerea de ce utilizatorul se comportă într-un fel sau altul și ce emoții îi evocă interacțiunea curentă. Este ieftin și simplu, chiar și un cercetător fără experiență se poate descurca.

Cu toate acestea, are dezavantajele sale. În primul rând, nu este foarte natural ca oamenii să „gândească cu voce tare” tot timpul. Ei vor deveni adesea tăcuți și va trebui să le reamintiți constant să vorbească în continuare. În al doilea rând, sarcinile cu această metodă durează puțin mai mult decât în ​​viața reală. În plus, unii respondenți încep să folosească produsul mai atent. Articulând motivele acțiunilor lor, ei încearcă să acționeze mai rațional și pur și simplu nu vor să arate ca niște idioți și este posibil să nu prinzi unele momente intuitive ale comportamentului lor.

Intervenția moderată activă. Metoda este ideală pentru testarea conceptelor și prototipurilor. În timpul îndeplinirii sarcinilor, moderatorul interacționează activ cu utilizatorul: la momentele potrivite el află motivele comportamentului său și pune întrebări clarificatoare. În unele cazuri, moderatorul poate chiar emite sarcini neplanificate care decurg din dialog.

Această metodă vă permite să colectați cantitatea maximă de date de calitate. Cu toate acestea, poate fi folosit doar dacă aveți încredere în profesionalismul moderatorului dvs. Întrebările formulate incorect sau puse la momentul nepotrivit pot afecta foarte mult comportamentul și impresiile respondentului și chiar pot invalida rezultatele testului. De asemenea, atunci când utilizați această metodă, aproape nicio măsurătoare nu poate fi măsurată.

Gândește cu voce tare retrospectivă, RTA (retrospectivă). Aceasta este o combinație a primelor două metode. Utilizatorul finalizează mai întâi toate sarcinile fără interferențe, apoi este redat un videoclip cu munca sa în fața lui, iar el comentează comportamentul său și răspunde la întrebările moderatorului. Principalul dezavantaj al metodei este că timpul de testare crește foarte mult. Cu toate acestea, există momente când este optim.

De exemplu, odată ne-am confruntat cu sarcina de a testa mai multe tipuri de mafioți (monstri de joc) într-un singur RPG. Desigur, nu am putut distrage atenția respondenților cu întrebări și nici nu-i puteam forța să comenteze acțiunile lor în timpul bătăliei. Acest lucru ar face imposibil să joci un joc în care este nevoie de concentrare pentru a câștiga. Pe de altă parte, utilizatorul cu greu și-ar putea aminti după o serie de contracții dacă a observat că toporul strălucește roșu la primul șobolan. Prin urmare, în acest test am folosit metoda RTA. Cu fiecare utilizator, am trecut în revistă bătăliile sale și am discutat ce efecte ale monștrilor a observat și cum le-a înțeles.

Încercați să vă gândiți cum să obțineți suficiente date menținând în același timp naturalețe maximă în comportamentul respondentului. În ciuda simplității și versatilității metodei „gândește cu voce tare”, care a fost mult timp cea mai populară în testarea utilizabilității, încercăm din ce în ce mai mult să o înlocuim cu observație. Dacă moderatorul vede un comportament interesant al respondentului, el va aștepta până când va finaliza sarcina și va pune o întrebare după aceea. Imediat după sarcină, este mai probabil ca respondentul să-și amintească de ce a făcut-o.

Un eye tracker ajută foarte mult în această chestiune. Văzând focalizarea atenției actuale a respondentului, puteți înțelege mai bine comportamentul acestuia fără a pune întrebări inutile. În general, eye tracker îmbunătățește semnificativ calitatea moderației, iar acest rol, în opinia mea, nu este mai puțin important decât capacitatea de a construi hitmaps.

Metrici

Metricurile sunt indicatori cantitativi ai gradului de utilizare. Ca rezultat al testării, veți obține întotdeauna un set de probleme găsite în interfață. Metricurile vă permit să înțelegeți cât de bun sau rău este totul și, de asemenea, să îl comparați cu un alt proiect sau cu versiunile anterioare ale designului.

Care sunt valorile?

Conform ISO 9241-11, principalele caracteristici ale utilizabilității sunt eficiența, productivitatea și satisfacția. Diferite valori pot fi relevante pentru proiecte diferite, dar toate sunt legate cumva de aceste trei caracteristici. Voi scrie despre cei mai des folosiți indicatori.

Îndeplinirea cu succes a sarcinilor. Puteți folosi un cod binar: a făcut față sarcinii sau a eșuat. Urmăm adesea abordarea lui Nielsen și distingem trei tipuri de evaluări de succes:

  • a finalizat sarcina practic fără probleme - 100%;
  • a întâmpinat probleme, dar a finalizat sarcina în mod independent - 50%;
  • a eșuat sarcina - 0%.

Dacă din 12 respondenți 4 au finalizat sarcina cu ușurință, 6 au avut probleme și 2 au eșuat, atunci rata medie de succes pentru această sarcină va fi de 58%.

Uneori, veți întâlni o situație în care grupul de mijloc include respondenți cu grade foarte diferite de „problematică”. De exemplu, un respondent s-a luptat cu fiecare câmp al formularului, în timp ce celălalt a făcut doar o mică greșeală la sfârșit. Îți poți da scorul la discreția ta, în funcție de ceea ce s-a întâmplat la test. De exemplu, 25% - dacă respondentul tocmai a început să finalizeze sarcina, sau 80% - dacă a făcut o greșeală minoră.

Pentru a evita prea multă subiectivitate, luați în considerare scalele de punctaj în avans, mai degrabă decât să decideți pentru fiecare respondent după test. De asemenea, merită să luați în considerare ce să faceți cu erorile. De exemplu, ați dat sarcina de a cumpăra bilete de film în proiectul Cinema Mail.Ru. Unul dintre respondenți a cumpărat din greșeală un bilet nu pentru mâine, ci pentru astăzi și nu l-a observat. Este încrezător că a îndeplinit sarcina și are un bilet în mână. Dar greșeala lui este atât de critică încât nu va intra în film, așa că i-aș da „0%”, în ciuda faptului că biletul a fost achiziționat.

Rata de succes este o măsură foarte simplă și clară și vă recomand să o folosiți dacă sarcinile dvs. au obiective clare. O privire asupra graficului de succes al sarcinii vă permite să identificați rapid cele mai problematice zone ale interfeței.

Timpul de finalizare a sarcinii. Această valoare este doar indicativă pentru comparație. Cum știi dacă un utilizator finalizează o sarcină în 30 de secunde este bine sau rău? Dar faptul că timpul a fost redus în comparație cu versiunea anterioară a designului este deja bun. Sau faptul că înregistrarea pe proiectul nostru durează mai puțin decât concurenții. Există interfețe în care reducerea timpului pentru finalizarea sarcinilor este critică - de exemplu, interfața de lucru a unui angajat al unui call center.

Cu toate acestea, această măsurătoare nu este aplicabilă pentru toate sarcinile. Să ne luăm sarcina de a selecta un produs într-un magazin online. Utilizatorii ar trebui să găsească rapid filtre și alte elemente de interfață asociate cu căutarea produselor, dar procesul de selecție în sine le va lua în momente diferite, iar acest lucru este complet normal. Atunci când aleg pantofi, femeile sunt gata să se uite prin 20 de pagini cu rezultatele căutării. Și asta nu înseamnă neapărat că nu au fost produse relevante pe primele pagini sau că nu au văzut filtrele. Adesea vor doar să vadă toate opțiunile.

Frecvența problemelor. Orice raport de testare a gradului de utilizare conține o listă a problemelor pe care le-au întâlnit respondenții. Numărul de respondenți care au întâmpinat o problemă este un indicator al frecvenței acesteia în cadrul testului. Această valoare poate fi utilizată numai dacă utilizatorii dvs. au efectuat exact aceleași sarcini.

Dacă au existat variații în test sau sarcinile nu au fost clar formulate, ci au fost compilate pe baza unui interviu, atunci va fi dificil de calculat frecvența. Va fi necesar nu numai să se numere pe cei care au întâlnit-o, ci și să se estimeze câți respondenți ar putea întâmpina problema (a efectuat o sarcină similară, a mers la aceeași secțiune). Cu toate acestea, această caracteristică permite echipei să înțeleagă care probleme ar trebui rezolvate mai întâi.

Satisfacția subiectivă. Aceasta este evaluarea subiectivă a utilizatorului cu privire la confortul sau confortul lucrului cu sistemul. Acesta este dezvăluit folosind chestionare pe care respondenții le completează în timpul sau după testare. Există chestionare standard. De exemplu, Scala de utilizare a sistemului, Chestionar de utilizare post-studiu sau Chestionar privind experiența jocurilor pentru jocuri. Sau vă puteți crea propriul chestionar.

Acestea sunt departe de singurele valori posibile. De exemplu, o listă de 10 metrici UX pe care Jeff Sauro le evidențiază. Pentru produsul dvs., valorile pot fi diferite: de exemplu, la ce nivel înțeleg respondenții regulile jocului, câte greșeli fac atunci când completează formulare lungi. Amintiți-vă că decizia de a utiliza mai multe valori impune o serie de limitări testării. Respondenții trebuie să acționeze cât mai natural posibil și în aceleași condiții. Prin urmare, ar fi bine să oferiți:

  • Puncte de plecare comune. Aceleași sarcini pentru diferiți respondenți ar trebui să înceapă din același punct de interfață. După fiecare sarcină, puteți cere respondenților să revină la pagina principală.
  • Nicio intervenție. Orice comunicare cu un moderator poate afecta valorile de performanță dacă moderatorul sugerează ceva respondentului fără să vrea și crește timpul necesar pentru a finaliza sarcina.
  • Ordinea sarcinilor. Pentru a compensa efectul de învățare în testarea comparativă, asigurați-vă că variați ordinea expunerii la produsele comparate între respondenți. Lăsați jumătate să înceapă cu proiectul dvs. și jumătate cu unul competitiv.
  • Criterii de succes. Gândiți-vă dinainte la ce fel de comportament considerați de succes pentru sarcină: de exemplu, este acceptabil ca respondentul să nu folosească filtre atunci când selectează un produs într-un magazin online.

Interpretarea metricilor

Amintiți-vă că testarea clasică de utilizare este un studiu calitativ, iar valorile pe care le obțineți sunt în primul rând ilustrative. Acestea oferă o imagine de ansamblu asupra diferitelor scenarii dintr-un produs, permițându-vă să vedeți punctele dureroase. De exemplu, crearea unui cont provoacă mai multe dificultăți decât înregistrarea în sistem. Ele pot arăta dinamica schimbării dacă le măsurați în mod regulat. Adică, valorile ne permit să înțelegem că noul design ne permite să îndeplinim sarcina mai rapid. Aceste relații sunt mult mai indicative și de încredere decât valorile absolute ale valorilor găsite.

Jeff Sauro, un expert statistic în cercetarea UX, sfătuiește să nu reprezinte valorile ca medii, ci să folosești întotdeauna intervale de încredere. Acest lucru este mult mai corect, mai ales dacă există variații în rezultatele respondenților. Pentru a face acest lucru, puteți folosi calculatoarele sale online gratuite: pentru succes și pentru timpul de finalizare a sarcinilor. Nu te poți lipsi de procesarea statistică atunci când compari rezultatele.

Când sunt necesare valorile?

Nu toate rapoartele de testare a gradului de utilizare conțin valori. Colectarea și analiza lor necesită timp și impun limitări metodelor de testare. Iată cazurile în care sunt cu adevărat necesare:

  • Dovedi. Adesea este nevoie să se demonstreze că trebuie făcute modificări unui produs, mai ales în companiile mari. Pentru factorii de decizie, numerele sunt vizuale, ușor de înțeles și familiare. Când arăți că 10 din 12 respondenți nu au putut să plătească pentru un articol sau că înregistrarea în sistem durează în medie de două ori mai mult decât concurenții, se acordă rezultatelor cercetării mai multă pondere.
  • Comparaţie. Dacă vă comparați produsul cu alții de pe piață, aveți nevoie și de valori. În caz contrar, vei vedea avantajele și dezavantajele diferitelor proiecte, dar nu vei putea evalua unde se situează produsul tău printre ele.
  • Vezi modificările. Valorile sunt bune pentru testarea regulată a aceluiași produs după ce au fost făcute modificări. Ele vă permit să vedeți progresul după reproiectare și să acordați atenție acelor locuri care au rămas fără îmbunătățiri. Puteți utiliza din nou acești indicatori ca bază de dovezi care vor arăta managementului ponderea investițiilor în reproiectare. Sau doar pentru a înțelege că ai obținut rezultate și mergi în direcția bună.
  • Ilustrați, puneți un accent. Numerele funcționează bine pentru a ilustra probleme importante. Uneori le numărăm pentru cele mai izbitoare și importante momente ale testului, chiar dacă nu folosim metrici în toate sarcinile.

Cu toate acestea, nu folosim valori în fiecare test. Te poți descurca fără ele dacă cercetătorul lucrează îndeaproape cu echipa de proiect, există încredere internă și echipa este suficient de matură pentru a prioritiza corect rezolvarea problemelor.

Metoda de înregistrare a datelor

S-ar părea, ce este în neregulă cu un blocnotes și un stilou sau doar un document Word deschis? În lumea de dezvoltare Agile de astăzi, cercetătorii UX trebuie să încerce să-și aducă descoperirile înapoi echipei cât mai repede posibil.

Pentru a optimiza timpul de analiză, este bine să pregătiți în prealabil un șablon pentru introducerea notelor în timpul testului. Am încercat să facem acest lucru în software specializat (de exemplu, Noldus Observer sau Morae Manager), dar în practică tabelele s-au dovedit a fi cele mai flexibile și universale. Marcați în prealabil în tabel întrebările pe care intenționați să le adresați, locurile de introducere a problemelor găsite în sarcini, precum și ipotezele (pentru fiecare respondent veți marca dacă a fost confirmat sau nu). Semnele noastre arată astfel:

Ce altceva poți folosi:

  • . Șablon Excel personalizabil pentru introducerea observațiilor pentru fiecare respondent. Există un cronometru încorporat care măsoară timpul necesar pentru finalizarea sarcinilor, iar graficele de timp și de succes sunt generate automat.
  • Rainbow Spreadsheet de Tomer Sharon de la Google. Un tabel vizual pentru colaborarea între cercetător și echipă. Linkul duce la un articol care descrie metoda și există, de asemenea, un link către o foaie de calcul Google cu un șablon.

Cu experiență, majoritatea notelor pot fi luate în timpul testului. Dacă nu ați ajuns la timp, este mai bine să notați tot ce vă amintiți imediat după test. Dacă reveniți la analiză după câteva zile, cel mai probabil va trebui să vizionați din nou videoclipul și să petreceți mult mai mult timp.

Pregătirea pentru testare

Pe lângă metodă, metrici și protocolul de testare în sine, trebuie să decideți asupra următoarelor lucruri:

Format de comunicare cu moderatorul. Moderatorul poate fi în aceeași cameră cu participantul la test. În acest caz, îi va fi ușor să pună întrebări la timp. Totuși, prezența unui moderator poate influența respondentul: acesta va începe să-i pună întrebări moderatorului, provocându-l să-l solicite explicit sau implicit.

Încercăm să lăsăm respondentul singur cu produsul pentru cel puțin o parte a testului. Astfel comportamentul lui devine mai relaxat și mai natural. Și pentru a nu alerga înainte și înapoi dacă ceva nu merge bine, puteți lăsa orice messenger cu conexiune audio activată, astfel încât moderatorul să poată contacta respondentul din camera de observație.

Metoda de stabilire a sarcinilor. Sarcinile pot fi anunțate de un moderator. Dar în acest caz, în ciuda protocolului uniform de testare, textul sarcinii poate fi pronunțat ușor diferit de fiecare dată. Acest lucru este valabil mai ales dacă testul este efectuat de mai mulți moderatori. Uneori, chiar și mici diferențe de formulare pot pune respondenții în condiții de plecare diferite.

Pentru a evita acest lucru, puteți fie să „antrenați” moderatorii să citească întotdeauna textele sarcinii, fie să le oferiți respondenților sarcini pe bucăți de hârtie sau pe ecran. Diferențele de redactare încetează să mai fie o problemă dacă folosești un scenariu flexibil, când sarcinile sunt formulate în timpul testului, pe baza unui interviu cu moderatorul.

Puteți utiliza instrumentele produsului pentru a stabili sarcini. De exemplu, la testarea ICQ, respondenții au primit sarcini printr-o fereastră de chat cu un moderator, iar la testarea Mail.Ru Mail, le-au primit prin scrisori. Acest mod de stabilire a sarcinilor a fost cât se poate de firesc pentru aceste proiecte și am testat și scenarii de corespondență de bază de multe ori.

Crearea unui context natural. Chiar dacă vorbim de teste de laborator, gândiți-vă cum să aduceți utilizarea produsului în test mai aproape de condițiile reale. De exemplu, dacă testați dispozitive mobile, cum le vor ține respondenții? Pentru o imagine bună în videoclip, este mai bine atunci când telefonul sau tableta sunt fixate pe un suport sau întinse pe o masă. Cu toate acestea, acest lucru nu arată clar dacă toate zonele sunt accesibile și convenabil de apăsat, deoarece telefoanele sunt adesea ținute cu o singură mână, iar cu tabletele se află pe canapea.

Merită să vă gândiți la mediul în care va fi utilizat produsul: există ceva care distrage atenția persoanei, este zgomotos, există o conexiune bună la internet. Toate acestea pot fi simulate în laborator.

Plan de testare pentru client. Aceasta este, de asemenea, o fază de pregătire importantă, deoarece implică echipa de proiect. Nu trebuie să spuneți clientului toate caracteristicile metodologice ale testului (cum veți comunica cu respondentul, înregistrați datele etc.). Dar asigurați-vă că îi arătați care vor fi sarcinile și ce veți testa pentru ele. Poate că nu ați ținut cont de unele caracteristici ale proiectului sau poate că echipa de proiect va avea idei și ipoteze suplimentare. De obicei ajungem cu un semn ca acesta:

Planul de raportare. Desigur, raportul este scris pe baza rezultatelor studiului. Dar este o bună practică să întocmești un plan de raport înainte de a efectua teste, pe baza scopurilor și obiectivelor studiului. Cu un astfel de plan în fața dvs., puteți verifica scriptul pentru a-ți verifica caracterul complet, precum și să pregătești cele mai convenabile formulare pentru a capta date pentru o analiză ulterioară. Puteți decide că un raport nu este necesar și că un dosar general de observații este suficient pentru dumneavoastră și echipă. Și dacă îți motivezi echipa să o completeze cu tine, asta va fi absolut grozav.

Desigur, puteți doar „lăsați prietenul să folosească produsul” și să vedeți ce dificultăți are. Dar un scenariu bine scris vă va permite să nu ratați problemele importante și să nu împingeți accidental respondentul la răspunsurile de care aveți nevoie. La urma urmei, testarea de utilizare este un experiment simplificat și, în orice experiment, pregătirea preliminară este importantă.

Protocolul pentru orice testare de utilizare constă din următoarele părți:

  • Instruire sau briefing (bun venit, descrierea evenimentului, semnarea documentelor).
  • Interviu introductiv (test de screening, interviu scurt despre utilizarea produsului, context și scenarii).
  • Lucrul cu produsul (sarcini de testare).
  • Colectarea impresiilor finale ale produsului pe baza experienței de testare.

Instruire sau briefing

Indiferent de subiectul testării, orice studiu începe la fel. Ce ar trebui făcut:

Creați o atmosferă. Cunoaște persoana, oferă-i ceai, cafea sau apă, arată-i unde este toaleta. Încercați să relaxați puțin respondentul, deoarece poate fi nervos înainte de eveniment. Aflați dacă a fost ușor să vă găsesc, întrebați cum vă simțiți.

Descrieți procesul. Spuneți-ne ce fel de eveniment îl așteaptă pe respondent, cât timp va dura, din ce părți constă și ce veți face. Asigurați-vă că îi subliniați respondentului că contribuția acestuia va ajuta la îmbunătățirea produsului și că nu testați abilitățile unei persoane. Dacă înregistrați video, avertizați respondentul despre acest lucru și spuneți-i că datele nu vor apărea online. Eu zic cam asa:

Ne aflăm în biroul Grupului Mail.Ru. Astăzi vom vorbi despre proiectul XXX. Acest lucru va dura aproximativ o oră. Mai întâi vom vorbi puțin, apoi vă voi ruga să încercați să faceți ceva în proiectul în sine, apoi vom discuta despre impresiile dvs. Vom înregistra ce se întâmplă în cameră și pe ecranul computerului. Înregistrarea este necesară doar pentru analiză, nu vă veți vedea pe Internet.

Facem cercetări pentru a îmbunătăți proiectul XXX, pentru a înțelege ce trebuie să fie fixat în el și în ce direcție ar trebui să se dezvolte. Prin urmare, vă rog să exprimați deschis orice comentarii: atât pozitive, cât și negative. Nu-ți fie teamă să ne jignești. Dacă ceva nu îți merge în timp ce studiezi un proiect, ia-l cu calm. Aceasta înseamnă că am găsit o problemă pe care echipa de proiect trebuie să o rezolve. Principalul lucru este să vă amintiți că nu vă testăm, voi testați produsul. Dacă sunteți gata, vă sugerez să începeți.

Să semneze documente. De regulă, acesta este consimțământul pentru prelucrarea datelor cu caracter personal și, uneori, și un acord privind nedezvăluirea informațiilor despre testare. Pentru testele cu minori, este necesar acordul părinților pentru ca copilul lor să participe la studiu. De obicei o trimitem părinților în avans și le rugăm să-l aducă cu ei. Asigurați-vă că explicați de ce solicitați să semnați documentele și acordați-le timp să le examineze. În Rusia, oamenii se feresc de orice documente care trebuie semnate.

Configurați echipamentul. Dacă utilizați urmărirea ochilor, echipamente biometrice sau pur și simplu înregistrați videoclipuri, acum este momentul să activați totul. Avertizați respondentul când începeți înregistrarea.

Interviu introductiv

Rezolvă următoarele probleme:

Verificați recrutarea. Pentru a fi sigur, începeți întotdeauna de acolo - chiar dacă aveți încredere în agenția sau persoana care a găsit respondentul. De mai multe ori în timpul testului am aflat că respondentul a înțeles greșit întrebările și de fapt nu a folosit produsul exact așa cum aveam nevoie. Încercați să evitați formalitățile și să evitați să puneți întrebări din chestionarul de screening: persoana poate ști deja ce să răspundă.

Scenarii și context pentru utilizarea produsului. Chiar dacă nu ai mult timp pentru test, nu sări peste acest pas. Cel puțin în general, află de la respondent ce probleme rezolvă cu ajutorul produsului, dacă folosește proiecte similare, în ce condiții interacționează cu acestea și de pe ce dispozitive. Răspunsurile vă vor ajuta să înțelegeți mai bine motivele comportamentului respondentului și, dacă utilizați un scenariu flexibil, atunci vă vor ajuta să formulați sarcini adecvate. Dacă aveți suficient timp, cereți respondentului să arate ce și cum face de obicei. Aceasta poate fi o sursă de întrebări și perspective suplimentare.

Așteptări și relații.Începutul testării este un moment bun pentru a afla ce știe respondentul despre produs, ce simte despre acesta și ce așteptări de la acesta. După test, vei putea compara așteptările tale cu impresia finală.

Pentru majoritatea testelor, această structură introductivă a interviului va funcționa. Dacă testați un produs nou, poate doriți să omiteți întrebările introductive. Dacă intrați în prea multe detalii despre un subiect, acesta poate crea anumite așteptări pentru utilizator cu privire la produs. Prin urmare, lăsați doar câteva întrebări generale pentru a stabili contactul cu respondentul și treceți imediat la sarcini și este mai bine să discutați scenarii, relații și context după ce utilizatorul a studiat inițial produsul.

Lucrul cu produsul, scrierea sarcinilor

Care sunt sarcinile?

Să ne imaginăm că vrei să testezi un magazin online. Aveți scenarii importante (căutarea și selecția mărfurilor, procesul de comandă), probleme cunoscute (erori frecvente în formularul de plată) și chiar o ipoteză că proiectantul a greșit cu filtrul de preț. Cum să formulezi sarcini?

Sarcini concentrate. Pare evident să faci ceva de genul acesta: „Alegeți o mașină de spălat vase de 45 de centimetri lățime cu o funcție de fascicul de podea care nu costă mai mult de 30 de mii de ruble”. Acest lucru îl motivează pe respondent să folosească filtre și să compare produsele între ele. Puteți verifica filtrul de preț pentru toți respondenții și puteți analiza scenariul cheie pentru selectarea unui produs. Astfel de sarcini au dreptul la viață și sunt bune pentru testarea unor ipoteze specifice (ca și în cazul filtrului de preț).

Cu toate acestea, dacă întregul test constă din ele, atunci riscați următoarele:

  • Verificarea interfeței la fața locului. Veți găsi doar probleme care sunt legate de detaliile postului (filtrați după preț și lățime). Nu veți vedea alte probleme - cum ar fi sortarea produselor sau alte filtre - decât dacă le subliniați și ele. Dar este puțin probabil să reușiți să finalizați sarcini pentru toate elementele site-ului.
  • Lipsa de implicare. Utilizatorii efectuează adesea astfel de sarcini mecanic. Când văd primul produs care corespunde criteriilor, se opresc. Poate că respondentul nu a ales niciodată o mașină de spălat vase în viața sa și nu-i pasă ce este o „grindă pe podea”. Cu cât o sarcină este mai asemănătoare cu o situație din viața reală și cu cât oferă mai mult context pe care utilizatorul îl poate înțelege, cu atât sunt mai mari șansele de a implica un respondent care va pretinde că alege cu adevărat un produs. Iar un utilizator implicat „trăiește” mai bine interfața, lasă mai multe comentarii, își crește șansele de a găsi probleme și de a oferi cunoștințe utile despre comportamentul și caracteristicile publicului.
  • Gamă restrânsă de perspective. În viața reală, utilizatorul ar selecta probabil un produs complet diferit. De exemplu, nu aș folosi filtre deloc (și aici le-ați subliniat). Sau as cauta un produs pe baza unor criterii care nu sunt pe site. Oferind sarcini rigide, concentrate, nu veți afla despre contextul real al utilizării produsului, nu veți găsi scenarii pe care echipa de proiect ar putea să nu le fi prevăzut și nu veți colecta date despre nevoile de conținut și funcționalități.

Sarcini cu context. O modalitate de a implica mai bine utilizatorii este să adăugați istoric și context real unei sarcini grele. De exemplu, în loc de „Găsiți o rețetă de plăcintă cu prune pe site”, sugerați următoarele: „Veți avea oaspeți într-o oră. Găsiți ceva de coacere în această perioadă. Aveți de toate pentru biscuiți la frigider, precum și câteva prune. Dar, din păcate, nu există unt.”

O abordare similară poate fi utilizată cu un magazin online. De exemplu: „Imaginați-vă că alegi un cadou pentru sora ta. Uscatorul ei de par s-a stricat recent si ar fi bucuroasa sa-si ia unul nou. Trebuie să îndeplinești 7 mii de ruble.” Este important ca respondentul să aleagă cu adevărat o persoană reală căreia îi va „cumpăra” cadoul (dacă nu există soră, sugerați o altă rudă sau un prieten). Factorul cheie pentru astfel de sarcini este realitatea și claritatea contextului. Este ușor să-ți imaginezi că alegi un cadou pentru familia ta, dar este mult mai dificil să-ți imaginezi că ești „un contabil care pregătește un raport anual”.

Un exemplu izbitor al acestei abordări este „metoda Bollywood”, care a fost inventată de expertul indian UX Apala Lahiri Chavan. Ea susține că indienilor, la fel ca mulți asiatici, le este greu să vorbească deschis despre interfață. Dar, imaginându-se ca eroi ai situațiilor dramatice fictive (ca în filmele lor preferate), se deschid și încep să participe activ la testare. Prin urmare, sarcinile pentru indieni ar trebui să arate cam așa:

Imaginează-ți că tânăra ta nepoată iubită se căsătorește. Și apoi afli că viitorul ei soț este un fraudator și, de altfel, căsătorit. Trebuie să cumpărați urgent două bilete de avion spre Bangalore pentru dvs. și pentru soția înșelatorului, pentru a supăra nunta și a salva familia de rușine. Grabă!

Sarcini bazate pe experiența respondenților. Să vă reamintim: pentru testarea cu succes, respondenții trebuie să corespundă publicului proiectului. Prin urmare, pentru a verifica un magazin online de electrocasnice, îi recrutăm pe cei care au ales recent electrocasnice sau le aleg acum. Este exact ceea ce vom folosi atunci când creăm sarcini pe baza experienței respondenților. Există două opțiuni pentru utilizarea acestei abordări:

  • Parametrii respondentului. În acest caz, adaptați sarcinile fixe respondenților. De exemplu, în cazul unui magazin de electrocasnice și a unei sarcini de lucru cu filtre, îl întrebi pe persoană ce anume a achiziționat recent. Aflați criteriile (preț, funcții) și propuneți să repetați „cumpărarea” pe site-ul dvs.
  • Scenariile respondenților. Sarcinile sunt complet formate pe baza experienței participanților. Pentru a înțelege ce scenarii să verifice, moderatorul află exact cum a rezolvat persoana problema în viață și sugerează să o facă pe site. De exemplu, un cumpărător a petrecut mult timp comparând mai multe modele înainte de a alege. Chiar dacă site-ul nu are o funcție adecvată, invitați respondentul să compare produse pentru a înțelege pe ce parametri se va baza. Poate că veți obține idei despre cum ar trebui să arate funcția de comparare și, de asemenea, veți adapta pagina produsului la acest scenariu.

Astfel de sarcini oferă multe exemple reale de efectuare a operațiunilor de bază într-un produs. Acest lucru dă adesea naștere la o gamă mult mai largă de probleme și constatări. În plus, vă permite să testați produsul pe noi scenarii pe care nu le-ați considerat de bază sau nici măcar nu le-ați gândit.

Când am testat proiectul Mail.Ru Real Estate, sarcinile bazate pe experiența respondenților ne-au ajutat să facem multe descoperiri. Am văzut că atunci când caută un apartament în regiunea Moscovei, oamenii indică în geofiltru stațiile finale de metrou, adică acestea sunt stații la care se poate ajunge din regiune. Ne asteptam ca filtrul de metrou sa caute un apartament langa statie. De asemenea, am aflat cum diferă scenariile de căutare pentru clădiri noi de cele secundare, ceea ce a ajutat la mutarea căutării clădirilor noi într-o altă secțiune a site-ului - cu propriile filtre și propriul concept de descriere a apartamentelor. De asemenea, vă recomand să citiți articolul excelent al lui Jared Spool despre beneficiile unor astfel de sarcini.

Misiuni fără sarcini. Uneori este mai bine să nu oferi utilizatorilor sarcini pentru a lucra cu proiectul, ci să vezi unde încep ei înșiși să se familiarizeze cu produsul. Oferă respondentului o introducere: „Imaginați-vă că vă decideți să încercați acest produs. Te las câteva minute. Fă ceea ce ai face în viața reală. Nu vă dau nicio sarcină”.

Este important ca moderatorul să părăsească sala în acest moment. În caz contrar, utilizatorul este tentat să întrebe imediat ceva, să clarifice: „Trebuie să mă înregistrez? Cum pot face acest lucru?" și așa mai departe.

Acest tip de sarcină este util pentru produse complet noi. Îl folosim adesea pentru aplicații și jocuri mobile. Așa aflăm dacă utilizatorii citesc materiale de instruire, ce detalii atrag imediat atenția, ce înțeleg oamenii despre conceptul de produs și cum îi descriu apoi capacitățile. După sarcina gratuită sunt planificate scenarii specifice.

Un alt domeniu de aplicare pentru sarcinile gratuite sunt proiectele de conținut. Dacă vrei să înțelegi cum sunt citite articolele tale (unde zăbovesc mult timp, ce opresc, la ce elemente din pagină acordă atenție), atunci pur și simplu lasă respondentul singur cu proiectul pentru câteva minute. Numai fără ca un moderator să se uite peste umăr, utilizatorul se va relaxa și va citi textul în același mod ca de obicei. Așa testăm proiectele „Mail.Ru News”, „Mail.Ru Lady” și altele. Această abordare a făcut posibilă identificarea diferitelor modele de comportament pe site, diferite modele de citire a articolelor și înțelegerea tipurilor de materiale care ar trebui formatate diferit.

Efectuarea unor sarcini bune

Prima sarcină este simplă.Începeți testarea cu sarcini introductive și simple. Respondentul trebuie să se simtă confortabil cu formatul testului, mai ales dacă utilizați metoda gândirii cu voce tare: trebuie să se obișnuiască să fie nevoit să își verbalizeze gândurile și sentimentele. Nu ar trebui să aruncați imediat toată durerea și suferința interfeței pe ea.

Nu-mi da niciun indiciu. Formulați sarcinile astfel încât să nu-l determine pe respondent să facă ceea ce trebuie. Dacă doriți să testați capacitatea de a adăuga produse la favorite într-un magazin online, faceți fără sarcina „Să adăugăm acest televizor la favorite”, mai ales dacă butonul este numit astfel. Respondentul, după ce a citit sarcina, va găsi pur și simplu un buton pe ecran cu semnătura dorită - poate chiar fără să înțeleagă ce face exact.

Este mai bine să explicați sensul sarcinii fără a recurge la termeni din interfață. De exemplu: „Pe site puteți salva produsele care vă plac și apoi alegeți pe care să le comandați. Să încercăm să facem asta cu așa și cu un televizor.”

Urmăriți terminologia. Nu folosiți cuvinte și simboluri neclare. Acest lucru pare evident, dar noi, obișnuiți cu anumiți termeni, uităm adesea că puțini oameni din afara comunității IT îi cunosc. De exemplu, la testarea noii funcționalități de fire (lanțuri de litere) în Mail.Ru Mail, am avut o perioadă dificilă. La urma urmei, utilizatorii care nu sunt familiarizați cu această funcție pur și simplu nu au în cap un termen care să desemneze fire.

Până la urmă, nu le-am numit nimic. Pur și simplu le-am arătat respondenților o casetă cu fire conectate și am discutat despre această nouă caracteristică și le-am lăsat utilizatorilor să aleagă cuvântul pentru a desemna firele. Acest lucru ne-a ajutat să folosim mai târziu cele mai înțelese texte în materiale promoționale educaționale.

Urmăriți nu numai temele, ci și întrebările moderatorului, în special cele care vin de la echipă în timpul testării. De exemplu, atunci când discutați despre funcții, nu ar trebui să utilizați cuvântul „bară de instrumente”: nu toată lumea este familiarizată cu el. Cu doar câțiva ani în urmă, nu toți utilizatorii cunoșteau nici măcar cuvântul „browser”. Cel mai bun mod de a formula sarcini depinde de publicul de testare. Nu ar trebui să mergi la cealaltă extremă, explicând toți termenii la rând. De exemplu, jucătorii cu experiență nu trebuie să explice ce sunt „buff”, „frag”, „respawn” și așa mai departe.

Mai puține teste. Este adesea tentant să creați un cont de testare pentru respondent în sistem și să efectuați testarea acestuia. La urma urmei, puteți testa totul în acest cont în avans, evitați problemele și nu pierdeți timpul cu înregistrarea sau autorizarea unui respondent. Este adesea, de asemenea, mult mai ușor din punct de vedere tehnic să implementați un nou design pe date de testare, mai degrabă decât pe date reale.

Cu toate acestea, cu această abordare riști să obții rezultate mult mai puțin utile, deoarece acțiunile de testare nu au consecințe reale. Situația devine complet artificială, este dificil pentru utilizatori să o proiecteze în experiența reală.

De exemplu, atunci când lucrează pe cont propriu pe o rețea de socializare, respondenții, ca în viața reală, vor face cu atenție tot ceea ce pot vedea prietenii lor (publică link-uri, trimit mesaje). Când își configurează propria căsuță poștală, ei vor încerca să nu ștergă scrisorile importante. La testarea magazinelor online, uneori se folosește o abordare în care recompensa trebuie cheltuită direct în timpul testului. În acest caz, respondentul nu va atinge primul produs care se potrivește sarcinii, ci va selecta ceea ce are de fapt nevoie.

Cu doar date de testare, veți găsi probleme asociate numai cu acestea, mai degrabă decât să testați funcționalitatea pe diferite variante. De exemplu, când am testat panoul social al browserului Amigo, unul dintre respondenți, care și-a conectat contul VKontakte la panou, a observat imediat că îi era incomod să citească în acest fel. Aproape întregul feed a constat din abonamente la grupuri cu fotografii erotice. Și în panoul îngust din imagini era pur și simplu imposibil să vezi ceva.

O altă problemă cu datele de testare este că este dificil de înțeles sistemul, deoarece totul în jur este neobișnuit. De exemplu, un utilizator al rețelei sociale este obișnuit să-și recunoască pagina după propria fotografie. Chiar și atunci când testăm prototipuri, încercăm să le personalizăm cât mai mult posibil. De exemplu, atunci când testăm prototipuri pe care se poate face clic în Odnoklassniki, le adaptăm întotdeauna pentru fiecare utilizator, inserând numele și fotografia acestuia și, uneori, ultimele știri, pe pagină.

Nu vă lăsați limitat de interfață. Nu uitați că interacțiunea cu un produs nu se limitează adesea doar la interfață. Dacă este posibil, testați produse sau servicii conexe și conexiunile dintre ele. Când testăm jocuri, încercăm să verificăm nu numai jocul, ci și site-ul său web și descărcările asociate, înregistrarea în joc și căutarea de informații pe forum. Și când am testat un magazin online, am verificat și apelul operatorului după plasarea unei comenzi, care dădea recomandări pentru call center.

Gândește-te la sincronizare. Pentru un scenariu bun, este important să prioritizați sarcinile. Cel mai probabil, dacă sistemul este mare și testul are multe obiective, vei dori să faci o mulțime de sarcini. Cu toate acestea, un respondent obosit nu va mai fi de folos. Un test bun nu durează mai mult de o oră și jumătate, doi este maxim. Excepția sunt poate jocurile. Și amintiți-vă că obiectivele dvs. nu sunt doar sarcini, ci și interviuri, chestionare, amenajarea echipamentelor și semnarea documentelor. Toate acestea durează de obicei cel puțin o jumătate de oră.

Dacă sunt prea multe sarcini și nu vrei să renunți la unele, poți să le pui pe cele mai puțin prioritare în rotație, adică să arăți doar părți din respondenți. Sau faceți o parte din test obligatorie pentru toată lumea și urmăriți restul doar cu cei cu timp suficient. Dar aceștia vor fi cel mai probabil cei mai de succes respondenți.

Evaluați utilitatea sarcinii. Luați în considerare dacă într-adevăr se potrivește ipotezelor dvs. De exemplu, doriți să testați funcția de abonare la știri pe un site web. Sarcina „Abonare la newsletter” va verifica doar dacă newsletter-ul poate fi găsit de cei care îl caută. Cu toate acestea, oamenii vin rar pe site pentru a se abona la știri. Sarcina nu se aplică vieții reale. Trebuie să înțelegeți dacă oportunitatea de a vă abona este observată de cei care îndeplinesc sarcini complet diferite.

Acest lucru poate fi verificat în diferite moduri, în funcție de implementarea funcției. Dacă o persoană a fost angajată în sarcini în care ar fi văzut opțiunea de abonament, întreabă-l dacă se află pe site. Asigurați-vă că clarificați unde a văzut această oportunitate sau cum a fost implementată pentru a vă asigura că respondentul nu este doar de acord cu dvs.

Dacă o ofertă de abonament este inclusă în procesul de înregistrare sau de plată, vedeți dacă respondentul profită de ea și discutați-o după sarcină. Există foarte puține șanse ca în condiții de laborator oamenii să se aboneze efectiv la liste de corespondență, dar puteți verifica dacă o persoană a acordat atenție acestei oportunități, ce așteaptă de la lista de corespondență și așa mai departe.

Culegere de impresii finale

Scopul fazei finale de testare este de a colecta impresii despre lucrul cu produsul, de a înțelege ce i-a plăcut utilizatorului și ce l-a supărat și de a evalua satisfacția subiectivă. De obicei, această parte a testului folosește o combinație între un interviu cu un moderator și completarea chestionarelor formale.

Interviu cu moderatorul

În interviul final, le punem întotdeauna respondenților aproximativ aceleași întrebări: „Care au fost impresiile tale?”, „Ce ți-a plăcut și ce nu?”, „A fost ceva care părea dificil sau incomod?”, „Ce a fost lipsește?” , „Ce ați dori să schimbați în produs?” Este timpul să clarificați aspectele neclare ale comportamentului respondentului dacă nu ați făcut acest lucru în timpul testului. Dacă, înainte de test, ați aflat de la utilizatori atitudinea lor față de marcă sau produs și așteptările lor de la acesta, aflați dacă s-a schimbat ceva. La interviu, acordați atenție următoarelor:

Dezirabilitatea socială. Gestionați cu mare atenție rezultatele interviului. Dacă în timpul testului auziți adesea comentarii impulsive sub influența problemelor, atunci în interviul final va înflori dezirabilitatea socială.

Unii oameni simt că atunci când vorbesc despre problemele unui produs, își recunosc propria incompetență. Alții pur și simplu nu vor să supere un moderator plăcut. Foarte des, respondenții (în special femeile) care au suferit întregul test spun că totul este, în principiu, normal. Feedback-ul negativ poate fi dictat și de dezirabilitatea socială: dacă respondentul crede că scopul testului este de a găsi defecte, el încearcă cu sârguință să le găsească.

Citate și priorități. Deși toate cuvintele testatorilor din interviul final trebuie adesea împărțite la doi sau chiar zece, asta nu înseamnă că sunt inutile. Pe baza modului în care respondenții își rezumă impresiile, puteți deduce priorități. Este produsul „prostie completă”? Ce anume a influențat asta? Care dintre multele probleme își amintește cel mai mult respondentul și le consideră cele mai enervante?

Cu toate acestea, luați în considerare faptul că ultima sarcină este cel mai bine reținută. De asemenea, este foarte util să urmăriți ce adjective folosesc respondenții pentru a descrie produsul și cu ce își compară experiența.

Să nu uităm de bine. Foarte des, un raport de testare a gradului de utilizare este o listă lungă de probleme găsite în timpul testului. În general, găsirea problemelor este una dintre sarcinile principale ale cercetării. Dar nu uitați de aspectele pozitive ale produsului.

În primul rând, un raport fără rezultate pozitive pur și simplu demotivează echipa. Și, în al doilea rând, este util să știm ce le place utilizatorilor la produs: ce se întâmplă dacă în timpul următoarei reproiectări ei decid să elimine caracteristica care le-a plăcut atât de mult tuturor. Prin urmare, asigurați-vă că întrebați respondenții despre aspectele pozitive ale produsului, chiar dacă au criticat interfața pe parcursul testării.

Atitudine față de „dorințe”. Cel mai probabil, respondenții, pe lângă impresiile lor, își vor exprima dorințe și idei. Sarcina ta este să înțelegi ce problemă se află în spatele propunerilor. Pentru că soluțiile oferite de utilizatori, cel mai probabil, nu ți se potrivesc. La urma urmei, participanții la testare nu sunt designeri, nu sunt conștienți de caracteristicile și limitările dezvoltării. Cu toate acestea, în spatele oricărei astfel de solicitări există o nevoie pe care trebuie să o captezi. Dacă un respondent spune că are absolut nevoie de un buton verde mare aici, asigurați-vă că întrebați: de ce?

Măsura satisfacției

Adesea, conform cuvintelor respondentului din interviul final, este greu de înțeles dacă produsul i-a plăcut sau nu și cu atât mai dificil de comparat atitudinea mai multor respondenți care au remarcat atât avantaje, cât și dezavantaje. Aici chestionarele vin în ajutorul cercetătorului. În primul rând, la completarea chestionarului (mai ales înainte de a vorbi cu moderatorul), influența notoriei dezirații sociale este puțin mai mică, deși nu veți scăpa complet de ea. În al doilea rând, chestionarul vă oferă parametri clari pentru compararea scenariilor, produselor sau etapelor proiectului.

Alcătuirea unui chestionar bun este un subiect separat și foarte amplu. Formularea, scalele și multe altele sunt importante aici. Chestionarele gata făcute și dovedite pot fi de mare ajutor: au fost deja perfectionate și testate de multe ori. Singura problemă este că aproape toate aceste chestionare nu au traduceri oficiale în rusă. Desigur, le puteți traduce singur, dar din punct de vedere metodologic, traducerile trebuie testate pentru a verifica corectitudinea formulării. Cu toate acestea, chestionarele pot servi drept ghid atunci când vă creați propriile chestionare.

Există chestionare care sunt date după fiecare sarcină pentru a evalua satisfacția față de scenarii specifice. De exemplu:

  • Chestionarul după scenariu (ASQ). Trei întrebări despre complexitate, productivitate și indicii în sistem.
  • Întrebare simplă unică (SEQ) . O întrebare despre complexitatea scenariului.

Și există chestionare care sunt folosite deja în faza finală a testării. Iată câteva exemple pe care le folosim atunci când este necesar:

  • Scala de utilizare a sistemului și Chestionarul de utilizare a sistemului post-studiu. Două chestionare clasice și populare create cu mai bine de 20 de ani în urmă. Ambele constau în declarații. Respondenții trebuie să indice nivelul lor de acord cu ei. Toate aceste afirmații caracterizează capacitatea de utilizare a produsului din diferite unghiuri. De exemplu: „Aș putea găsi cu ușurință informațiile de care aveam nevoie”, „Diferitele capabilități ale sistemului sunt ușor accesibile” și așa mai departe.
  • . Un chestionar care ne ajută adesea în timpul testelor. Utilizatorului i se pune la dispoziție un set de adjective din care le selectează pe cele care pot caracteriza produsul. Ca rezultat, obțineți un nor de cuvinte - caracteristici ale proiectului dumneavoastră. Adesea, această tehnică aduce rezultate foarte interesante.
  • Chestionar privind experiența jocului. Chestionarele clasice de utilizare nu pot fi aplicate la jocuri: implicarea în joc este mult mai importantă decât înțelegerea interfețelor. Prin urmare, ar trebui să creați întotdeauna chestionare speciale pentru jocuri sau să utilizați Chestionarul privind experiența jocului. Chestionarul conține mai multe module: un modul de bază, un bloc în joc, un post-chestionar și un chestionar despre capacitățile sociale ale jocului.
  • Material publicat de utilizator. Faceți clic pe butonul „Scrie” pentru a vă împărtăși opinia sau a vorbi despre proiectul dvs.

Proiectarea unui produs, site web sau aplicație este un proces foarte lung care necesită răbdare, perspectivă și o serie de instrumente. Pentru a înțelege ce funcționează de fapt și ce nu, este important să știți ce cred utilizatorii. Aici intervine testarea utilizatorilor.

Unind forțele, UXPin, UserTesting și Optimal Workshop au decis să descrie procesul UX pe care l-au urmat pentru un Yelp ipotetic:

Întregul proces a fost mai mult ca un sprint de design, constând din proiecte de 1-3 săptămâni axate pe rezolvarea unor probleme specifice.

O scurtă prezentare a procesului de proiectare UX

1. Definirea produsului

În etapa inițială, specialiștii au determinat propunerea de valoare, avantajul nedrept și modelul general de afaceri. Deoarece Yelp a avut deja un succes semnificativ în atragerea de vizitatori, au decis că ar fi interesant să înțeleagă cum ar putea crește frecvența de utilizare. În continuare, a fost elaborat un plan general de testare.

2. Testare și analiză

În timpul fazei de explorare, echipa a revizuit în detaliu planul de testare și a trecut la sesiuni nemoderate. Au fost determinate datele demografice ale utilizatorilor și au fost detaliate sarcini specifice. Pe parcursul lucrărilor au fost folosite diverse metode de testare, de la analiza înregistrărilor interacțiunilor utilizatorilor cu site-ul, sortarea cardurilor de la distanță și testarea primului clic.

Potrivit UserTesting, unul dintre principiile principale ale testării de utilizare este utilizarea sarcinilor generale și specifice. Primul vă permite să aflați ce cred utilizatorii, în timp ce cel din urmă dezvăluie motivele dezamăgirii.

În timpul tuturor testărilor, dezvoltatorii au aderat la următoarele principii:

  • Procesarea textului.În scop de extracție beneficiu maxim specialiștii au ajustat instrucțiunile de mai multe ori pentru a se asigura că limbajul era cât mai concis și au încurajat acțiuni specifice. Aceasta este o condiție prealabilă pentru testarea la distanță nemoderată, deoarece instrucțiunile scrise sunt singurele directive pentru participanți.
  • Dirijare (test pilot). Odată ce instrucțiunile au fost gata, a fost efectuată testarea la distanță nemoderată cu un utilizator din grupul de testare. De asemenea, a oferit feedback cu privire la instrucțiunile în sine, astfel încât echipa să poată corecta probleme minore și să asigure o claritate deplină.
  • Furnizarea sarcinilor cu întrebări relevante. Pentru fiecare sarcină, participantul la test a trebuit să răspundă la întrebarea „A fost finalizată sarcina?”, precum și „Evaluați nivelul de ușurință/dificultate”. Răspunsul la prima întrebare a arătat clar dacă sarcina era fezabilă; în timp ce al doilea ne-a permis să aprofundăm posibilele îmbunătățiri ale designului.
  • Evitarea întrebărilor conducătoare. Testarea a folosit întrebări precum „Cât de ușor sau dificil a fost pentru dvs. să finalizați această sarcină?” în loc de „Cât de dificilă a fost această sarcină?”, ceea ce împiedică posibilitatea unui răspuns părtinitor.

Pentru a colecta date calitative și cantitative, specialiștii au efectuat trei teste de utilizare de la distanță, fiecare dintre ele implicat cel puțin 5 persoane. După identificarea punctelor dureroase, au dezvoltat fluxuri de sarcini, simulând pașii fiecărui utilizator pe baza designului curent. După ce le-au analizat și au identificat defectele de utilizare, au îmbunătățit fluxurile, care au servit ca principii functionale reproiectare.

3. Proiectare și iterare

Glen Lipka, vicepreședintele User Experience, consideră că o interfață de utilizare consistentă este mai bună decât o interfață de utilizator perfectă. Consecvența generează recunoaștere, care, la rândul său, duce la conversii mai frecvente. Mai jos sunt câteva principii directoare:

  • Design pentru informare. Oamenii folosesc site-urile web nu pentru a admira modele frumoase, ci pentru că au nevoie de conținut. În cazul descris, având în vedere că Yelp este un site de căutare pe piața locală de servicii, este nevoie de o reproiectare livrare mai buna informația potrivită pentru oamenii potriviți, iar testarea arhitecturii informaționale folosind sortarea cardurilor a fost o parte integrantă a acestui proces.
  • Urmând principiul MAYA (Cel mai avansat și totuși acceptabil)., „cel mai avansat și în același timp perceput”. În timp ce echipa a vrut să ofere cea mai buna experienta pentru utilizatorul ocazional de Yelp, nu au vrut să creeze ceva atât de străin încât să-i dezactiveze utilizatori experimentați sau confunda pe altele noi.
  • Studierea modelelor de interfață cu utilizatorul. Au fost studiate modelele existente interfața cu utilizatorul pe alte site-uri cunoscute și am găsit ceva care ar putea fi adoptat de la ei.
  • Faceți site-ul plăcut și ușor de utilizat (utilizabil). Experiența pentru utilizatorii ocazionali Yelp trebuia să fie mai clară. În același timp, specialiștii au dorit să mențină un aspect plăcut aspect site-ul.

Scopul final era atingerea unui maxim local. Proiectul a fost finalizat odată ce costurile au depășit beneficiile iterației suplimentare. Având în vedere timpul limitat al sprintului de design, dezvoltatorii nu s-au concentrat pe atingerea maximului global.

Înțelegeți-vă afacerea înainte de a testa

Înainte de a începe să lucrați la UX, trebuie mai întâi să vă înțelegeți afacerea. Ce probleme rezolvă, cum aduce bani? În ce moduri are succes și în ce moduri poate fi îmbunătățit?

Astfel, în prima etapă a reproiectării, analizezi modelul de afaceri, identifici îmbunătățirile necesare UX, iar apoi te decizi asupra ipotezelor și a unui plan de testare.

Pentru primul pas, experții au ales pentru că este o vizualizare simplă și în același timp cuprinzătoare a afacerii:

Nu vă vom plictisi cu toată documentația, așa că uitați-vă la cum puteți face acest lucru în scopuri UX pe Exemplu de Yelp:

  • Cel mai problema principala: Oamenii dintr-un anumit oraș doresc [cel mai bun/cel mai rapid/cel mai ieftin/cel mai ușor] [produs/serviciu].
  • Cele mai de bază 3 funcții: recenzii utilizatorilor, flux de activitate, căutare după oraș/categorie.
  • Propunere de valoare unică: abilitatea de a enumera companii, de a adăuga recenzii și de a vedea companii recomandate de prieteni și de alți utilizatori.
  • „Avantaj nedrept” (ceea ce nu poate fi copiat sau cumpărat): Efectele de rețea ale unei baze mari de utilizatori.

Cel mai Puncte importante sunt funcția de căutare și arhitectura informației. Dacă oamenii nu găsesc ceea ce au nevoie, nu vor scrie recenzii. Reproiectarea ar trebui să organizeze și să direcționeze cel mai bine oamenii către informațiile de care au nevoie.

2. Definirea obiectelor de testare utilizator

Având în vedere baza de utilizatori deja imensă a site-ului, s-a decis ca cele mai interesante domenii de cercetare să fie rata de accesare și reținerea utilizatorilor. Potrivit lui Neil Patel, director general QuickSprout, adăugarea sau eliminarea caracteristicilor poate adăuga valoare produsului. Pe baza acestor considerente, ne-am decis asupra întrebărilor necesare:

  • Ce caracteristici folosesc oamenii atunci când aleg un restaurant? (de exemplu, fotografii, evaluări etc.)
  • Utilizatorii pot alege un restaurant pe baza mai multor criterii specifice?
  • Știu utilizatorii cum să salveze variantele?
  • Pot afla dacă o anumită locație este deschisă în prezent?

3. Selectarea metodelor de testare

Deoarece proiectul descris s-a bazat pe sprinturi de design, dezvoltatorii și-au dorit să fie cuprinzător, dar și rentabil. Alegerea a fost făcută în favoarea testării la distanță nemoderată, care a inclus analiza sortărilor de carduri filmate, sortarea arborilor și testarea la primul clic. Cu ajutorul acestor teste, experții au putut afla cum participanții la test folosesc produsul în viața lor, ce informații acordă prioritate și ce acțiuni sunt cele mai populare.

Planificarea și colectarea datelor calitative

Testarea de utilizare de la distanță folosind un software special (de exemplu, UserTesting) pentru a înregistra ecranul și vocea participantului, vă permite să vedeți acțiunile utilizatorului și să auziți gândurile acestuia în timp ce acesta îndeplinește o anumită sarcină.

Pentru a efectua testarea utilizatorilor, mai întâi trebuie să determinați care public se potrivește obiectivelor dvs. de cercetare.

În cazul nostru a fost utilizatorii actuali Yelp, care a vizitat acest site ocazional.

Criteriile de selecție precum vârsta, sexul, nivelul de venit sau nivelul de cunoștințe de internet nu au fost importante. Deoarece acest studiu a fost realizat exclusiv în scopul analizei calitative, studiul nu a necesitat semnificație statistică pentru a confirma concluziile. Ei au urmat cele mai bune practici din industrie și și-au efectuat studiul cu 5 utilizatori. În cele din urmă, pentru a menține sprintul de design simplu, au testat Yelp doar pe un computer desktop.

Scopul testării a fost de a afla cum acești utilizatori fac față mai multor sarcini de natură generală (pentru a determina cele mai multe funcții importante) și prin macar, cu o sarcină mai puțin obișnuită (pentru a afla dacă știu să folosească funcții mai avansate).

Sarcinile generale au inclus:

  • Sarcină concentrată - găsiți o companie pe baza unor parametri specifici
  • Sarcină deschisă - găsiți o companie cu foarte puține directive
  • O sarcină foarte specifică - găsiți un loc anume și aflați informație specifică despre el

Dezvoltatorii au fost interesați să afle cum interacționează utilizatorii cu filtrele și pe ce bază aleg o anumită companie.

Pentru sarcini mai puțin obișnuite, au oferit diverse opțiuni pentru fiecare grup de utilizatori. Deoarece au existat mai multe reclamații din partea utilizatorilor înregistrați Yelp cu privire la funcțiile Marcaje și Listări, Yelp a cerut utilizatorilor înregistrați (Grupul 1) să salveze compania pentru referințe viitoare. Pentru utilizatorii fără conturi (grupul 2), sarcina a fost să găsească un eveniment. Era important să vedem dacă vor folosi sau nu funcția de căutare atunci când vor îndeplini această sarcină și cum vor lua o decizie cu privire la evenimentul să participe.

La sfârșitul fiecărei sarcini, participanții au fost rugați să noteze dacă au avut succes în îndeplinirea sarcinii și să evalueze nivelul de dificultate sau ușurința de a o îndeplini.

După selectarea subiecților și pregătirea întrebărilor de testare, a fost efectuată testarea utilizatorului în sine, iar o oră mai târziu au fost primite înregistrări video pentru analiză ulterioară.

Analiza calitativă a cercetării utilizatorilor

Odată ce cercetarea a fost finalizată, este timpul să analizăm rezultatele și să stabilim principalele probleme pe care le-au întâlnit utilizatorii pe site-ul Yelp. Și iată ce am aflat:

1. Funcția de căutare a fost principalul punct de plecare pentru orice sarcină.

Toți cei cinci participanți au folosit bara de căutare, chiar și în sarcini în care s-ar fi putut descurca cu ușurință fără ea.

4 din 5 participanți au apelat imediat la funcția de căutare pentru a găsi un restaurant. Un singur utilizator a început să răsfoiască categoriile pe care le-a găsit imediat prea incomod și a ajuns să apeleze și la bara de căutare.

2. Fila Evenimente nu era suficient de vizibilă.

Într-o sarcină, participanții fără conturi Yelp au fost rugați să găsească un eveniment interesant în orașul lor în weekendul viitor. Experții au vrut să știe dacă vor folosi fila Evenimente din partea de sus a paginii:

În mod ciudat, nimeni nu a folosit fila Evenimente. Un candidat a mers la bara de căutare, în timp ce altul a mers la categoria Artă și divertisment.

3. Funcția de marcaj s-a dovedit a fi neclară și nimeni nu a folosit liste.

Dezvoltatorii au vrut să afle ce metodă ar alege utilizatorii pentru a economisi spațiu pentru referințe ulterioare. Există două moduri de a face acest lucru pe Yelp: marcați locul sau creați o listă.

Dintre cei trei participanți:

  • Unul a folosit marcaje pentru a salva companiile, dar s-a plâns că procesul a durat mult.
  • Unul a început să salveze companii folosind marcaje, dar sa oprit din același motiv ca utilizatorul de mai sus.
  • Un utilizator nu a înțeles deloc cum să salveze companiile pe site și a abandonat sarcina.

Doi participanți care au folosit marcaje au spus că ar fi bine să poată face acest lucru și din pagina cu rezultatele căutării în loc de
pentru a merge la pagina fiecărei companii în acest scop.

4. Găsirea unei anumite locații s-a dovedit a fi o sarcină foarte rapidă și ușoară.

Toți cei cinci utilizatori care au avut sarcina de a găsi o anumită locație și de a afla dacă este deschisă în prezent, au finalizat-o cu succes și au evaluat-o ca fiind foarte ușoară.

5. Utilizatorii au folosit fotografii pentru a determina atmosfera restaurantului.

Când i s-a cerut să găsească un restaurant cu o anumită atmosferă, niciunul dintre cei cinci participanți nu a încercat să folosească bara de căutare. În schimb, trei s-au uitat la fotografiile restaurantului pe Yelp, unul a vizitat site-ul web al restaurantului, iar ultimul a considerat că simbolurile costurilor ($,$$,$$$,$$$$) erau un indicator suficient pentru a stabili dacă restaurantul avea ambianța potrivită.

6. Filtrele au fost folosite de participanți, dar ar putea fi îmbunătățite.

Într-o sarcină de a găsi un restaurant pentru un grup de 15 persoane, trei dintre cei cinci participanți au folosit filtrul „Potrivit pentru grup mare”, un altul a folosit funcția „Rezervați” și apoi a derulat în jos pagina de rezultate până când au găsit un restaurant care se potrivește. cerinta.

Ultimul utilizator a încercat să selecteze două categorii pentru a filtra rezultatele, dar când a dat clic pe una dintre opțiuni, cea de-a doua a dispărut în acel moment.

Când participanții au căutat un restaurant utilizând anumiți parametri, una dintre cerințe a fost să găsească un restaurant în limita a 20 USD/persoană. Doi din cinci utilizatori au fost confuzi dacă un restaurant cu acest buget ar trebui clasificat în categoria $, $$ sau $$$. Unul dintre ei a spus că nu știe ce înseamnă simbolurile, iar celălalt a ales categoria greșită. Ceilalți trei utilizatori au ales corect categoria $$.

Semnificațiile simbolurilor nu sunt afișate în timpul selectării filtrului, ci numai atunci când o persoană merge la pagina unui anumit restaurant. Deoarece așteptările privind prețurile sunt foarte subiective, participanților nu le-a fost clar ce categorie ar trebui să aleagă.

Colectarea datelor cantitative despre comportamentul utilizatorului

Următorul obiectiv a fost mai mult analiză detaliată. Pentru a face acest lucru, experții au efectuat testarea la primul clic și testarea cu carduri închise.

1. Sortare cu carduri cu găuri folosind instrumentul OptimalSort.

Sortarea cu carduri închise implică acordarea participanților de carduri care conțin nume, pe care participanții trebuie apoi să le potrivească cu categoriile existente (spre deosebire de sortarea cu carduri deschise, în care utilizatorii trebuie să creeze singuri categoriile). Când numiți carduri, ar trebui să respectați principiul „cu cât este mai simplu, cu atât mai bine”. Câteva reguli care se aplică atât sortării cu fața în sus, cât și cu fața în sus:

  • Nu trebuie să amestecați categoriile de părinți și copii. Cu alte cuvinte, folosește categorii de același nivel, altfel vei deruta participanții.
  • Furnizați formulare deschise pentru feedback suplimentar după testare.
  • Rețineți că uneori utilizatorii nu grupează date. Absența unei grupări poate fi la fel de informativă ca și prezența acesteia. În acest caz, asigurați-vă că îl întrebați pe participant de ce.

Sortarea cardurilor utilizată în testul descris a avut trei obiective simple:

  • Determinați cât de des folosesc oamenii filtrele de căutare pe Yelp
  • Stabiliți care filtre sunt cele mai importante
  • Stabiliți care filtre sunt mai puțin importante

În total, dezvoltatorii au avut 47 de hărți care arată toate cele 47 de filtre de căutare Yelp (preț, distanță etc.). Participanții au fost apoi rugați să le trimită pe categorii de importanță: „foarte important”, „oarecum important”, „nu este important” și „Nu știu pentru ce este acest filtru”:

2. Testarea primului clic folosind instrumentul Chalkmark

Această testare surprinde zona site-ului pe care utilizatorul face clic pentru a finaliza sarcina specifica. Iată câteva sfaturi pentru a o face:

  1. Scrieți clar sarcinile. Asigurați-vă că participantul se gândește la cum să rezolve problema, nu doar unde să facă clic.
  2. Defini moduri mai bune pentru a finaliza sarcina. Incepand cu pagina principala, construiește totul moduri posibile pentru a atinge fiecare scop.
  3. Alocați o anumită perioadă de timp pentru a finaliza sarcinile.

Această testare ar trebui să aibă:

  • Stabiliți dacă arhitectura informațională vă permite să finalizați rapid o sarcină
  • Stabiliți dacă comenzile rapide de navigare sunt clare

Cercetătorii au cerut utilizatorilor să finalizeze anumite sarcini, oferindu-le capturi de ecran ale paginilor Yelp. Apoi au analizat rezultatele (heatmap) și cât de repede participanții au finalizat aceste sarcini.

Analiza cantitativă a cercetării utilizatorilor

În urma analizei calitative, datele din două anchete de teledetecție au fost analizate cu ajutorul instrumentului Optimal Workshop.

1. Rezultatele testării filtrelor de căutare pe Yelp folosind sortarea închisă a cardurilor

92,5% dintre participanți au spus că folosesc în mod regulat filtrele de căutare ale site-ului.

Cele mai importante filtre pentru utilizatori au fost „Deschide acum”, „Acceptare Carduri de credit" și "Oferte speciale".

Peste 88% dintre participanți au decis că cele 7 filtre nu sunt deloc importante.

Ca rezultat al acestei cercetări, au fost identificate trei obiective cheie pentru reproiectarea paginii de pornire Yelp:

  • Faceți mai vizibile cele mai populare filtre de căutare.
  • Eliminați filtrele de căutare neutilizate sau reproiectați-le astfel încât filtrele mai comune să aibă prioritate și filtrele mai puțin obișnuite să fie ușor accesibile.
  • Sortați cardurile închise în categorii existente pentru a determina ce filtre ar trebui să intre în fiecare categorie în funcție de utilizatori. Dacă se descoperă dezacorduri mari între participanți, arhitectura informațională va trebui reconstruită.

Pagina de pornire Yelp Primul clic pe Rezultatele testului

2. 30% dintre participanți au considerat site-ul „aglomerat” sau „confuz”.

Harta termică a arătat diferențe semnificative în ceea ce privește locul în care utilizatorii au făcut clic. Participanții au fost rugați să găsească un restaurant la preț rezonabil, care ar putea găzdui până la 20 de persoane. Finalizarea sarcinii a durat în medie 15 secunde - ceea ce este mult în condiții de internet. În imaginea de mai jos, puteți vedea că 55% au dat clic pe elementul de meniu Restaurante din colțul din dreapta sus. Restul de 45% au făcut clic în locuri complet diferite. Având răspunsuri potențiale în mai multe locuri pe o pagină, crește sarcina cognitivă a utilizatorilor și probabilitatea unui prim clic incorect:

24% dintre participanți au folosit bara de căutare când au căutat un mecanic în orașul lor (una dintre sarcini). Majoritatea participanților au navigat la categoriile de servicii situate în partea stângă a site-ului. Dar a doua cea mai populară acțiune a fost încă folosirea barei de căutare.

Fila Evenimente a indus în eroare utilizatorii când li s-a cerut să afle mai multe despre un festival viitor în orașul lor. fila Evenimente în panoul de sus navigarea duce oamenii la o pagină cu evenimentele principale (nu pe cele pe care le-au selectat). Pentru a vedea evenimentele la care intenționează să participe, ar trebui să facă clic pe fila de jos „Evenimente”.

Drept urmare, 37% dintre oameni au ignorat ambele file și au mers direct la bara de căutare. 37% dintre oameni au dat clic pe fila Evenimente dorită. 18% au dat clic pe o filă situată în bara de navigare principală.

Pe baza datelor cantitative obținute, au fost identificate următoarele sarcini pentru reproiectare:

  • Reduceți aglomerația de pe pagini pentru a facilita utilizatorilor să perceapă informațiile și să acționeze.
  • Creați nume de file clare și fără ambiguitate și eliminați-le pe cele ambigue care conduc utilizatorii pe căi greșite.
  • Efectuați o hartă deschisă a conținutului principal pentru a determina cum cred utilizatorii că informațiile ar trebui organizate și cum ar denumi categoriile.
  • Faceți fila Evenimente mai vizibilă.
  • Reproiectați vizualizarea „Cont”, astfel încât să nu existe confuzii între meniul principal al site-ului și meniul contului.

Proiectare și iterație centrate pe utilizator

Odată ce analiza datelor utilizatorului este completă, puteți începe să creați și să reluați designul.

Jakob Nielsen, co-fondator al Nielsen Norman Group, clasifică majoritatea proceselor de proiectare care implică testarea utilizabilității în două categorii: design iterativ și design paralel.

Într-un proces iterativ, trecem pur și simplu de la o versiune a designului la următoarea pe baza a ceea ce descoperim din testarea de utilizare. Fiecare săgeată din graficul de mai jos reprezintă o rundă de testare și analiză:

1 wireframe, mai multe iterații → hârtie/wireframe interactiv, mai multe iterații → modele vizuale, mai multe iterații

Cu acest proces, se recomandă cel puțin două iterații pentru fiecare schiță, cadru și aspect. Desigur, acest proces poate fi extins în funcție de dimensiune și complexitate și puteți crea cu ușurință 5-10 iterații pentru fiecare etapă.

Acest proces de proiectare pune accent de la început pe gândirea creativă. Mai multe versiuni ale unui design care sunt ușor diferite unele de altele în ceea ce privește aspectul sunt de preferat iterațiilor.

3 modele diferite realizate în același timp → Testare utilizator (conectat cele mai bune idei design) → 1 design → Proces de proiectare iterativ

O rundă mare de testare a utilizatorilor are ca rezultat un design unificat. Pentru a-l îmbunătăți în continuare, cel mai bine este să folosiți un proces iterativ, în care micile modificări sunt testate în grupuri mici de 5-10 utilizatori până când designul este final.

Procesul de reproiectare Yelp descris a fost în esență un proces paralel, împreună cu testarea UX efectuată la început. Deoarece aceasta a fost doar o reproiectare ipotetică, dezvoltatorii s-au oprit după proiectarea pasului 1. Dacă aceasta a fost o reproiectare reală, urmatorul pas ar fi să efectuăm teste suplimentare pentru a îmbunătăți prototipul.

Schițarea

Pentru reproiectarea lui Yelp, schița a fost primul pas în reproiectarea paginii de start și a paginii cu rezultatele căutării Yelp.

Designul paginii de pornire Yelp a durat două iterații, echipa concentrându-se doar pe structură.

Schița a fost realizată ținând cont de unele dintre principalele probleme de utilizare identificate în timpul testării paginii de pornire:

  • Creșteți vizibilitatea barei de căutare
  • Faceți fila Evenimente mai vizibilă
  • Optimizați categoriile

În plus, a fost adăugat un subsol și „Recenzia zilei” a fost mutată din partea dreaptă a paginii în partea de jos.

2. Pagina cu rezultatele căutării Yelp

Deoarece pagina de rezultate conține mai puțină varietate de informații în comparație cu pagina de pornire, a fost nevoie de o singură iterație pentru a schița noul design.

Următoarele puncte au fost luate în considerare în această schiță:

  • Fotografiile ar trebui să fie mai vizibile
  • Desemnați categorii de preț

Crearea unui wireframe

Există destul de multă dezbatere cu privire la wireframes de joasă și înaltă fidelitate. Dezvoltatorii l-au ales pe primul pentru că au vrut să se concentreze numai pe structură în această etapă.

Având în vedere complexitatea paginii de pornire actuale a lui Yelp, a fost nevoie de 4 iterații. Pe lângă remedierea problemelor de utilizare, au vrut să păstreze
Aspecte SEO (de exemplu, o listă cu alte orașe). Mai jos ne vom concentra pe cea mai recentă iterație.

  • Îmbunătățiri în bara de căutare

Design actual:

Bara de căutare se află în partea de sus a paginii.

Cadru modificat:

Dezvoltatorii au adăugat mai multă precizie și au oferit, de asemenea, spațiu liber în jurul panoului pentru a-l scoate mai mult în evidență. Deoarece scrierea recenziilor este o interacțiune cheie pentru Yelp, au adăugat și un buton „Scrieți o recenzie” în colțul din stânga sus.

  • Optimizați lista de categorii

Design actual:

Cadru modificat:

Noul design este mai vizual și prezintă doar 8 categorii la un moment dat. Pentru a vedea mai multe, utilizatorii pur și simplu dați clic pe butonul „Mai multe companii”, care a fost mutat mai aproape de ⅓ de sus a paginii pentru un accent vizual mai puternic.

  • Faceți mai ușor să găsiți fila Evenimente

Design actual:

„Evenimentele” sunt fie ascunse în colțul din dreapta în bara de navigare de sus (nu este afișată aici), fie sunt împinse într-o bară laterală din mijlocul derulării.

Cadru modificat:

Aspectul modificat plasează „Evenimente” în centrul derulării. Puteți fie să inserați o funcție Fotografie în stânga textului, fie să adăugați un videoclip care se redă în fundal.

  • Reducerea haosului general

Design actual:

Cadru modificat:

Orice elemente secundare, cum ar fi „Evenimente populare” sau „Liste” (care nu au fost nici măcar folosite în testele de utilizare) au fost mutate în subsol.

2. Pagini cu rezultate ale căutării Yelp

Deoarece paginile cu rezultatele căutării erau mai puțin complexe, reproiectarea a necesitat doar două iterații. Mai jos ne vom concentra pe cea mai recentă iterație.

Design actual:

Filtrele și sortarea lui Yelp sunt lipsite de ierarhie.

Cadru modificat:

Noul cadru evidențiază cele mai importante filtre și rearanjează întreaga zonă în pătrate. Fiecare categorie de filtru include doar patru opțiuni, ceea ce oferă ordine vizuală Deoarece 90% dintre utilizatori consideră că filtrul „Deschide acum” este important, dezvoltatorii l-au evidențiat element separat. Prețurile sunt clarificate în funcție de intervalele de dolari și sunt ascunse 7 filtre neimportante.

  • Aspect îmbunătățit al rezultatelor căutării

Design actual:

Majoritatea utilizatorilor s-au bazat pe fotografii pentru a determina atmosfera unui loc, dar pictogramele de imagine din listări erau prea mici. De asemenea, nu există nicio modalitate de a salva o companie ca marcaj..

Cadru modificat:

Am mărit miniaturile și am mutat butonul „Salvare pentru mai târziu” în partea de sus pentru marcare ușoară. A fost schimbată și aspectul și adresa și numărul de telefon au fost separate.

Prototipare: precizie scăzută și mare

În timp ce wireframing se referă la structură, prototipul înseamnă experiență. Prototiparea poate avea, de asemenea, fidelitate scăzută sau înaltă.

1. Prototipări de joasă fidelitate

Deoarece aceste prototipuri sunt în mod inerent neterminate, oamenii oferă un feedback mai obiectiv asupra caracteristicilor de bază și a designului general.

Dezvoltatorii de la UXPin, UserTesting și Optimal Workshop au dorit să poată răsfoi categorii, selecta filtre și comuta între pagina principala iar pagina cu rezultatele căutării a fost o experiență perfectă pentru participanți. Dacă aceasta ar fi o reproiectare adevărată, următorul lor pas ar fi să testeze utilizatorul acest prototip și apoi să repete din nou.

2. Prototipări de înaltă precizie

Prototiparea de înaltă fidelitate este ideală pentru etapele ulterioare de proiectare, iar iterația acoperă aspecte precum aspectul, brandingul și alte detalii.

Experții au adăugat precizie folosind biblioteca lor de elemente de interfață cu utilizatorul. Ceea ce nu a putut fi făcut în browser a fost creat în Photoshop sau Sketch și apoi importat direct în UXPin folosind drag & drop. Straturile au fost păstrate, așa că a fost doar o chestiune de a face clic pe elemente și de a adăuga interacțiuni.

Din nou, dacă aceasta ar fi o reproiectare adevărată, echipa ar testa noul prototip pe aceleași sarcini și ar repeta după caz.

Concluzie

Cea mai mare provocare cu care se confruntă designerii și managerii de produs nu este modul în care funcționează piața sau diferitele tehnologii, ci modul în care se comportă oamenii. Ceea ce spun utilizatorii și ceea ce fac ei sunt două lucruri complet diferite, iar singura modalitate de a verifica acest lucru este testarea.

Testarea de utilizare este mai mult decât o bifare pe o listă de cerințe. Acesta este motivul cel mai convingător pentru dvs solutii de proiectare. La urma urmei, dacă nu proiectați pentru utilizatori, atunci proiectați numai pentru dvs.

Apropo, designul site-ului web Yelp descris în acest articol a suferit câteva modificări și acum arată astfel:

Este posibil ca dezvoltatorii săi să fi folosit principiile enumerate mai sus pentru a obține un rezultat care amintește oarecum de cel la care au ajuns specialiștii de la UXPin, UserTesting și Optimal Workshop

Testarea de utilizare va arăta cât de convenabil este pentru utilizator să găsească informații și să efectueze acțiuni pe site. Acest lucru vă permite să înțelegeți la jumătate ce trebuie să faceți în continuare - lăsați designul același sau modificați-l.

Cea mai mică greșeală poate eșua testul. În acest articol, veți afla ce să luați în considerare în fiecare etapă a testării.

Ce este important

Orice test este unic ca scop și obiective. Cu toate acestea, există puncte generale care ar trebui clarificate chiar de la început:

  • Unde să încep?
  • Prin ce etape trebuie să treci?
  • Cum să nu ratezi detalii importante?
  • Ce capcane va trebui să depășești?
  • Cum să obțineți date valide și semnificative?

Următorul algoritm va ajuta la planificare.

Pasul 1: Definiți-vă obiectivul

Formulați un rezultat clar al studiului și decideți ce date sunt cel mai bine colectate pentru aceasta.

Testul poate include întrebări generale:

  • Ce navigare îmbunătățește experiența utilizatorului?
  • Cum interacționează vizitatorii cu aplicația/site-ul?

Sau specifice:

  • Ce îi împiedică pe utilizatori să efectueze acțiunea țintă pe site?
  • Ce vă atrage atenția când plasați o comandă?

Cu toate acestea, cu cât sunt mai multe întrebări în programul de cercetare, cu atât domeniul erorilor de interpretare este mai larg. Întrebați doar ce vă ajută să vă atingeți obiectivul.

Pasul 2: Atrageți participanții potriviți

Aceștia sunt vizitatorii site-ului și utilizatorii țintă.

Aflați cine folosește sistemul actual și decideți ce clienți potențiali îi vizați.

Stabiliți numărul de participanți. De obicei, de la 3 la 8. Cu cât sunt mai multe, cu atât mai multe erori de utilizare pot fi identificate. Iată cum arată dependența:

Pasul 3: Alegeți un format

Testare personală de utilizare

Este bun pentru că vă permite să citiți limbajul corpului și să evaluați comportamentul oamenilor în viața reală.

  • Silent Observer: Stai lângă utilizatori, nu interacționezi cu ei, ci le analizezi comportamentul și modul în care fac față sarcinilor.
  • Metoda gândirii cu voce tare: participanții descriu tot ceea ce fac și gândesc pe măsură ce merg. Acest lucru oferă o viziune clară a ceea ce se întâmplă aproximativ în mintea vizitatorilor.
  • Metodă de interacțiune sinergică: doi utilizatori îndeplinesc sarcini împreună și se ajută reciproc. Nu le dați indicii și nu evaluați cum depășesc dificultățile atunci când lucrează cu site-ul.

Testare de utilizare de la distanță

Aceasta este o alternativă la testarea în persoană, care vă economisește timp și bani. Utilizatorii realizează sarcini unde și cum le este convenabil.

  • Moderat: interacționați cu un participant online.
  • Nemoderat: nu poți să-i pui întrebări sau să interferezi în niciun fel.

Pasul 4: Formulați obiective/scenarii

Iată două tipuri de sarcini:

  • Deschis/Explorator: de obicei, mai explorator și explorator. Acest tip necesită mai mult de un răspuns, iar răspunsurile variază de la utilizator la utilizator. Le oferiți participanților un minim de informații despre execuție.
  • Închis/Specific: mai restrâns și orientat spre obiective. Ele limitează sfera studiului și produc rezultate mai precise.

Este important să găsiți o cale de mijloc. Cum să o facă?

Cerințe de sarcină

  • Sarcină ≠ întrebare

De ce? Nu există niciun beneficiu din a pune întrebări cu răspunsuri previzibile sau nebunești.

  • Formulare specifică

Nu lăsați utilizatorii să se întrebe ce să facă sau care este următorul pas.

În același timp, nu vă concentrați asupra celor mai mici și nesemnificative detalii, acoperiți doar acele aspecte ale sistemului care sunt importante pentru dvs.

  • Evitați instrucțiunile

De asemenea, nu este nevoie să treci la cealaltă extremă și să dai instrucțiuni despre cum să treci corect testul. În loc de rezultate fiabile, veți obține ceea ce vă așteptați și atunci ce rost are testarea?

  • Creați condiții apropiate de cele reale

În acest fel, veți obține o părere sinceră de la utilizatori despre sistem: ce cred ei, cum depășesc dificultățile și ce iese în cele din urmă din el.

Pasul 5: Creați chestionare

Există două tipuri principale de chestionare pentru testele de utilizare.

Pre-chestionare

Cât de des cumperi online?

  • Nu;
  • Achizitionat de 1-2 ori anul trecut;
  • De aproximativ 3-7 ori pe an;
  • În mod regulat (specificați cât de des).

Evaluați cum să implicați mai eficient publicul țintă și de ce depinde acest lucru.

Chestionare post-test

Aceste întrebări ajută la înțelegerea impresiilor participantului la test. Rugați-l să vă spună dacă i-a fost ușor sau dificil să folosească sistemul, dacă această experiență l-a inspirat sau l-a dezamăgit.

Cum vă place aplicația?

  • Ușor de folosit;
  • Greu de folosit.

Te rog explica de ce crezi asta? (intrebare deschisa).

Pasul 6: Efectuați un test de rulare

Repetiția de studiu ajută la evaluarea gradului de pregătire și la identificarea și rezolvarea problemelor din timp.

Un test pilot vă va arăta cât timp trebuie să aloce fiecărei sarcini. Dacă sunt multe, sortați-le după importanță și relevanță pentru obiectivul principal.

Încercați singur sau cereți colegilor să susțină mai întâi testul. Unul sau doi participanți la încercare sunt mai mult decât suficiente pentru a prinde gafe și a se pregăti pentru experimentul adevărat.

Dacă un pilot are succes, produce și descoperiri utile și uneori neașteptate.

Important! Atrageți utilizatori care nu sunt familiarizați cu toate nuanțele sistemului pe care îl testați.

Pasul 7: Înregistrați rezultatele

Nu există o metodă universală de analiză a datelor. Alege ce funcționează pentru tine.

Rezumați ce dificultăți au întâmpinat utilizatorii și trageți concluzii. Puteți clasifica problemele și le puteți clasifica în funcție de gravitate sau importanță. Stabiliți pe care merită să lucrați mai întâi și pe care să le tăiați de pe listă.

Caz: testul de utilizare în acțiune

Scop: răspunde la întrebări și schimbă secțiunile necesare site:

  • Este ușor să găsești un anumit produs pe o pagină?
  • Cât de ușor este să-l creezi în funcție de dorințele tale și să-l adaugi în coș?

Cele mai bune articole pe această temă