) ekziston një fazë e vlerësimit të projektimit, është në këtë fazë që mund të kryhet testimi i përdorshmërisë me cilësi të lartë.

U detyrova ta shkruaj këtë artikull nga problemet që u shfaqën kur po kryeja testimin e përdorshmërisë. Shpresoj se mund të ndihmoj dikë që të përcaktojë më saktë se kur duhet përdorur testimi i përdorshmërisë dhe si të shmangen disa nga problemet gjatë kryerjes së tij.

Ridizajnimi i faqes në internet

Kur ia vlen të kryhet testimi i përdorshmërisë dhe çfarë i paraprin?

Në rastin e një faqe interneti të zhvilluar tashmë, çështja e kryerjes së testimit të përdorshmërisë lind kur ndjeni ose zbuloni se diçka nuk është në rregull me sitin. Në çdo rast, ju duhet të instaloni Google analitikë(libër: Google Analytics. Analiza profesionale e trafikut të faqes në internet) ose shërbim tjetër për analitikën e vizitave në faqe. Unë nuk do të flas pse duhet të instaloni një shërbim të tillë, pasi tema është shteruar prej kohësh dhe nuk rekomandon instalimin shërbime të ngjashme thjesht dembel. Pas instalimit të Google Analytics, ju tashmë keni të dhëna specifike për statistikat e vizitave, pikat e hyrjes dhe daljes së vizitorëve të faqes dhe informacione të tjera.

Hapi tjetër duhet të jetë përcaktimi i KPI-ve (Wikipedia: Treguesit kryesorë të performancës - treguesit kryesorë të performancës). Është e nevojshme të analizohet ajo që është e rëndësishme për biznesin dhe të përcaktohen qëllimet që duhet të arrijnë faqet.

Shembull: për disa mund të jenë porosi mallrash, për të tjerë mund të jenë kërkesa nëpërmjet formularit të reagimit me ndonjë pyetje, etj.

Nëse deri në këtë pikë rekomandimet ishin të detyrueshme, domethënë, në çdo rast, këto hapa do të ndihmojnë në zhvillimin dhe promovimin e faqes, atëherë rekomandime të mëtejshme vijnë nëse e kuptoni vërtet që faqja nuk është efektive.

Hapi i tretë është të identifikoni drejtpërdrejt faqet dhe funksionet e problemit. Thjesht kryerja e testimit të përdorshmërisë është joefektive; ju duhet të kuptoni se ku lindin problemet, në cilën faqe, me cilin funksion dhe më pas të kryeni testimin për të përcaktuar se çfarë saktësisht është e gabuar në faqe dhe si ta zgjidhni atë. Google Analytics do të ndihmojë përsëri, këtu mund të përcaktoni se cilat faqe largohen nga përdoruesit, cilat faqe injorohen dhe cilat funksione nuk përdoren.

Përgatitja për testimin e përdorshmërisë

Pra, në këtë pikë tashmë është përcaktuar që faqja kërkon ridizajnim; ne kemi gjetur faqe dhe funksione me të cilat përdoruesit kanë probleme. Mbetet vetëm për të kuptuar pse përdoruesit kanë probleme dhe si t'i rregullojnë ato.

Hapi i katërt duhet të jetë formimi i hipotezave se çfarë nuk shkon me faqen, dhe në bazë të kësaj, është e nevojshme të përcaktohen metrikat (Wikipedia: ISO 9126 - Vlerësimi i produktit softuer) me anë të të cilave do të testohen funksionet (ka një ekspert metodë vlerësimi në të cilën eksperti parashtron hipoteza për të përmirësuar ndërfaqen e faqes dhe, bazuar në to, faqja ridizajnohet, megjithatë, është e mundur të kontrollohet nëse kjo hipotezë është vërtet e vërtetë vetëm pas zbatimit të ndryshimeve, gjë që sjell një kosto të lartë të gabim).

Shembull: me duke përdorur Google analytics, ne kemi përcaktuar që përdoruesit po hyjnë në faqen e regjistrimit, por nuk po e plotësojnë atë. Përdoruesit mund të mos jenë në gjendje të kuptojnë se çfarë informacioni duhet të futin në fusha ose mund të mos dinë se çfarë të bëjnë më pas pasi të plotësojnë fushat. Kjo do të thotë që ne duhet ta testojmë këtë faqe bazuar në metrikat e kuptueshmërisë. mesazhet e sistemit dhe sekuencën operative.

Pas përcaktimit të matjeve me të cilat do të testojmë zonat problematike në faqe, është e nevojshme të përcaktohet karakteri dhe skenari i punës (libri: Alan Cooper në ndërfaqen. Bazat e dizajnit të ndërveprimit) sipas të cilit do të kryhet testimi i përdorshmërisë. Ky hap të nevojshme për të tërhequr të anketuarit e duhur dhe për të zgjedhur një detyrë për testimin e përdorshmërisë. Nëse kjo pikë humbet, atëherë një i anketuar që nuk është përdoruesi i synuar mund të kalojë me sukses në zonën e problemit dhe përdoruesi që përdor në të vërtetë këtë faqe do të ketë probleme reale. probleme të mëdha. Rezultati do të jetë një ridizajnim i ndërfaqes pa marrë parasysh të dhënat, por problemi do të mbetet. Përcaktimi i saktë i skenarit do të ndihmojë që të anketuarit t'i jepet detyra e duhur. Kjo do të thotë, nëse detyra është të blini një telefon celular, dhe i padituri nuk regjistrohet fare (dhe ne po testojmë regjistrimin në mënyrë specifike), atëherë testimi i përdorshmërisë është i padobishëm.

Shënim: zgjidhni skenarin në mënyrë që të testohen sa më shumë zona problematike.

Më pas vjen përzgjedhja e të anketuarve në bazë të karakterit të përzgjedhur. Sa më shumë që i anketuari të përputhet me portretin e personazhit, aq më mirë. Një numër i mjaftueshëm i të anketuarve është 5-8 persona. Në zgjedhjen e sasisë e bazoj në rekomandimin e Jakob Nielsen dhe përvojën time.

Menjëherë përpara vetë testimit të përdorshmërisë, kërkojini të anketuarit të plotësojë një pyetësor për të kontrolluar nëse karakteri i zgjedhur dhe i anketuari përputhen me karakteristikat e kërkuara. Kryeni një konferencë hyrëse, gjatë së cilës përshkruani kontekstin e përdorimit të faqes dhe detyrën (libra: Dizajni i uebit: libri i Steve Krug, ose "Mos më bëj të mendoj!").

Shembull i detyrës: duke kërkuar diçka të re celular Ju keni ardhur në këtë faqe përmes një motori kërkimi. Gjeni telefonin që ju nevojitet (gjithashtu kërkojini të anketuarit të përshkruajë telefonin që do të kërkonte).

Kryerja e vetë testimit të përdorshmërisë (programi: Usability Studio) nuk është ashtu siç duket detyrë e vështirë. Ju duhet një laptop me një aparat fotografik dhe disa programe për të kapur lëvizjet e përdoruesve dhe për të regjistruar aktivitetin e ekranit. Kërkojini të anketuarit të komentojë për të gjitha veprimet dhe emocionet e tij. Siç tregon praktika, ai do ta bëjë këtë gjithsesi (dhe kjo nuk është për t'u habitur, sepse edhe në shtëpi, përdoruesve shpesh u pëlqen të qortojnë ose, përkundrazi, të kujdesen për forma të ndryshme dhe elementë të tjerë në faqe).

Pas përfundimit të testit, intervistoni të anketuarin për përshtypjet e tij, çfarë vështirësish hasi dhe çfarë i dukej e papërshtatshme. Unë nuk rekomandoj përdorimin e të dhënave të sondazhit si ligj për të ndryshuar çdo gjë që nuk i pëlqen. Ju duhet të dëgjoni përdoruesit, por të jeni shumë mosbesues ndaj tyre. opinion subjektiv. Është më mirë nëse, bazuar në rezultatet e sondazhit, shfaqet një hipotezë për nevojën për të ndryshuar ndërfaqet, për të shtuar një artikull tjetër në listën e zonave problematike dhe për ta testuar atë në përsëritjen tjetër.

Përpunimi i të dhënave të testimit të përdorshmërisë

Më pas, duhet të shikoni materialet e mbledhura video, të analizoni rezultatet e testimit të përdorshmërisë dhe të përcaktoni kërkesat për ndërfaqen për ridizajnim (libër: Dizajni i uebit. Lehtësia e përdorimit të faqeve të internetit). Ndryshimet që do të bëhen në bazë të kërkesave të caktuara duhet të kontrollohen gjatë testimit të ardhshëm të përdorshmërisë. Numri i përsëritjeve të tilla duhet të varet kryesisht nga qëllimet dhe buxheti i caktuar për ridizajnimin e sitit.

Shembuj: shtoni këshilla në formularin e regjistrimit, nënvizoni butonin e blerjes, shtoni fushën "platformë" në formularin për zgjedhjen e një telefoni sipas parametrave, etj.

Dizajn i faqes në internet

Nëse dizajni është kryer sipas standardit ISO 9241-210, atëherë kryerja e testimit të përdorshmërisë nuk duhet të jetë një proces i kushtueshëm dhe kërkon kohë për shkak të bazës së përgatitur analitike. Fazat kryesore të testimit të përdorshmërisë kur hartoni një faqe interneti nga e para mbeten të njëjtat siç përshkruhen më lart, me përjashtim të disa aspekteve:

1. Formimi i hipotezave
2. Përcaktimi i metrikës për testim
3. Përcaktimi i personazheve dhe skenarëve
4. Përzgjedhja e të anketuarve
5. Plotësimi i formularit
6. Trajnimi induksion
7. Kryerja e testimit të përdorshmërisë
8. Anketa e të anketuarve
9. Analiza e rezultateve
10. Përcaktimi i kërkesave për projektimin e faqes

Problemi kryesor që hasa me testimin e përdorshmërisë në këtë rast ishte testimi i një dizajni statik, në vend të një faqe interneti të plotë. Në realitet, është më mirë të testoni një faqe interneti të dizajnuar dhe madje të programuar, por kostoja e përsëritjes së dizajnit do të jetë e lartë. Sa më herët të gjendet një problem në ndërfaqe, aq më i ulët është kostoja e rregullimit të tij. Si të kryhet testimi i plotë i përdorshmërisë së një imazhi statik? Zgjidhja e këtij problemi ishte programi Axure. Mënyra më e lirë dhe më e suksesshme ishte vendosja artificiale e lidhjeve në një imazh statik të dizajnit të faqes dhe gjenerimi i tij në faqen HTML. Kjo metodë bën të mundur testimin e faqes pa shpenzuar burime edhe për paraqitjen. Natyrisht, faqet e krijuara nuk kanë pothuajse asnjë funksionalitet, ato shfaqen vetëm në një formë të caktuar, por kjo mjafton për të identifikuar një numër më të madh problemesh.

Unë nuk e konsideroj opsionin e testimit sasior të përdorshmërisë, pasi na lejon të përcaktojmë ergonominë e përgjithshme të ndërfaqes, por nuk na lejon të përcaktojmë se cilat probleme lindin, pse dhe si t'i rregullojmë ato.

P.S. Pres me padurim kritika konstruktive në lidhje me zgjidhjen e propozuar për testimin e përdorshmërisë me cilësi të lartë të dizajnit, pasi nuk kam parë askund një zgjidhje të tillë. Nëse keni ndonjë sugjerim se si të kryeni testimin e plotë të përdorshmërisë me cilësi të lartë me çmim të lirë dhe me gëzim, do të jem i lumtur ta lexoj.

Përgatitja, intervistat dhe mbledhja e të dhënave

Tek faqeshënuesit

Natalia Sprogis, kreu i kërkimit UX në Mail.Ru Group, foli në blogun e kompanisë në Habrahabr për përgatitjen dhe kryerjen e testimit të përdorshmërisë: çfarë të përfshihet në skriptin e testit, si të zgjidhni një metodë të mbledhjes së të dhënave, të krijoni detyra dhe të mblidhni përshtypjet e të anketuarve .

Një plan testimi është, nga njëra anë, një grup detyrash, pyetjesh dhe pyetësorësh që i jepni secilit të anketuar dhe nga ana tjetër, është baza metodologjike e studimit: metrikat dhe hipotezat që testoni dhe regjistroni, mjetet e zgjedhura.

A është vërtet i nevojshëm testimi?

Së pari, duhet të jeni të sigurt se në këtë fazë projekti ka nevojë për testim të përdorshmërisë. Prandaj, sqaroni se për çfarë qëllimi po ju kontakton ekipi i projektit. Testimi i përdorshmërisë nuk është i gjithëfuqishëm dhe tashmë në fillim duhet të kuptoni se çfarë mund t'i sjellë produktit. Përgatitni menjëherë ekipin tuaj të projektit për të ditur se cilat pyetje mund t'u përgjigjeni dhe cilat jo. Ka pasur raste kur ne ose u kemi ofruar klientëve një metodë tjetër (për shembull, intervistat e thelluara ose studimet e ditarit janë më të mira tani), ose rekomandojmë që ta braktisin studimin fare dhe të bëjnë një test të ndarë.

Për shembull, ne kurrë nuk testojmë "tërheqjen" e një opsioni tipar ose dizajni në kërkimin cilësor. Ne mund të mbledhim reagime nga përdoruesit, por ekziston një rrezik shumë i madh që përgjigjet e tyre të ndikohen nga dëshira sociale. Njerëzit janë gjithmonë të prirur të thonë se do të përdorin edhe atë që nuk do ta përdorin. Dhe madhësia e vogël e mostrës nuk na lejon t'u besojmë përgjigjeve të tilla. Për shembull, ne patëm një përvojë të pasuksesshme duke testuar faqet e uljes së lojërave: faqja e uljes që u zgjodh si më tërheqëse në test rezultoi shumë më keq gjatë testimit A/B.

Testimi i prototipave dhe koncepteve ka gjithashtu një sërë kufizimesh. Kur planifikoni, duhet të kuptoni se çfarë mund të përfitoni vërtet nga ky test. Është mirë kur një projekt ka mundësinë të testojë prototipe ose dizajne përpara zbatimit. Sidoqoftë, sa më pak i detajuar dhe funksional të jetë prototipi, aq më i lartë është niveli i abstraksionit për të anketuarin, aq më pak të dhëna mund të merren nga testi. Është mirë të testohen prototipet për të identifikuar problemet me emërtimin dhe metaforat e ikonave, domethënë të gjitha çështjet e kuptueshmërisë. Aftësia për të testuar çdo gjë përtej kësaj varet shumë nga natyra e projektit dhe detajet e prototipit.

Baza për të shkruar një skript testi të përdorshmërisë

Planifikimi i testit fillon jo me shkrimin e tekstit të detyrave, por me një përpunim të detajuar të qëllimeve dhe pyetjeve kërkimore së bashku me ekipin e projektit. Këtu është baza për të bërë një plan:

Skenarë të rëndësishëm. Këta janë ata skenarë përdoruesish (detyra ose raste përdorimi) që prekin biznesin ose kanë të bëjnë me qëllimin e testimit. Edhe nëse ekipi dyshon për probleme në fusha specifike, shpesh ia vlen të kontrollohen rastet themelore. Në këtë rast, skenarët e mëposhtëm mund të konsiderohen të rëndësishëm për testin:

• më e shpeshta (për shembull, dërgimi i një mesazhi në mesazher);
• ndikimi i qëllimeve të biznesit (për shembull, puna me një formular pagese);
• lidhur me përditësimin (ata që preken nga ridizajnimi ose futja e funksionalitetit të ri).

Çështje të njohura Shpesh, kërkimi duhet të japë përgjigje për shkaqet e problemeve të biznesit të një shërbimi. Për shembull, prodhuesi është i shqetësuar për daljen e madhe të lojtarëve pas orës së parë të lojës. Dhe ndonjëherë zonat problematike të ndërfaqes janë tashmë të njohura për ekipin, dhe ju duhet të grumbulloni detaje dhe specifika. Për shembull, shërbimi mbështetës shpesh kontaktohet me pyetje në lidhje me formën e pagesës.

Pyetje. Ekipi mund të ketë gjithashtu pyetje kërkimore, të tilla si nëse përdoruesit vërejnë një reklamë baneri Shërbime shtesë; A emërtohet qartë një seksion i caktuar?

Hipotezat. Kjo është ajo në të cilën përkthehen çështjet dhe pyetjet e njohura të ekipit. Është mirë nëse klienti vjen tek ju me hipoteza të gatshme - për shembull, "Klientët tanë paguajnë vetëm me telefon me një komision. Përdoruesit mund të mos e shohin më zgjedhjen mënyrë fitimprurëse pagesa." Nëse nuk ka hipoteza, por ekziston vetëm dëshira për të testuar projektin në mënyrë abstrakte "për përdorshmërinë", detyra juaj është të formuloni këto hipoteza.

Mendoni me ekipin e projektit për vendet ku përdoruesit nuk sillen siç pritej (nëse ka një informacion të tillë). Zbuloni nëse ka ndonjë element dizajni që është debatuar shumë dhe mund të jetë problematik. Bëni auditimin tuaj të produktit për të gjetur probleme të mundshme për përdoruesit që janë të rëndësishme për t'u testuar. E gjithë kjo do t'ju ndihmojë të bëni një listë të atyre elementeve (detyrave, pyetjeve, kontrolleve) që duhet të përfshihen në skenarin përfundimtar.

Metoda e mbledhjes së të dhënave

Është e rëndësishme të merret parasysh se si do të grumbulloni të dhëna për atë që ndodh gjatë testit për analiza të mëvonshme. Opsionet e mëposhtme përdoren tradicionalisht:

Vrojtim. Gjatë kryerjes së detyrave, i anketuari mbetet vetëm me produktin dhe sillet siç e sheh të arsyeshme. Komentet e të anketuarit mblidhen përmes pyetësorëve dhe komunikimit me moderatorin pas testit. Kjo është metoda "më e pastër"; ajo siguron sjellje më të natyrshme të të anketuarit dhe aftësinë për të matur saktë një numër metrikash (për shembull, koha për të përfunduar një detyrë).

Megjithatë, ka shumë të dhëna të dobishme cilësore prapa skenave. Duke parë këtë apo atë sjellje të një të anketuari, nuk mund ta kuptoni pse ai vepron në këtë mënyrë. Sigurisht, ju mund të pyesni për këtë në fund të testit, por ka shumë të ngjarë që i anketuari do ta mbajë mend mirë vetëm detyrën e fundit. Për më tepër, gjatë përfundimit të detyrave, mendimi i tij për sistemin mund të ndryshojë, dhe ju do të merrni vetëm pamjen përfundimtare, dhe jo përshtypjet e para.

Mendo me zë të lartë (mendon me zë të lartë). Për një kohë të gjatë, kjo metodë është përdorur më shpesh në testimin e përdorshmërisë. Jakob Nielsen dikur e quajti atë mjeti kryesor i vlerësimit të përdorshmërisë. Çështja është që ju i kërkoni të anketuarit të shprehë të gjitha mendimet që lindin gjatë punës me ndërfaqen dhe të komentojë të gjitha veprimet e tij. Duket diçka si kjo: "Tani do ta shtoj këtë artikull në karrocën time. Ku është butoni? Ah, këtu është ajo. Oh, harrova të shikoja se çfarë ngjyre ishte.”

Metoda ndihmon për të kuptuar pse përdoruesi sillet në një mënyrë ose në një tjetër dhe cilat emocione ngjall tek ai ndërveprimi aktual. Është e lirë dhe e thjeshtë, madje edhe një studiues i papërvojë mund ta trajtojë atë.

Megjithatë, ajo ka të metat e saj. Së pari, nuk është shumë e natyrshme që njerëzit të "mendojnë me zë të lartë" gjatë gjithë kohës. Ata shpesh do të heshtin dhe do t'ju duhet t'i kujtoni vazhdimisht që të vazhdojnë të flasin. Së dyti, detyrat me këtë metodë zgjasin pak më shumë për t'u përfunduar sesa brenda jeta reale. Për më tepër, disa të anketuar fillojnë ta përdorin produktin me më shumë mendim. Duke artikuluar arsyet e veprimeve të tyre, ata përpiqen të veprojnë më racionalisht, dhe thjesht nuk duan të duken si idiotë dhe mund të mos kapni disa momente intuitive të sjelljes së tyre.

Ndërhyrja aktive e moderatorit. Metoda është ideale për testimin e koncepteve dhe prototipeve. Gjatë përfundimit të detyrave, moderatori ndërvepron në mënyrë aktive me përdoruesin: në momentet e duhura ai zbulon arsyet e sjelljes së tij dhe bën pyetje sqaruese. Në disa raste, moderatori mund të lëshojë edhe detyra të paplanifikuara që dalin nga dialogu.

Kjo metodë ju lejon të grumbulloni shuma maksimale të dhëna cilësore. Megjithatë, mund të përdoret vetëm nëse i besoni profesionalizmit të moderatorit tuaj. Formuluar gabimisht ose në kohën e gabuar pyetjet e bëra mund të ndikojë shumë në sjelljen dhe përshtypjet e të anketuarit dhe madje të zhvleftësojë rezultatet e testit. Gjithashtu, kur përdoret kjo metodë, pothuajse asnjë metrikë nuk mund të matet.

Retrospektive mendo me zë të lartë, RTA (retrospektivë). Ky është një kombinim i dy metodave të para. Përdoruesi së pari kryen të gjitha detyrat pa ndërhyrje, dhe më pas shfaqet një video e punës së tij para tij, dhe ai komenton sjelljen e tij dhe u përgjigjet pyetjeve të moderatorit. Disavantazhi kryesor i metodës është se koha e testimit rritet shumë. Megjithatë, ka raste kur është optimale.

Për shembull, dikur u përballëm me detyrën e testimit të disa llojeve të turmave (përbindëshave të lojës) në një RPG. Natyrisht, ne nuk mund t'i shpërqendrojmë të anketuarit me pyetje dhe as t'i detyrojmë ata të komentojnë veprimet e tyre gjatë betejës. Kjo do ta bënte të pamundur të luhej një lojë ku nevojitet përqendrim për të fituar. Nga ana tjetër, përdoruesi vështirë se do të mund të kujtonte pas një sërë kontraktimesh nëse e vuri re sëpatën që shkëlqente me ngjyrë të kuqe te miu i parë. Prandaj, në këtë test kemi përdorur metodën RTA. Me secilin përdorues, ne rishikuam betejat e tij dhe diskutuam se cilat efekte të përbindëshave vuri re dhe si i kuptonte ato.

Mundohuni të mendoni se si të merrni të dhëna të mjaftueshme duke ruajtur natyralitetin maksimal të sjelljes së të anketuarit. Pavarësisht nga thjeshtësia dhe shkathtësia e metodës "mendoni me zë", e cila ka qenë prej kohësh më e popullarizuara në testimin e përdorshmërisë, ne po përpiqemi gjithnjë e më shumë ta zëvendësojmë atë me vëzhgim. Nëse moderatori sheh sjellje interesante të të anketuarit, ai do të presë derisa të përfundojë detyrën dhe më pas të bëjë një pyetje. Menjëherë pas detyrës, ka më shumë gjasa që i anketuari të kujtojë pse e bëri atë.

Një gjurmues i syve ndihmon shumë në këtë çështje. Duke parë fokusin e vëmendjes aktuale të të anketuarit, mund ta kuptoni më mirë sjelljen e tij pa bërë pyetje të panevojshme. Në përgjithësi, gjurmuesi i syve përmirëson ndjeshëm cilësinë e moderimit, dhe ky rol, për mendimin tim, nuk është më pak i rëndësishëm sesa aftësia për të ndërtuar harta hit.

Metrikë

Metrikat janë tregues sasiorë të përdorshmërisë. Si rezultat i testimit, gjithmonë merrni një sërë problemesh që gjenden në ndërfaqe. Metrikat ju lejojnë të kuptoni se sa e mirë apo e keqe është gjithçka, dhe gjithashtu ta krahasoni atë me një projekt tjetër ose versione të mëparshme të dizajnit.

Cilat janë metrikat?

Sipas ISO 9241-11, karakteristikat kryesore të përdorshmërisë janë efikasiteti, produktiviteti dhe kënaqësia. Metrika të ndryshme mund të jenë të rëndësishme për projekte të ndryshme, por të gjitha ato janë disi të lidhura me këto tre karakteristika. Unë do të shkruaj për treguesit më të përdorur.

Përfundimi me sukses i detyrave. Ju mund të përdorni një kod binar: u përballua me detyrën ose dështoi. Ne shpesh ndjekim qasjen e Nielsen dhe dallojmë tre lloje të vlerësimeve të suksesit:

• e përfundoi detyrën praktikisht pa probleme - 100%;
• hasi probleme, por e kreu detyrën në mënyrë të pavarur - 50%;
• dështoi detyrën - 0%.

Nëse nga 12 të anketuar, 4 e kanë kryer detyrën lehtësisht, 6 kanë pasur probleme dhe 2 kanë dështuar, atëherë shkalla mesatare e suksesit për këtë detyrë do të jetë 58%.

Ndonjëherë do të hasni në një situatë ku grupi i mesëm Ka të anketuar me shkallë shumë të ndryshme të "problematikës". Për shembull, një i anketuar luftoi me çdo fushë të formës, ndërsa tjetri bëri vetëm një gabim të vogël në fund. Ju mund të jepni rezultatin tuaj sipas gjykimit tuaj, në varësi të asaj që ndodhi në test. Për shembull, 25% - nëse i anketuari sapo ka filluar të kryejë detyrën, ose 80% - nëse ka bërë një gabim të vogël.

Për të shmangur shumë subjektivitet, merrni parasysh shkallët e vlerësimit paraprakisht në vend që të vendosni për secilin të anketuar pas testit. Vlen gjithashtu të merret parasysh se çfarë të bëni me gabimet. Për shembull, ju dhatë detyrën për të blerë bileta filmi në projektin e Kinemasë Mail.Ru. Një nga të anketuarit bleu aksidentalisht një biletë jo për nesër, por për sot dhe nuk e vuri re. Ai ka besim se e ka kryer detyrën dhe ka një biletë në dorë. Por gabimi i tij është aq kritik sa ai nuk do të hyjë në film, kështu që unë do t'i jepja "0%", pavarësisht se bileta ishte blerë.

Shkalla e suksesit është një metrikë shumë e thjeshtë dhe e qartë, dhe unë rekomandoj ta përdorni nëse detyrat tuaja kanë qëllime të qarta. Një vështrim në grafikun e suksesit të detyrës ju lejon të identifikoni shpejt zonat më problematike të ndërfaqes.

Koha e përfundimit të detyrës. Kjo metrikë është vetëm tregues i krahasimit. Si e dini nëse një përdorues përfundon një detyrë në 30 sekonda është e mirë apo e keqe? Por fakti është se koha është zvogëluar në krahasim me versioni i mëparshëm dizajni është tashmë i mirë. Ose fakti që regjistrimi në projektin tonë kërkon më pak kohë sesa konkurrentët. Ka ndërfaqe ku reduktimi i kohës për të përfunduar detyrat është kritik - për shembull, ndërfaqja e punës e një punonjësi të qendrës së thirrjeve.

Megjithatë, kjo metrikë nuk është e zbatueshme për të gjitha detyrat. Le të marrim detyrën e zgjedhjes së një produkti në një dyqan online. Përdoruesit duhet të gjejnë shpejt filtra dhe elementë të tjerë të ndërfaqes që lidhen me kërkimin e produkteve, por vetë procesi i përzgjedhjes do t'i marrë ato kohë të ndryshme, dhe kjo është krejtësisht normale. Kur zgjedhin këpucë, gratë janë të gatshme të shikojnë 20 faqe të rezultateve të kërkimit. Dhe kjo nuk do të thotë domosdoshmërisht se nuk kishte produkte përkatëse në faqet e para ose se nuk i shihnin filtrat. Shpesh ata thjesht duan të shohin të gjitha opsionet.

Frekuenca e problemeve.Çdo raport i testimit të përdorshmërisë përmban një listë të problemeve që kanë hasur të anketuarit. Numri i të anketuarve që kanë hasur një problem është një tregues i shpeshtësisë së tij brenda testit. Kjo metrikë mund të përdoret vetëm nëse përdoruesit tuaj kryejnë saktësisht të njëjtat detyra.

Nëse ka pasur ndryshime në test ose detyrat nuk janë formuluar qartë, por janë përpiluar në bazë të një interviste, atëherë do të jetë e vështirë të llogaritet frekuenca. Do të jetë e nevojshme jo vetëm të numërohen ata që e kanë hasur, por edhe të vlerësohet se sa të anketuar mund të ndeshen me problemin (krye një detyrë të ngjashme, shkoi në të njëjtin seksion). Megjithatë, kjo karakteristikë i lejon ekipit të kuptojë se cilat probleme duhet të rregullohen së pari.

Kënaqësi subjektive. Kjo vlerësim subjektiv komoditeti ose komoditeti i përdoruesit për të punuar me sistemin. Ai zbulohet duke përdorur pyetësorët që të anketuarit plotësojnë gjatë ose pas testimit. Ka pyetësorë standardë. Për shembull, shkalla e përdorshmërisë së sistemit, pyetësori i përdorshmërisë pas studimit ose pyetësori i përvojës së lojës për lojëra. Ose mund të krijoni pyetësorin tuaj.

Këto janë larg nga të vetmet metrika të mundshme. Për shembull, një listë me 10 metrika UX që thekson Jeff Sauro. Për produktin tuaj, matjet mund të jenë të ndryshme: për shembull, në çfarë niveli i kuptojnë të anketuarit rregullat e lojës, sa gabime bëjnë kur plotësojnë formularë të gjatë. Mos harroni se vendimi për të përdorur shumë metrika imponon një sërë kufizimesh në testim. Të anketuarit duhet të veprojnë sa më natyrshëm dhe në të njëjtat kushte. Prandaj, do të ishte mirë të sigurohet:

• Pikat e përbashkëta të fillimit. Të njëjtat detyra për të anketuar të ndryshëm duhet të fillojnë nga e njëjta pikë ndërfaqe. Pas çdo detyre, mund t'u kërkoni të anketuarve të kthehen në faqen kryesore.
• Asnjë ndërhyrje. Çdo komunikim me një moderator mund të ndikojë në matjet e performancës nëse moderatori padashur i sugjeron diçka të anketuarit dhe rrit kohën që duhet për të përfunduar detyrën.
• Rendi i detyrave. Për të kompensuar efektin e të mësuarit në testimi krahasues, sigurohuni që të ndryshoni rendin e prezantimit në produktet e krahasuara për të anketuar të ndryshëm. Gjysma le të fillojë me projektin tuaj dhe gjysma me një projekt konkurrues.
• Kriteret e suksesit. Mendoni paraprakisht se çfarë lloj sjelljeje e konsideroni të suksesshme për detyrën: për shembull, a është e pranueshme që i anketuari të mos përdorë filtra kur zgjedh një produkt në një dyqan online.

Interpretimi i metrikës

Mos harroni se testimi klasik i përdorshmërisë është një studim cilësor dhe metrikat që merrni janë kryesisht ilustruese. Ato ofrojnë një përmbledhje të skenarëve të ndryshëm në një produkt, duke ju lejuar të shihni pikat e dhimbjes. Për shembull, krijimi i një llogarie shkakton më shumë vështirësi sesa regjistrimi në sistem. Ata mund të tregojnë dinamikën e ndryshimit nëse i matni rregullisht. Kjo do të thotë, metrikat na lejojnë të kuptojmë se dizajni i ri na lejon të kryejmë detyrën më shpejt. Janë këto marrëdhënie që janë shumë më treguese dhe më të besueshme se vlerat absolute të metrikës së gjetur.

Jeff Sauro, një ekspert statistikor në kërkimin UX, këshillon që të mos përfaqësohen metrikat si mesatare, por të përdoren gjithmonë intervale besimi. Kjo është shumë më e saktë, veçanërisht nëse ka ndryshime në rezultatet e të anketuarve. Për ta bërë këtë, ju mund të përdorni kalkulatorët e tij falas në internet: për sukses dhe për kohën e përfundimit të detyrës. Ju nuk mund të bëni pa përpunim statistikor kur krahasoni rezultatet.

Kur nevojiten metrikat?

Jo çdo raport i testimit të përdorshmërisë përmban metrikë. Mbledhja dhe analiza e tyre kërkon kohë dhe imponon kufizime në metodat e testimit. Këtu janë rastet në të cilat ato janë vërtet të nevojshme:

• Provoj. Shpesh ekziston nevoja për të vërtetuar se duhet të bëhen ndryshime në një produkt, veçanërisht në kompanitë e mëdha. Për vendimmarrësit, numrat janë vizualë, të kuptueshëm dhe të njohur. Kur tregoni se 10 nga 12 të anketuar nuk ishin në gjendje të paguanin për një artikull, ose se regjistrimi në sistem zgjat mesatarisht dy herë më shumë se konkurrentët, kjo u jep rezultateve të hulumtimit më shumë peshë.
• Krahasoni. Nëse e krahasoni produktin tuaj me të tjerët në treg, ju nevojiten edhe metrikë. Përndryshe, do të shihni avantazhet dhe disavantazhet e projekteve të ndryshme, por nuk do të jeni në gjendje të vlerësoni se ku renditet produkti juaj mes tyre.
• Shihni ndryshimet. Metrikat janë të mira për të testuar rregullisht të njëjtin produkt pasi të jenë bërë ndryshime. Ato ju lejojnë të shihni përparimin pas ridizajnimit dhe t'i kushtoni vëmendje atyre vendeve që kanë mbetur pa përmirësime. Ju mund t'i përdorni përsëri këta tregues si një bazë dëshmie që do t'i tregojë menaxhmentit peshën e investimeve në ridizajnim. Ose thjesht për të kuptuar se keni arritur rezultate dhe po ecni në drejtimin e duhur.
• Ilustroni, bëni një theksim. Numrat funksionojnë mirë për të ilustruar çështje të rëndësishme. Ndonjëherë ne i numërojmë ato për momentet më të habitshme dhe më të rëndësishme të testit, edhe nëse nuk përdorim metrikë në të gjitha detyrat.

Megjithatë, ne nuk përdorim metrikë në çdo test. Ju mund të bëni pa to, nëse studiuesi punon ngushtë me ekipin e projektit, ka besim të brendshëm dhe ekipi është mjaft i pjekur për t'i dhënë përparësi zgjidhjes së problemeve.

Metoda e regjistrimit të të dhënave

Do të duket, çfarë nuk shkon me një bllok shënimesh dhe stilolaps apo thjesht dokument i hapur Fjalë? Në botën e sotme të zhvillimit Agile, studiuesit UX duhet të përpiqen t'i kthejnë gjetjet e tyre në ekip sa më shpejt që të jetë e mundur.

Për të optimizuar kohën e analizës, është mirë të përgatisni paraprakisht një shabllon për futjen e shënimeve gjatë testit. Ne u përpoqëm ta bënim këtë në një të specializuar software(për shembull, Noldus Observer ose Morae Manager), por në praktikë tabelat rezultuan të ishin më fleksibilet dhe më të gjithanshëm. Paraprakisht, shënoni në tabelë pyetjet që planifikoni të bëni, vendet për futjen e problemeve të gjetura në detyra, si dhe hipotezat (për secilin të anketuar do të shënoni nëse është konfirmuar apo jo). Shenjat tona duken kështu:

Çfarë tjetër mund të përdorni:

• . I personalizueshëm Modeli i Excel për të futur vëzhgime për çdo të anketuar. Ekziston një kohëmatës i integruar që mat kohën që duhet për të përfunduar detyrat dhe grafikët e kohës dhe suksesit gjenerohen automatikisht.
• Rainbow Spreadsheet nga Tomer Sharon i Google. Tabela vizuale për bashkëpunimi studiues dhe ekip. Lidhja çon në një artikull që përshkruan metodën, dhe ka gjithashtu një lidhje me një spreadsheet të Google me një shabllon.

Me përvojë, shumica e shënimeve mund të merren gjatë testit. Nëse nuk e keni arritur në kohë, është më mirë të shkruani gjithçka që mbani mend menjëherë pas testit. Nëse i ktheheni analizës pas disa ditësh, me shumë mundësi do t'ju duhet të rishikoni videon dhe të kaloni shumë më tepër kohë.

Përgatitja për testim

Përveç metodës, metrikës dhe vetë protokollit të testimit, duhet të vendosni për gjërat e mëposhtme:

Forma e komunikimit me moderatorin. Moderatori mund të jetë në të njëjtën dhomë me pjesëmarrësin e testit. Në këtë rast, do ta ketë të lehtë të bëjë pyetje në kohë. Megjithatë, prania e një moderatori mund të ndikojë tek i padituri: ai do të fillojë t'i bëjë pyetje moderatorit, duke e provokuar atë që ta shtyjë në mënyrë eksplicite ose të nënkuptuar.

Ne përpiqemi ta lëmë të anketuarin vetëm me produktin për të paktën një pjesë të testit. Në këtë mënyrë sjellja e tij bëhet më e relaksuar dhe e natyrshme. Dhe për të mos vrapuar përpara dhe mbrapa nëse diçka nuk shkon, mund të lini çdo mesazher me lidhje audio të ndezur në mënyrë që moderatori të kontaktojë të anketuarin nga dhoma e vëzhgimit.

Mënyra e vendosjes së detyrave. Detyrat mund të shpallen nga një moderator. Por në këtë rast, pavarësisht protokollit uniform të testimit, teksti i detyrës mund të shqiptohet paksa ndryshe çdo herë. Kjo është veçanërisht e vërtetë nëse testi kryhet nga disa moderatorë. Ndonjëherë edhe dallimet e vogla në formulim mund t'i vendosin të anketuarit në kushte të ndryshme fillestare.

Për të shmangur këtë, ju ose mund t'i "stërvitni" moderatorët që të lexojnë gjithmonë tekstet e detyrës, ose t'u jepni të anketuarve detyra në copa letre ose në ekran. Dallimet në formulim pushojnë së qeni problem nëse përdorni një skenar fleksibël, kur detyrat formulohen gjatë testit, bazuar në një intervistë me moderatorin.

Ju mund të përdorni mjetet e produktit për të vendosur detyra. Për shembull, gjatë testimit të ICQ, të anketuarit morën detyra përmes një dritareje bisede me një moderator, dhe kur testonin Mail.Ru Mail, ata i morën ato me letra. Kjo mënyrë e vendosjes së detyrave ishte sa më e natyrshme për këto projekte, dhe ne testuam shumë herë edhe skenarët bazë të korrespondencës.

Krijimi i një konteksti natyror. Edhe nëse po flasim për teste laboratorike, mendoni se si ta afroni përdorimin e produktit në test kushte reale. Për shembull, nëse jeni duke testuar pajisje celulare, si do t'i mbajnë të anketuarit ato? Për imazh i mirë Në regjistrimet video, është më mirë kur telefoni ose tableti është i fiksuar në një mbajtëse ose shtrirë në një tavolinë. Sidoqoftë, kjo nuk e bën të qartë nëse të gjitha zonat janë të arritshme dhe të përshtatshme për t'u shtypur, sepse telefonat shpesh mbahen me njërën dorë, dhe me tableta ata shtrihen në divan.

Vlen të mendoni për mjedisin në të cilin do të përdoret produkti: a ka diçka që e shpërqendron personin, a është e zhurmshme, a ka një lidhje të mirë në internet. E gjithë kjo mund të simulohet në laborator.

Plani i testimit për klientin. Kjo është gjithashtu një fazë e rëndësishme përgatitore pasi përfshin ekipin e projektit. Ju nuk duhet t'i tregoni klientit të gjitha tiparet metodologjike të testit (si do të komunikoni me të anketuarin, si do të regjistroni të dhënat, etj.). Por sigurohuni t'i tregoni atij se cilat do të jenë detyrat dhe çfarë do të provoni mbi to. Ndoshta nuk keni marrë parasysh disa veçori të projektit, ose ndoshta ekipi i projektit do t'i ketë ide shtesë dhe hipoteza. Zakonisht përfundojmë me një shenjë si kjo:

Raporto planin. Natyrisht, raporti është shkruar në bazë të rezultateve të studimit. Por është një praktikë e mirë për të hartuar një plan raporti përpara kryerjes së testeve, bazuar në qëllimet dhe objektivat e studimit. Me një plan të tillë para jush, ju mund të kontrolloni skriptin tuaj për plotësinë, si dhe të përgatisni format më të përshtatshme për të kapur të dhënat për analizat e mëvonshme. Ju mund të vendosni që një raport nuk është i nevojshëm dhe se një dosje e përgjithshme vëzhgimesh është e mjaftueshme për ju dhe ekipin. Dhe nëse motivoni ekipin tuaj që ta plotësojë atë me ju, kjo do të jetë absolutisht e mrekullueshme.

Natyrisht, ju thjesht mund të "lëreni mikun tuaj të përdorë produktin" dhe të shihni se çfarë vështirësish ka ai ose ajo. Por një skenar i shkruar mirë do t'ju lejojë të mos humbisni çështje të rëndësishme dhe të mos e shtyni aksidentalisht të anketuarin drejt përgjigjeve që ju nevojiten. Në fund të fundit, testimi i përdorshmërisë është një eksperiment i thjeshtuar, dhe në çdo eksperiment, përgatitja paraprake është e rëndësishme.

Protokolli për çdo test të përdorshmërisë përbëhet nga pjesët e mëposhtme:

• Udhëzim ose informim (mirëseardhje, përshkrim i ngjarjes, nënshkrimi i dokumenteve).
• Intervistë hyrëse (test shqyrtimi, intervistë e shkurtër rreth përdorimit të produktit, kontekstit dhe skenarëve).
• Puna me produktin (detyrat e testimit).
• Mbledhja e përshtypjeve përfundimtare të produktit bazuar në përvojën e testimit.

Udhëzim ose informim

Pavarësisht nga lënda e testimit, çdo studim fillon në të njëjtën mënyrë. Çfarë duhet bërë:

Krijo një atmosferë. Njihuni me personin, ofroni çaj, kafe ose ujë, tregoni se ku është tualeti. Mundohuni ta relaksoni pak të anketuarin, pasi ai mund të jetë nervoz para ngjarjes. Zbuloni nëse ishte e lehtë t'ju gjeja, pyesni se si jeni.

Përshkruani procesin. Na tregoni se çfarë lloj ngjarjeje e pret të anketuarin, sa kohë do të zgjasë, nga cilat pjesë përbëhet dhe çfarë do të bëni. Sigurohuni që t'i vini në dukje të anketuarit se kontributi i tij do të ndihmojë në përmirësimin e produktit dhe se nuk po testoni aftësitë e një personi. Nëse jeni duke incizuar video, paralajmëroni të paditurin për këtë dhe thuajini se të dhënat nuk do të shfaqen në internet. Unë them diçka si kjo:

Ne jemi të vendosur në zyrën e Mail.Ru Group. Sot do të flasim për projektin XXX. Kjo do të zgjasë rreth një orë. Fillimisht do të flasim pak, pastaj do t'ju kërkoj të përpiqeni të bëni diçka në vetë projektin dhe më pas do të diskutojmë përshtypjet tuaja. Ne do të incizojmë atë që po ndodh në dhomë dhe në ekranin e kompjuterit. Regjistrimi është i nevojshëm vetëm për analiza; nuk do ta shihni veten në internet.

Ne po bëjmë kërkime për ta përmirësuar projektin XXX, për të kuptuar se çfarë duhet të rregullohet në të dhe në cilin drejtim duhet të zhvillohet. Prandaj, ju kërkoj të shprehni hapur çdo koment: pozitiv dhe negativ. Mos kini frikë të na ofendoni. Nëse diçka nuk ju shkon gjatë studimit të një projekti, merreni me qetësi. Kjo do të thotë se ne kemi gjetur një problem që ekipi i projektit duhet ta rregullojë. Gjëja kryesore është të mbani mend se ne nuk po ju testojmë, ju po testoni produktin. Nëse jeni gati, ju sugjeroj të filloni.

Për të nënshkruar dokumente. Si rregull, ky është pëlqimi për përpunimin e të dhënave personale, dhe ndonjëherë edhe një marrëveshje për moszbulimin e informacionit rreth testimit. Për testet me të mitur, kërkohet pëlqimi i prindërve që fëmija i tyre të marrë pjesë në studim. Zakonisht ua dërgojmë prindërve paraprakisht dhe u kërkojmë ta sjellin me vete. Sigurohuni që të shpjegoni pse po kërkoni të nënshkruani dokumentet dhe t'u jepni kohë për t'i shqyrtuar ato. Në Rusi, njerëzit janë të kujdesshëm ndaj çdo dokumenti që kërkohet të nënshkruhet.

Vendosja e pajisjeve. Nëse përdorni gjurmimin e syve, pajisje biometrike ose thjesht regjistroni video, tani është koha për t'i aktivizuar të gjitha. Paralajmëroni të paditurin kur të filloni regjistrimin.

Intervistë hyrëse

Ai zgjidh problemet e mëposhtme:

Kontrollo rekrutimin. Për të qenë në anën e sigurt, gjithmonë filloni atje - edhe nëse i besoni agjencisë ose personit që e ka gjetur të paditurin. Më shumë se një herë gjatë testit kemi zbuluar se i anketuari i ka keqkuptuar pyetjet dhe në fakt nuk e ka përdorur produktin pikërisht ashtu siç na duhej. Mundohuni të shmangni formalitetin dhe shmangni pyetjet nga pyetësori i shqyrtimit: personi mund ta dijë tashmë se çfarë të përgjigjet.

Skenarët dhe konteksti për përdorimin e produktit. Edhe nëse nuk keni shumë kohë për testin, mos e anashkaloni këtë hap. Të paktën në përgjithësi, zbuloni nga i anketuari se çfarë problemesh zgjidh ai me ndihmën e produktit, nëse përdor projekte të ngjashme, në çfarë kushtesh ndërvepron me ta dhe nga cilat pajisje. Përgjigjet do t'ju ndihmojnë të kuptoni më mirë arsyet e sjelljes së të anketuarit dhe nëse jeni duke përdorur një skenar fleksibël, atëherë formuloni detyra të përshtatshme. Nëse keni kohë të mjaftueshme, kërkojini të anketuarit të tregojë se çfarë dhe si bën zakonisht. Ky mund të jetë një burim pyetjesh dhe njohurish të mëtejshme.

Pritjet dhe marrëdhëniet. Fillimi i testimit është një kohë e mirë për të zbuluar se çfarë di i anketuari për produktin, si ndihet për të dhe çfarë pret prej tij. Pas testit, ju do të jeni në gjendje të krahasoni pritjet tuaja me përshtypjen tuaj përfundimtare.

Për shumicën e testeve, kjo strukturë e intervistës hyrëse do të funksionojë. Nëse jeni duke testuar një produkt të ri, mund të dëshironi të kaloni pyetjet hyrëse. Nëse futeni në shumë detaje rreth një teme, mund të krijojë pritshmëri të caktuara për përdoruesit në lidhje me produktin. Prandaj, lini vetëm disa pyetje të përgjithshme për të krijuar kontakt me të anketuarin dhe menjëherë kaloni te detyrat, dhe është më mirë të diskutoni skenarët, marrëdhëniet dhe kontekstin pasi përdoruesi të ketë studiuar fillimisht produktin.

Puna me produktin, shkrimi i detyrave

Cilat janë detyrat?

Le të imagjinojmë se dëshironi të provoni një dyqan online. Ju keni skenarë të rëndësishëm (kërkimi dhe përzgjedhja e mallrave, procesi i porositjes), probleme të njohura (gabime të shpeshta në formularin e pagesës) dhe madje edhe një hipotezë se projektuesi ka bërë diçka të gabuar me filtrin e çmimit. Si të formuloni detyrat?

Detyra të fokusuara. Duket e qartë të bësh diçka të tillë: “Zgjidh pjatalarëse 45 centimetra e gjerë me një funksion "rreze në dysheme" që kushton jo më shumë se 30 mijë rubla." Kjo e motivon të anketuarin të përdorë filtra dhe të krahasojë produktet me njëri-tjetrin. Ju mund të kontrolloni filtrin e çmimeve për të gjithë të anketuarit dhe të shikoni skenarin kryesor për zgjedhjen e një produkti. Detyra të tilla kanë të drejtën e jetës dhe janë të mira për testimin e hipotezave specifike (si me filtrin e çmimeve).

Sidoqoftë, nëse i gjithë testi përbëhet prej tyre, atëherë rrezikoni sa vijon:

• Kontrolli i ndërfaqes në vend. Do të gjeni vetëm çështje që lidhen me detajet e punës (filtroni sipas çmimit dhe gjerësisë). Nuk do të shihni probleme të tjera - të tilla si klasifikimi i produkteve ose filtra të tjerë - nëse nuk i vini në dukje gjithashtu. Por nuk ka gjasa të jeni në gjendje të përfundoni detyrat për të gjithë elementët e faqes.
• Mungesa e angazhimit. Përdoruesit shpesh kryejnë detyra të tilla mekanikisht. Kur shohin produktin e parë që përputhet me kriteret, ndalojnë. Ndoshta i anketuari nuk ka zgjedhur kurrë një pjatalarëse në jetën e tij dhe nuk i intereson se çfarë është "trare në dysheme". Sa më e ngjashme të jetë një detyrë me një situatë të jetës reale dhe sa më shumë kontekst të sigurojë që përdoruesi mund ta kuptojë, aq më të larta janë shanset për të angazhuar një të intervistuar që do të pretendojë se po zgjedh në të vërtetë një produkt. Dhe një përdorues i angazhuar "përjeton" më mirë ndërfaqen, lë më shumë komente, rrit shanset e tij për të gjetur probleme dhe për të ofruar njohuri të dobishme për sjelljen dhe karakteristikat e audiencës.
• Gama e ngushtuar e njohurive. Në jetën reale, përdoruesi ndoshta do të zgjidhte një produkt krejtësisht ndryshe. Për shembull, nuk do të përdorja fare filtra (dhe këtu i theksuat). Ose do të kërkoja një produkt bazuar në kritere që nuk janë në faqe. Duke dhënë detyra të ngurta dhe të fokusuara, nuk do të mësoni për kontekstin real të përdorimit të produktit, nuk do të gjeni skenarë që ekipi i projektit mund të mos ketë parashikuar dhe nuk do të mbledhë të dhëna për nevojat e përmbajtjes dhe funksionalitetit.

Detyrat me kontekst. Një mënyrë për të angazhuar më mirë përdoruesit është ta shtoni atë në një detyrë të thatë histori reale dhe konteksti. Për shembull, në vend të "Gjeni një recetë për byrek me kumbulla në faqen e internetit", sugjeroni sa vijon: "Do të keni mysafirë brenda një ore. Gjeni diçka për të pjekur gjatë kësaj kohe. Ju keni gjithçka për biskotën në frigorifer, si dhe disa kumbulla. Por, për fat të keq, nuk ka gjalpë.”

Një qasje e ngjashme mund të përdoret me një dyqan online. Për shembull: “Imagjinoni sikur po zgjidhni një dhuratë për motrën tuaj. Kohët e fundit tharësja e saj u prish dhe ajo do të ishte e lumtur të merrte një të re. Ju duhet të plotësoni 7 mijë rubla. Është e rëndësishme që i anketuari me të vërtetë të zgjedhë një person të vërtetë për të cilin do të "blejë" dhuratën (nëse nuk ka motër, sugjeroni një të afërm ose mik tjetër). Faktori kryesor për detyra të tilla është realiteti dhe qartësia e kontekstit. Është e lehtë të imagjinohet se po zgjidhni një dhuratë për familjen tuaj, por është shumë më e vështirë të imagjinohet se jeni "një kontabilist që përgatit një raport vjetor".

Një shembull i mrekullueshëm i kësaj qasjeje është "metoda Bollywood", e cila u shpik nga eksperti indian UX Apala Lahiri Chavan. Ajo argumenton se indianët, si shumë aziatikë, e kanë të vështirë të flasin hapur për ndërfaqen. Por, duke e imagjinuar veten si heronj të situatave dramatike imagjinare (si në filmat e tyre të preferuar), ata hapen dhe fillojnë të marrin pjesë aktive në testim. Prandaj, detyrat për indianët duhet të duken diçka si kjo:

Imagjinoni që mbesa juaj e re e dashur po martohet. Dhe pastaj zbuloni se burri i saj i ardhshëm është një mashtrues, dhe i martuar. Ju duhet urgjentisht të blini dy bileta fluturimi për në Bangalore për veten tuaj dhe për gruan e mashtruesit në mënyrë që të prishni dasmën dhe të shpëtoni familjen nga turpi. Nxitoni!

Detyrat e bazuara në përvojën e të anketuarve. Ju kujtojmë: për testim të suksesshëm, të anketuarit duhet të korrespondojnë me audiencën e projektit. Prandaj, për të kontrolluar një dyqan online të pajisjeve shtëpiake, ne rekrutojmë ata që kanë zgjedhur së fundmi pajisje ose po i zgjedhin ato tani. Kjo është pikërisht ajo që ne do të përdorim kur krijojmë detyra bazuar në përvojën e të anketuarve. Ekzistojnë dy mundësi për të përdorur këtë qasje:

• Parametrat e të anketuarit. Në këtë rast, ju përshtatni detyrat fikse për të anketuarit. Për shembull, në rastin e një dyqani pajisjesh shtëpiake dhe një detyrë për të punuar me filtra, ju pyesni personin se çfarë saktësisht ka blerë së fundmi. Zbuloni kriteret (çmimi, funksionet) dhe ofroni për të përsëritur "blerjen" në faqen tuaj të internetit.
• Skenarët e të anketuarve. Detyrat formohen plotësisht në bazë të përvojës së pjesëmarrësve. Për të kuptuar se cilët skenarë duhet të kontrollohen, moderatori zbulon saktësisht se si personi e ka zgjidhur problemin në jetë dhe sugjeron ta bëjë atë në faqen e internetit. Për shembull, një blerës kaloi një kohë të gjatë duke krahasuar disa modele përpara se të zgjidhte. Edhe nëse faqja nuk ka një funksion të përshtatshëm, ftoni të anketuarin të krahasojë produktet për të kuptuar se në cilat parametra do të mbështetet. Ndoshta do të merrni ide se si duhet të duket funksioni i krahasimit dhe gjithashtu do të përshtatni faqen e produktit me këtë skenar.

Detyra të tilla japin shumë shembuj realë kryerja e operacioneve bazë në produkt. Kjo shpesh shkakton një gamë shumë më të gjerë problemesh dhe gjetjesh. Për më tepër, ju lejon të testoni produktin në skenarë të rinj që nuk i keni konsideruar bazë ose as që i keni menduar.

Kur testuam projektin Mail.Ru Real Estate, ishin detyrat e bazuara në përvojën e të anketuarve që na ndihmuan të bënim shumë zbulime. Ne pamë që kur kërkonin një apartament në rajonin e Moskës, njerëzit tregojnë stacionet e fundit të metrosë në gjeofiltër, që do të thotë se këto janë stacione që mund të arrihen nga rajoni. Prisnim që filtri i metrosë kërkonte një apartament pranë stacionit. Mësuam gjithashtu se si skenarët e kërkimit për ndërtesat e reja ndryshojnë nga ato dytësore, gjë që ndihmoi në zhvendosjen e kërkimit për ndërtesa të reja në një seksion tjetër të faqes - me filtrat e vet dhe konceptin e vet për përshkrimin e apartamenteve. Unë rekomandoj gjithashtu të lexoni artikullin e shkëlqyer të Jared Spool mbi përfitimet e detyrave të tilla.

Detyra pa detyra. Ndonjëherë është më mirë të mos u ofroni përdoruesve fare detyra për të punuar me projektin, por të shihni se ku ata vetë fillojnë të njihen me produktin. Jepini të anketuarit një hyrje: “Imagjinoni që vendosni të provoni këtë produkt. Do të të lë për disa minuta. Bëni atë që do të bënit në jetën reale. Nuk të jap asnjë detyrë”.

Është e rëndësishme që moderatori të largohet nga dhoma në këtë moment. Përndryshe, përdoruesi tundohet të pyesë menjëherë diçka, për të sqaruar: “A duhet të regjistrohem? Si mund ta bëj këtë?” e kështu me radhë.

Ky lloj detyre është i dobishëm për produkte krejtësisht të reja. Shpesh e përdorim për aplikacione dhe lojëra celulare. Kështu zbulojmë nëse përdoruesit lexojnë materiale trajnimi, cilat detaje tërheqin menjëherë vëmendjen, çfarë kuptojnë njerëzit për konceptin e produktit dhe si i përshkruajnë më pas aftësitë e tij. Pas detyrës së lirë, planifikohen skenarë specifikë.

Një fushë tjetër e aplikimit për detyra falas janë projektet e përmbajtjes. Nëse doni të kuptoni se si lexohen artikujt tuaj (ku qëndrojnë për një kohë të gjatë, çfarë kapërcejnë, cilat elemente në faqe u kushtojnë vëmendje), atëherë thjesht lini të anketuarin vetëm me projektin për disa minuta. Vetëm pa një moderator që shikon mbi supe, përdoruesi do të relaksohet dhe do ta lexojë tekstin në të njëjtën mënyrë si zakonisht. Kështu testojmë projektet "Mail.Ru News", "Mail.Ru Lady" dhe të tjerët. Kjo qasje bëri të mundur identifikimin e modeleve të ndryshme të sjelljes në sajt, modeleve të ndryshme të leximit të artikujve dhe të kuptuarit se cilat lloje materialesh duhet të formatohen ndryshe.

Bërja e detyrave të mira

Detyra e parë është e thjeshtë. Filloni testimin me detyra hyrëse dhe të thjeshta. I anketuari duhet të ndihet rehat me formatin e testit, veçanërisht nëse jeni duke përdorur metodën e të menduarit me zë të lartë: ata duhet të mësohen të shprehin mendimet dhe ndjenjat e tyre. Ju nuk duhet të hidhni menjëherë mbi të gjithë dhimbjen dhe vuajtjet e ndërfaqes.

Mos më jep asnjë sugjerim. Formuloni detyra në mënyrë që të mos nxitni të anketuarin veprimet e drejta. Nëse dëshironi të provoni aftësinë për të shtuar produkte në të preferuarat në një dyqan online, bëni pa detyrën "Le ta shtojmë këtë televizor në të preferuarat", veçanërisht nëse butoni quhet në atë mënyrë. I anketuari, pasi të ketë lexuar detyrën, thjesht do të gjejë një buton në ekran me nënshkrimin e dëshiruar - ndoshta pa e kuptuar as se çfarë po bën saktësisht.

Shtë më mirë të shpjegoni kuptimin e detyrës pa përdorur terma në ndërfaqe. Për shembull: “Në faqe mund të ruani produktet që ju pëlqejnë dhe më pas zgjidhni cilin të porosisni. Le të përpiqemi ta bëjmë këtë me një televizor të tillë.”

Shikoni terminologjinë. Mos përdorni fjalë dhe simbole të paqarta. Kjo duket e qartë, por ne, pasi jemi mësuar me terma të caktuar, shpesh harrojmë se pak njerëz jashtë komunitetit të IT i njohin ato. Për shembull, kur testuam funksionalitetin e ri të fijeve (zinxhirët e shkronjave) në Mail.Ru Mail, patëm një kohë të vështirë. Në fund të fundit, përdoruesit që nuk janë të njohur me këtë funksion thjesht nuk kanë një term në kokën e tyre që do të tregonte fijet.

Në fund, ne nuk i quajtëm asgjë. Ne thjesht u treguam të anketuarve një kuti me zinxhirë të lidhur dhe diskutuam këtë mundësi e re, dhe i lejoi përdoruesit të zgjidhnin fjalën e tyre për të treguar fijet. Kjo na ndihmoi të përdorim më vonë tekstet më të kuptueshme në materialet promovuese edukative.

Ndiqni jo vetëm detyrat, por edhe pyetjet e moderatorit, veçanërisht ato që vijnë nga ekipi gjatë testimit. Për shembull, kur diskutoni funksionet, nuk duhet të përdorni fjalën "bar": jo të gjithë janë të njohur me të. Vetëm disa vjet më parë, jo të gjithë përdoruesit e dinin as fjalën "shfletues". Mënyra më e mirë për të formuluar detyrat varet nga audienca e testimit. Ju nuk duhet të shkoni në ekstremin tjetër, duke shpjeguar të gjitha termat me radhë. Për shembull, lojtarët me përvojë nuk kanë nevojë të shpjegojnë se çfarë janë "buff", "frag", "respawn" dhe kështu me radhë.

Më pak testim. Shpesh është joshëse të krijosh një llogari testimi për të anketuarin në sistem dhe të kryesh testime në të. Në fund të fundit, ju mund të testoni gjithçka në këtë llogari paraprakisht, të shmangni problemet dhe të mos humbni kohë për të regjistruar ose autorizuar një të anketuar. Shpesh është edhe teknikisht shumë më e lehtë për t'u mundësuar Dizajn i ri bazuar në të dhënat e testit, jo të dhëna reale.

Sidoqoftë, me këtë qasje rrezikoni të merrni rezultate shumë më pak të dobishme, sepse veprimet e testimit nuk kanë pasoja reale. Situata bëhet krejtësisht artificiale; është e vështirë për përdoruesit që ta projektojnë atë në përvojën reale.

Për shembull, kur punoni në llogarinë e vet në një rrjet social, të anketuarit, si në jetën reale, do të bëjnë me kujdes gjithçka që mund të shohin miqtë e tyre (publikojnë lidhje, dërgojnë mesazhe). Kur vendoset kuti e vet në postë ata do të përpiqen të mos fshijnë letra të rëndësishme. Kur testoni dyqanet online, ndonjëherë përdoret një qasje ku shpërblimi duhet të shpenzohet drejtpërdrejt gjatë testit. Në këtë rast, i anketuari nuk do të prekë produktin e parë që i përshtatet detyrës, por do të zgjedhë atë që i nevojitet në të vërtetë.

Vetëm me të dhënat e testimit, do të gjeni probleme që lidhen vetëm me të, në vend që të testoni funksionalitetin në variacione të ndryshme. Për shembull, kur testuam panelin social të shfletuesit Amigo, një nga të anketuarit, i cili lidhi llogarinë e tij VKontakte me panelin, vuri në dukje menjëherë se ishte e papërshtatshme për të të lexonte në këtë mënyrë. Pothuajse i gjithë furnizimi përbëhej nga abonime në grupe me fotografi erotike. Dhe në panelin e ngushtë në foto ishte thjesht e pamundur të shihej asgjë.

Një problem tjetër me të dhënat e testit është se është e vështirë të kuptohet sistemi, pasi gjithçka përreth është e pazakontë. Për shembull, një përdorues i rrjetit social është mësuar të njohë faqen e tij nga foto e vet. Edhe gjatë testimit të prototipave, ne përpiqemi t'i personalizojmë sa më shumë që të jetë e mundur. Për shembull, kur testojmë prototipe të klikueshme në Odnoklassniki, ne gjithmonë i përshtatim ato për secilin përdorues, duke futur emrin dhe foton e tij, dhe ndonjëherë lajmet më të fundit, në faqe.

Mos u kufizoni nga ndërfaqja. Mos harroni se ndërveprimi me një produkt shpesh nuk kufizohet vetëm në ndërfaqen. Nëse është e mundur, testoni produktet ose shërbimet e lidhura dhe lidhjet ndërmjet tyre. Gjatë testimit të lojërave, ne përpiqemi të kontrollojmë jo vetëm lojën, por edhe faqen e saj të internetit dhe shkarkimet e lidhura, regjistrimin në lojë dhe kërkimin e informacionit në forum. Dhe kur testova një dyqan në internet, kontrollova gjithashtu thirrjen e operatorit pasi vendosa një porosi, e cila dha rekomandime për qendrën e thirrjeve.

Mendoni për kohën. Për një skenar të mirë, është e rëndësishme t'i jepni përparësi detyrave. Me shumë mundësi, nëse sistemi është i madh dhe testi ka shumë qëllime, do të dëshironi të bëni shumë detyra. Megjithatë, një i anketuar i lodhur nuk do të jetë më i dobishëm. Test i mirë zgjat jo më shumë se një orë e gjysmë, dy është maksimumi. Përjashtim janë ndoshta lojërat. Dhe mbani mend se qëllimet tuaja nuk janë vetëm detyrat, por edhe intervistat, pyetësorët, vendosja e pajisjeve dhe nënshkrimi i dokumenteve. E gjithë kjo zakonisht zgjat të paktën gjysmë ore.

Nëse ka shumë detyra dhe nuk doni të hiqni dorë nga disa, mund t'i vendosni ato me më pak prioritet në rotacion, domethënë të tregoni vetëm pjesë të të anketuarve. Ose bëni një pjesë të testit të detyrueshëm për të gjithë, dhe pjesën tjetër shikoni vetëm me ata që kanë kohë të mjaftueshme. Por këta me shumë mundësi do të jenë të anketuarit më të suksesshëm.

Vlerësoni dobinë e detyrës. Mendoni nëse përputhet vërtet me hipotezat tuaja. Për shembull, ju dëshironi të testoni funksionin e abonimit të lajmeve në një faqe interneti. Detyra "Abonohu ​​në buletinin" do të kontrollojë vetëm nëse buletini mund të gjendet nga ata që e kërkojnë atë. Megjithatë, njerëzit rrallë vijnë në sit për t'u abonuar në lajme. Detyra nuk vlen për jetën reale. Ju duhet të kuptoni nëse mundësia për t'u abonuar vërehet nga ata që kryejnë detyra krejtësisht të ndryshme.

Kjo mund të kontrollohet në mënyra të ndryshme, në varësi të zbatimit të funksionit. Nëse një person ishte i angazhuar në detyra në të cilat ai mund të kishte parë opsionin e abonimit, pyeteni nëse është në sit. Vetëm sigurohuni që të sqaroni se ku e pa këtë mundësi ose si u zbatua për t'u siguruar që i padituri nuk është thjesht dakord me ju.

Nëse një ofertë abonimi është e integruar në procesin e regjistrimit ose arkëtimit, shikoni nëse i anketuari përfiton prej saj dhe diskutoni atë pas detyrës. Ka shumë pak mundësi që në kushte laboratorike njerëzit të abonohen në listat e postimeve, por mund të kontrolloni nëse një person i kushtoi vëmendje kësaj mundësie, çfarë pret nga lista e postimeve, etj.

Mbledhja e përshtypjeve përfundimtare

Qëllimi i fazës përfundimtare të testimit është të mbledhë përshtypjet e punës me produktin, të kuptojë se çfarë i pëlqeu përdoruesit dhe çfarë e shqetësoi atë dhe të vlerësojë kënaqësinë subjektive. Në mënyrë tipike, kjo pjesë e testit përdor një kombinim të një interviste me një moderator dhe plotësimin e pyetësorëve formalë.

Intervistë me moderatorin

Në intervistën përfundimtare, ne gjithmonë u bëjmë të anketuarve përafërsisht të njëjtat pyetje: "Cilat ishin përshtypjet tuaja?", "Çfarë ju pëlqeu dhe çfarë jo?", "A kishte ndonjë gjë që dukej e vështirë apo e papërshtatshme?", "Çfarë ishte mungon?” , “Çfarë do të dëshironit të ndryshonit në produkt?” Është koha për të sqaruar aspekte të paqarta të sjelljes së të anketuarit nëse nuk e keni bërë këtë gjatë testit. Nëse, para testit, keni zbuluar nga përdoruesit qëndrimin e tyre ndaj markës ose produktit dhe pritshmëritë e tyre prej tij, zbuloni nëse diçka ka ndryshuar. Kur intervistoni, kushtojini vëmendje sa vijon:

Dëshira sociale. Trajtoni rezultatet e intervistës me shumë kujdes. Nëse gjatë testit shpesh dëgjoni komente impulsive nën ndikimin e problemeve, atëherë në intervistën përfundimtare do të lulëzojë dëshira sociale.

Disa njerëz mendojnë se kur flasin për probleme në një produkt, ata po pranojnë paaftësinë e tyre. Të tjerët thjesht nuk duan të mërzitin një moderator të këndshëm. Shumë shpesh, të anketuarit (sidomos gratë) që vuajtën gjatë gjithë testit thonë se gjithçka është, në parim, normale. Reagimi negativ mund të diktohet edhe nga dëshirueshmëria sociale: nëse i anketuari beson se qëllimi i testit është të gjejë të metat, ai përpiqet me zell t'i gjejë ato.

Kuotat dhe prioritetet. Megjithëse të gjitha fjalët e testuesve në intervistën përfundimtare shpesh duhet të ndahen me dy apo edhe dhjetë, kjo nuk do të thotë se ato janë të kota. Bazuar në mënyrën se si të anketuarit përmbledhin përshtypjet e tyre, ju mund të nxirrni përparësitë. Produkt - " është thith"? Çfarë ndikoi konkretisht në këtë? Cilin nga problemet e shumta i padituri kujton më shumë dhe e konsideron më të bezdisshëm?

Megjithatë, merrni parasysh faktin që detyra e fundit mbahet mend më së miri. Është gjithashtu shumë e dobishme të gjurmosh se çfarë mbiemrash përdorin të anketuarit për të përshkruar produktin dhe me çfarë krahasojnë përvojën e tyre.

Të mos harrojmë të mirat. Shumë shpesh, një raport i testimit të përdorshmërisë është një listë e gjatë e problemeve të gjetura gjatë testit. Në përgjithësi, gjetja e problemeve është një nga detyrat kryesore të kërkimit. Por mos harroni për aspektet pozitive produkt.

Së pari, një raport pa rezultate pozitive thjesht demotivon ekipin. Dhe së dyti, është e dobishme të dini se çfarë pëlqejnë përdoruesit në lidhje me produktin: çka nëse gjatë ridizajnimit të ardhshëm ata vendosin të heqin funksionin që të gjithëve u pëlqeu aq shumë. Prandaj, sigurohuni që të pyesni të anketuarit për aspektet pozitive të produktit, edhe nëse ata kritikuan ndërfaqen gjatë testimit.

Qëndrimi ndaj "dëshirave". Me shumë mundësi, të anketuarit, përveç përshtypjeve të tyre, do të shprehin dëshira dhe ide. Detyra juaj është të kuptoni se cili është problemi pas propozimeve. Sepse zgjidhjet që ofrojnë përdoruesit me shumë mundësi nuk do t'ju përshtaten. Në fund të fundit, pjesëmarrësit e testimit nuk janë projektues; ata nuk janë të vetëdijshëm për veçoritë dhe kufizimet e zhvillimit. Megjithatë, pas çdo kërkese të tillë fshihet një nevojë që ju duhet ta kapni. Nëse një i anketuar thotë se i duhet absolutisht një buton i madh jeshil këtu, sigurohuni që të pyesni: pse?

Masa e kënaqësisë

Shpesh, sipas fjalëve të të anketuarit në intervistën përfundimtare, është e vështirë të kuptohet nëse i pëlqeu produkti apo jo, dhe akoma më e vështirë të krahasohet qëndrimi i disa të anketuarve që vunë në dukje si avantazhet ashtu edhe disavantazhet. Këtu studiuesit i vijnë në ndihmë pyetësorët. Së pari, kur plotësoni pyetësorin (sidomos para se të flisni me moderatorin), ndikimi i dëshirueshmërisë famëkeqe shoqërore është pak më i vogël, megjithëse nuk do të shpëtoni plotësisht prej tij. Së dyti, pyetësori ju jep parametra të qartë për krahasimin e skenarëve, produkteve ose fazave të projektit.

Përpilimi i një pyetësori të mirë është një temë më vete dhe shumë e madhe. Formulimi, peshoret dhe shumë më tepër janë të rëndësishme këtu. Pyetësorët e gatshëm dhe të provuar mund të jenë një ndihmë e mirë: ata tashmë janë përmirësuar dhe testuar shumë herë. Problemi i vetëm është se pothuajse të gjithë këta pyetësorë nuk kanë përkthime zyrtare në rusisht. Natyrisht, mund t'i përktheni vetë, por nga pikëpamja metodologjike, përkthimet duhet të testohen për të kontrolluar korrektësinë e formulimit. Megjithatë, pyetësorët mund të shërbejnë si udhëzues kur krijoni pyetësorët tuaj.

Ka pyetësorë që jepen pas çdo detyre për të vlerësuar kënaqësinë me skenarë specifikë. Për shembull:

• Pyetësori pas skenarit (ASQ). Tre pyetje rreth kompleksitetit, produktivitetit dhe sugjerimeve në sistem.
• Pyetje e vetme e thjeshtë (SEQ) . Një pyetje në lidhje me kompleksitetin e skenarit.

Dhe ka pyetësorë që përdoren tashmë në fazën përfundimtare të testimit. Këtu janë disa shembuj që ne përdorim kur është e nevojshme:

• Shkalla e përdorshmërisë së sistemit dhe pyetësori i përdorshmërisë së sistemit pas studimit. Dy pyetësorë klasikë dhe të njohur të krijuar më shumë se 20 vjet më parë. Të dyja përbëhen nga deklarata. Të anketuarit duhet të tregojnë nivelin e pajtimit me ta. Të gjitha këto deklarata me anët e ndryshme karakterizojnë përdorshmërinë e produktit. Për shembull: "Unë mund të gjeja lehtësisht informacionin që më duhej," " Mundësi të ndryshme sistemet janë lehtësisht të aksesueshme” e kështu me radhë.
• . Një pyetësor që na ndihmon shpesh gjatë testeve. Përdoruesi pajiset me një grup mbiemrash nga të cilët zgjedh ata që mund të karakterizojnë produktin. Si rezultat, ju merrni një re fjalësh - karakteristikat e projektit tuaj. Shpesh kjo teknikë sjell rezultate shumë interesante.
• Pyetësori i përvojës së lojës. Pyetësorët klasikë të përdorshmërisë nuk mund të aplikohen në lojëra: përfshirja në lojë është shumë më e rëndësishme sesa kuptueshmëria e ndërfaqeve. Prandaj, gjithmonë duhet të krijoni pyetësorë të veçantë për lojëra ose të përdorni Pyetësorin e Përvojës së Lojërave. Pyetësori përmban disa module: një modul bazë, një bllok në lojë, një pyetësor pas dhe një pyetësor. mundësitë sociale lojëra.
Materiali i publikuar nga përdoruesi. Klikoni butonin "Shkruaj" për të ndarë mendimin tuaj ose për të folur për projektin tuaj.

Përgatitja, intervistat dhe mbledhja e të dhënave

Tek faqeshënuesit

Natalia Sprogis, kreu i kërkimit UX në Mail.Ru Group, foli në blogun e kompanisë në Habrahabr për përgatitjen dhe kryerjen e testimit të përdorshmërisë: çfarë të përfshihet në skriptin e testit, si të zgjidhni një metodë të mbledhjes së të dhënave, të krijoni detyra dhe të mblidhni përshtypjet e të anketuarve .

Një plan testimi është, nga njëra anë, një grup detyrash, pyetjesh dhe pyetësorësh që i jepni secilit të anketuar dhe nga ana tjetër, është baza metodologjike e studimit: metrikat dhe hipotezat që testoni dhe regjistroni, mjetet e zgjedhura.

A është vërtet i nevojshëm testimi?

Së pari, duhet të jeni të sigurt se në këtë fazë projekti ka nevojë për testim të përdorshmërisë. Prandaj, sqaroni se për çfarë qëllimi po ju kontakton ekipi i projektit. Testimi i përdorshmërisë nuk është i gjithëfuqishëm dhe tashmë në fillim duhet të kuptoni se çfarë mund t'i sjellë produktit. Përgatitni menjëherë ekipin tuaj të projektit për të ditur se cilat pyetje mund t'u përgjigjeni dhe cilat jo. Ka pasur raste kur ne ose u kemi ofruar klientëve një metodë tjetër (për shembull, intervistat e thelluara ose studimet e ditarit janë më të mira tani), ose rekomandojmë që ta braktisin studimin fare dhe të bëjnë një test të ndarë.

Për shembull, ne kurrë nuk testojmë "tërheqjen" e një opsioni tipar ose dizajni në kërkimin cilësor. Ne mund të mbledhim reagime nga përdoruesit, por ekziston një rrezik shumë i madh që përgjigjet e tyre të ndikohen nga dëshira sociale. Njerëzit janë gjithmonë të prirur të thonë se do të përdorin edhe atë që nuk do ta përdorin. Dhe madhësia e vogël e mostrës nuk na lejon t'u besojmë përgjigjeve të tilla. Për shembull, ne patëm një përvojë të pasuksesshme duke testuar faqet e uljes së lojërave: faqja e uljes që u zgjodh si më tërheqëse në test rezultoi shumë më keq gjatë testimit A/B.

Testimi i prototipave dhe koncepteve ka gjithashtu një sërë kufizimesh. Kur planifikoni, duhet të kuptoni se çfarë mund të përfitoni vërtet nga ky test. Është mirë kur një projekt ka mundësinë të testojë prototipe ose dizajne përpara zbatimit. Sidoqoftë, sa më pak i detajuar dhe funksional të jetë prototipi, aq më i lartë është niveli i abstraksionit për të anketuarin, aq më pak të dhëna mund të merren nga testi. Është mirë të testohen prototipet për të identifikuar problemet me emërtimin dhe metaforat e ikonave, domethënë të gjitha çështjet e kuptueshmërisë. Aftësia për të testuar çdo gjë përtej kësaj varet shumë nga natyra e projektit dhe detajet e prototipit.

Baza për të shkruar një skript testi të përdorshmërisë

Planifikimi i testit fillon jo me shkrimin e tekstit të detyrave, por me një përpunim të detajuar të qëllimeve dhe pyetjeve kërkimore së bashku me ekipin e projektit. Këtu është baza për të bërë një plan:

Skenarë të rëndësishëm. Këta janë ata skenarë përdoruesish (detyra ose raste përdorimi) që prekin biznesin ose kanë të bëjnë me qëllimin e testimit. Edhe nëse ekipi dyshon për probleme në fusha specifike, shpesh ia vlen të kontrollohen rastet themelore. Në këtë rast, skenarët e mëposhtëm mund të konsiderohen të rëndësishëm për testin:

• më e shpeshta (për shembull, dërgimi i një mesazhi në mesazher);
• ndikimi i qëllimeve të biznesit (për shembull, puna me një formular pagese);
• lidhur me përditësimin (ata që preken nga ridizajnimi ose futja e funksionalitetit të ri).

Çështje të njohura Shpesh, kërkimi duhet të japë përgjigje për shkaqet e problemeve të biznesit të një shërbimi. Për shembull, prodhuesi është i shqetësuar për daljen e madhe të lojtarëve pas orës së parë të lojës. Dhe ndonjëherë zonat problematike të ndërfaqes janë tashmë të njohura për ekipin, dhe ju duhet të grumbulloni detaje dhe specifika. Për shembull, shërbimi mbështetës shpesh kontaktohet me pyetje në lidhje me formën e pagesës.

Pyetje. Ekipi mund të ketë gjithashtu pyetje për të hulumtuar: për shembull, a vërejnë përdoruesit një baner që reklamon shërbime shtesë; A emërtohet qartë një seksion i caktuar?

Hipotezat. Kjo është ajo në të cilën përkthehen çështjet dhe pyetjet e njohura të ekipit. Është mirë nëse klienti vjen tek ju me hipoteza të gatshme - për shembull, "Klientët tanë paguajnë vetëm me telefon me një komision. Përdoruesit mund të mos shohin një zgjedhje të një mënyre pagese më fitimprurëse.” Nëse nuk ka hipoteza, por ekziston vetëm dëshira për të testuar projektin në mënyrë abstrakte "për përdorshmërinë", detyra juaj është të formuloni këto hipoteza.

Mendoni me ekipin e projektit për vendet ku përdoruesit nuk sillen siç pritej (nëse ka një informacion të tillë). Zbuloni nëse ka ndonjë element dizajni që është debatuar shumë dhe mund të jetë problematik. Bëni auditimin tuaj të produktit për të gjetur probleme të mundshme për përdoruesit që janë të rëndësishme për t'u testuar. E gjithë kjo do t'ju ndihmojë të bëni një listë të atyre elementeve (detyrave, pyetjeve, kontrolleve) që duhet të përfshihen në skenarin përfundimtar.

Metoda e mbledhjes së të dhënave

Është e rëndësishme të merret parasysh se si do të grumbulloni të dhëna për atë që ndodh gjatë testit për analiza të mëvonshme. Opsionet e mëposhtme përdoren tradicionalisht:

Vrojtim. Gjatë kryerjes së detyrave, i anketuari mbetet vetëm me produktin dhe sillet siç e sheh të arsyeshme. Komentet e të anketuarit mblidhen përmes pyetësorëve dhe komunikimit me moderatorin pas testit. Kjo është metoda "më e pastër"; ajo siguron sjellje më të natyrshme të të anketuarit dhe aftësinë për të matur saktë një numër metrikash (për shembull, koha për të përfunduar një detyrë).

Megjithatë, ka shumë të dhëna të dobishme cilësore prapa skenave. Duke parë këtë apo atë sjellje të një të anketuari, nuk mund ta kuptoni pse ai vepron në këtë mënyrë. Sigurisht, ju mund të pyesni për këtë në fund të testit, por ka shumë të ngjarë që i anketuari do ta mbajë mend mirë vetëm detyrën e fundit. Për më tepër, gjatë përfundimit të detyrave, mendimi i tij për sistemin mund të ndryshojë, dhe ju do të merrni vetëm pamjen përfundimtare, dhe jo përshtypjet e para.

Mendo me zë të lartë (mendon me zë të lartë). Për një kohë të gjatë, kjo metodë është përdorur më shpesh në testimin e përdorshmërisë. Jakob Nielsen dikur e quajti atë mjeti kryesor i vlerësimit të përdorshmërisë. Çështja është që ju i kërkoni të anketuarit të shprehë të gjitha mendimet që lindin gjatë punës me ndërfaqen dhe të komentojë të gjitha veprimet e tij. Duket diçka si kjo: "Tani do ta shtoj këtë artikull në karrocën time. Ku është butoni? Ah, këtu është ajo. Oh, harrova të shikoja se çfarë ngjyre ishte.”

Metoda ndihmon për të kuptuar pse përdoruesi sillet në një mënyrë ose në një tjetër dhe cilat emocione ngjall tek ai ndërveprimi aktual. Është e lirë dhe e thjeshtë, madje edhe një studiues i papërvojë mund ta trajtojë atë.

Megjithatë, ajo ka të metat e saj. Së pari, nuk është shumë e natyrshme që njerëzit të "mendojnë me zë të lartë" gjatë gjithë kohës. Ata shpesh do të heshtin dhe do t'ju duhet t'i kujtoni vazhdimisht që të vazhdojnë të flasin. Së dyti, detyrat me këtë metodë kërkojnë pak më shumë kohë për t'u përfunduar sesa në jetën reale. Për më tepër, disa të anketuar fillojnë ta përdorin produktin me më shumë mendim. Duke artikuluar arsyet e veprimeve të tyre, ata përpiqen të veprojnë më racionalisht, dhe thjesht nuk duan të duken si idiotë dhe mund të mos kapni disa momente intuitive të sjelljes së tyre.

Ndërhyrja aktive e moderatorit. Metoda është ideale për testimin e koncepteve dhe prototipeve. Gjatë përfundimit të detyrave, moderatori ndërvepron në mënyrë aktive me përdoruesin: në momentet e duhura ai zbulon arsyet e sjelljes së tij dhe bën pyetje sqaruese. Në disa raste, moderatori mund të lëshojë edhe detyra të paplanifikuara që dalin nga dialogu.

Kjo metodë ju lejon të grumbulloni sasinë maksimale të të dhënave cilësore. Megjithatë, mund të përdoret vetëm nëse i besoni profesionalizmit të moderatorit tuaj. Pyetjet e formuluara gabimisht ose të bëra në kohën e gabuar mund të ndikojnë shumë në sjelljen dhe përshtypjet e të anketuarit dhe madje të zhvlerësojnë rezultatet e testit. Gjithashtu, kur përdoret kjo metodë, pothuajse asnjë metrikë nuk mund të matet.

Retrospektive mendo me zë të lartë, RTA (retrospektivë). Ky është një kombinim i dy metodave të para. Përdoruesi së pari kryen të gjitha detyrat pa ndërhyrje, dhe më pas shfaqet një video e punës së tij para tij, dhe ai komenton sjelljen e tij dhe u përgjigjet pyetjeve të moderatorit. Disavantazhi kryesor i metodës është se koha e testimit rritet shumë. Megjithatë, ka raste kur është optimale.

Për shembull, dikur u përballëm me detyrën e testimit të disa llojeve të turmave (përbindëshave të lojës) në një RPG. Natyrisht, ne nuk mund t'i shpërqendrojmë të anketuarit me pyetje dhe as t'i detyrojmë ata të komentojnë veprimet e tyre gjatë betejës. Kjo do ta bënte të pamundur të luhej një lojë ku nevojitet përqendrim për të fituar. Nga ana tjetër, përdoruesi vështirë se do të mund të kujtonte pas një sërë kontraktimesh nëse e vuri re sëpatën që shkëlqente me ngjyrë të kuqe te miu i parë. Prandaj, në këtë test kemi përdorur metodën RTA. Me secilin përdorues, ne rishikuam betejat e tij dhe diskutuam se cilat efekte të përbindëshave vuri re dhe si i kuptonte ato.

Mundohuni të mendoni se si të merrni të dhëna të mjaftueshme duke ruajtur natyralitetin maksimal të sjelljes së të anketuarit. Pavarësisht nga thjeshtësia dhe shkathtësia e metodës "mendoni me zë", e cila ka qenë prej kohësh më e popullarizuara në testimin e përdorshmërisë, ne po përpiqemi gjithnjë e më shumë ta zëvendësojmë atë me vëzhgim. Nëse moderatori sheh sjellje interesante të të anketuarit, ai do të presë derisa të përfundojë detyrën dhe më pas të bëjë një pyetje. Menjëherë pas detyrës, ka më shumë gjasa që i anketuari të kujtojë pse e bëri atë.

Një gjurmues i syve ndihmon shumë në këtë çështje. Duke parë fokusin e vëmendjes aktuale të të anketuarit, mund ta kuptoni më mirë sjelljen e tij pa bërë pyetje të panevojshme. Në përgjithësi, gjurmuesi i syve përmirëson ndjeshëm cilësinë e moderimit, dhe ky rol, për mendimin tim, nuk është më pak i rëndësishëm sesa aftësia për të ndërtuar harta hit.

Metrikë

Metrikat janë tregues sasiorë të përdorshmërisë. Si rezultat i testimit, gjithmonë merrni një sërë problemesh që gjenden në ndërfaqe. Metrikat ju lejojnë të kuptoni se sa e mirë apo e keqe është gjithçka, dhe gjithashtu ta krahasoni atë me një projekt tjetër ose versione të mëparshme të dizajnit.

Cilat janë metrikat?

Sipas ISO 9241-11, karakteristikat kryesore të përdorshmërisë janë efikasiteti, produktiviteti dhe kënaqësia. Metrika të ndryshme mund të jenë të rëndësishme për projekte të ndryshme, por të gjitha ato janë disi të lidhura me këto tre karakteristika. Unë do të shkruaj për treguesit më të përdorur.

Përfundimi me sukses i detyrave. Ju mund të përdorni një kod binar: u përballua me detyrën ose dështoi. Ne shpesh ndjekim qasjen e Nielsen dhe dallojmë tre lloje të vlerësimeve të suksesit:

• e përfundoi detyrën praktikisht pa probleme - 100%;
• hasi probleme, por e kreu detyrën në mënyrë të pavarur - 50%;
• dështoi detyrën - 0%.

Nëse nga 12 të anketuar, 4 e kanë kryer detyrën lehtësisht, 6 kanë pasur probleme dhe 2 kanë dështuar, atëherë shkalla mesatare e suksesit për këtë detyrë do të jetë 58%.

Ndonjëherë do të hasni në një situatë ku grupi i mesëm përfshin të anketuar me shkallë shumë të ndryshme të "problematikës". Për shembull, një i anketuar luftoi me çdo fushë të formës, ndërsa tjetri bëri vetëm një gabim të vogël në fund. Ju mund të jepni rezultatin tuaj sipas gjykimit tuaj, në varësi të asaj që ndodhi në test. Për shembull, 25% - nëse i anketuari sapo ka filluar të kryejë detyrën, ose 80% - nëse ka bërë një gabim të vogël.

Për të shmangur shumë subjektivitet, merrni parasysh shkallët e vlerësimit paraprakisht në vend që të vendosni për secilin të anketuar pas testit. Vlen gjithashtu të merret parasysh se çfarë të bëni me gabimet. Për shembull, ju dhatë detyrën për të blerë bileta filmi në projektin e Kinemasë Mail.Ru. Një nga të anketuarit bleu aksidentalisht një biletë jo për nesër, por për sot dhe nuk e vuri re. Ai ka besim se e ka kryer detyrën dhe ka një biletë në dorë. Por gabimi i tij është aq kritik sa ai nuk do të hyjë në film, kështu që unë do t'i jepja "0%", pavarësisht se bileta ishte blerë.

Shkalla e suksesit është një metrikë shumë e thjeshtë dhe e qartë, dhe unë rekomandoj ta përdorni nëse detyrat tuaja kanë qëllime të qarta. Një vështrim në grafikun e suksesit të detyrës ju lejon të identifikoni shpejt zonat më problematike të ndërfaqes.

Koha e përfundimit të detyrës. Kjo metrikë është vetëm tregues i krahasimit. Si e dini nëse një përdorues përfundon një detyrë në 30 sekonda është e mirë apo e keqe? Por fakti që koha është zvogëluar në krahasim me versionin e mëparshëm të dizajnit është tashmë i mirë. Ose fakti që regjistrimi në projektin tonë kërkon më pak kohë sesa konkurrentët. Ka ndërfaqe ku reduktimi i kohës për të përfunduar detyrat është kritik - për shembull, ndërfaqja e punës e një punonjësi të qendrës së thirrjeve.

Megjithatë, kjo metrikë nuk është e zbatueshme për të gjitha detyrat. Le të marrim detyrën e zgjedhjes së një produkti në një dyqan online. Përdoruesit duhet të gjejnë shpejt filtra dhe elementë të tjerë të ndërfaqes që lidhen me kërkimin e produkteve, por vetë procesi i përzgjedhjes do t'i marrë ato në periudha të ndryshme, dhe kjo është krejtësisht normale. Kur zgjedhin këpucë, gratë janë të gatshme të shikojnë 20 faqe të rezultateve të kërkimit. Dhe kjo nuk do të thotë domosdoshmërisht se nuk kishte produkte përkatëse në faqet e para ose se nuk i shihnin filtrat. Shpesh ata thjesht duan të shohin të gjitha opsionet.

Frekuenca e problemeve.Çdo raport i testimit të përdorshmërisë përmban një listë të problemeve që kanë hasur të anketuarit. Numri i të anketuarve që kanë hasur një problem është një tregues i shpeshtësisë së tij brenda testit. Kjo metrikë mund të përdoret vetëm nëse përdoruesit tuaj kryejnë saktësisht të njëjtat detyra.

Nëse ka pasur ndryshime në test ose detyrat nuk janë formuluar qartë, por janë përpiluar në bazë të një interviste, atëherë do të jetë e vështirë të llogaritet frekuenca. Do të jetë e nevojshme jo vetëm të numërohen ata që e kanë hasur, por edhe të vlerësohet se sa të anketuar mund të ndeshen me problemin (krye një detyrë të ngjashme, shkoi në të njëjtin seksion). Megjithatë, kjo karakteristikë i lejon ekipit të kuptojë se cilat probleme duhet të rregullohen së pari.

Kënaqësi subjektive. Ky është vlerësimi subjektiv i përdoruesit për komoditetin ose komoditetin e punës me sistemin. Ai zbulohet duke përdorur pyetësorët që të anketuarit plotësojnë gjatë ose pas testimit. Ka pyetësorë standardë. Për shembull, shkalla e përdorshmërisë së sistemit, pyetësori i përdorshmërisë pas studimit ose pyetësori i përvojës së lojës për lojëra. Ose mund të krijoni pyetësorin tuaj.

Këto janë larg nga të vetmet metrika të mundshme. Për shembull, një listë me 10 metrika UX që thekson Jeff Sauro. Për produktin tuaj, matjet mund të jenë të ndryshme: për shembull, në çfarë niveli i kuptojnë të anketuarit rregullat e lojës, sa gabime bëjnë kur plotësojnë formularë të gjatë. Mos harroni se vendimi për të përdorur shumë metrika imponon një sërë kufizimesh në testim. Të anketuarit duhet të veprojnë sa më natyrshëm dhe në të njëjtat kushte. Prandaj, do të ishte mirë të sigurohet:

• Pikat e përbashkëta të fillimit. Të njëjtat detyra për të anketuar të ndryshëm duhet të fillojnë nga e njëjta pikë ndërfaqe. Pas çdo detyre, mund t'u kërkoni të anketuarve të kthehen në faqen kryesore.
• Asnjë ndërhyrje. Çdo komunikim me një moderator mund të ndikojë në matjet e performancës nëse moderatori padashur i sugjeron diçka të anketuarit dhe rrit kohën që duhet për të përfunduar detyrën.
• Rendi i detyrave. Për të kompensuar efektin e të mësuarit në testimin e krahasimit, sigurohuni që të ndryshoni rendin e ekspozimit ndaj produkteve që krahasohen midis të anketuarve. Gjysma le të fillojë me projektin tuaj dhe gjysma me një projekt konkurrues.
• Kriteret e suksesit. Mendoni paraprakisht se çfarë lloj sjelljeje e konsideroni të suksesshme për detyrën: për shembull, a është e pranueshme që i anketuari të mos përdorë filtra kur zgjedh një produkt në një dyqan online.

Interpretimi i metrikës

Mos harroni se testimi klasik i përdorshmërisë është një studim cilësor dhe metrikat që merrni janë kryesisht ilustruese. Ato ofrojnë një përmbledhje të skenarëve të ndryshëm në një produkt, duke ju lejuar të shihni pikat e dhimbjes. Për shembull, krijimi i një llogarie shkakton më shumë vështirësi sesa regjistrimi në sistem. Ata mund të tregojnë dinamikën e ndryshimit nëse i matni rregullisht. Kjo do të thotë, metrikat na lejojnë të kuptojmë se dizajni i ri na lejon të kryejmë detyrën më shpejt. Janë këto marrëdhënie që janë shumë më treguese dhe më të besueshme se vlerat absolute të metrikës së gjetur.

Jeff Sauro, një ekspert statistikor në kërkimin UX, këshillon që të mos përfaqësohen metrikat si mesatare, por të përdoren gjithmonë intervale besimi. Kjo është shumë më e saktë, veçanërisht nëse ka ndryshime në rezultatet e të anketuarve. Për ta bërë këtë, ju mund të përdorni kalkulatorët e tij falas në internet: për sukses dhe për kohën e përfundimit të detyrës. Ju nuk mund të bëni pa përpunim statistikor kur krahasoni rezultatet.

Kur nevojiten metrikat?

Jo çdo raport i testimit të përdorshmërisë përmban metrikë. Mbledhja dhe analiza e tyre kërkon kohë dhe imponon kufizime në metodat e testimit. Këtu janë rastet në të cilat ato janë vërtet të nevojshme:

• Provoj. Shpesh ekziston nevoja për të vërtetuar se duhet të bëhen ndryshime në një produkt, veçanërisht në kompanitë e mëdha. Për vendimmarrësit, numrat janë vizualë, të kuptueshëm dhe të njohur. Kur tregoni se 10 nga 12 të anketuar nuk ishin në gjendje të paguanin për një artikull, ose se regjistrimi në sistem zgjat mesatarisht dy herë më shumë se konkurrentët, kjo u jep rezultateve të hulumtimit më shumë peshë.
• Krahasoni. Nëse e krahasoni produktin tuaj me të tjerët në treg, ju nevojiten edhe metrikë. Përndryshe, do të shihni avantazhet dhe disavantazhet e projekteve të ndryshme, por nuk do të jeni në gjendje të vlerësoni se ku renditet produkti juaj mes tyre.
• Shihni ndryshimet. Metrikat janë të mira për të testuar rregullisht të njëjtin produkt pasi të jenë bërë ndryshime. Ato ju lejojnë të shihni përparimin pas ridizajnimit dhe t'i kushtoni vëmendje atyre vendeve që kanë mbetur pa përmirësime. Ju mund t'i përdorni përsëri këta tregues si një bazë dëshmie që do t'i tregojë menaxhmentit peshën e investimeve në ridizajnim. Ose thjesht për të kuptuar se keni arritur rezultate dhe po ecni në drejtimin e duhur.
• Ilustroni, bëni një theksim. Numrat funksionojnë mirë për të ilustruar çështje të rëndësishme. Ndonjëherë ne i numërojmë ato për momentet më të habitshme dhe më të rëndësishme të testit, edhe nëse nuk përdorim metrikë në të gjitha detyrat.

Megjithatë, ne nuk përdorim metrikë në çdo test. Ju mund të bëni pa to, nëse studiuesi punon ngushtë me ekipin e projektit, ka besim të brendshëm dhe ekipi është mjaft i pjekur për t'i dhënë përparësi zgjidhjes së problemeve.

Metoda e regjistrimit të të dhënave

Do të duket, çfarë nuk shkon me një bllok shënimesh dhe stilolaps ose thjesht një dokument të hapur Word? Në botën e sotme të zhvillimit Agile, studiuesit UX duhet të përpiqen t'i kthejnë gjetjet e tyre në ekip sa më shpejt që të jetë e mundur.

Për të optimizuar kohën e analizës, është mirë të përgatisni paraprakisht një shabllon për futjen e shënimeve gjatë testit. Ne u përpoqëm ta bënim këtë në softuer të specializuar (për shembull, Noldus Observer ose Morae Manager), por në praktikë tabelat rezultuan të ishin më fleksibël dhe universal. Paraprakisht, shënoni në tabelë pyetjet që planifikoni të bëni, vendet për futjen e problemeve të gjetura në detyra, si dhe hipotezat (për secilin të anketuar do të shënoni nëse është konfirmuar apo jo). Shenjat tona duken kështu:

Çfarë tjetër mund të përdorni:

• . Modeli i personalizueshëm i Excel për të futur vëzhgime për çdo të anketuar. Ekziston një kohëmatës i integruar që mat kohën që duhet për të përfunduar detyrat dhe grafikët e kohës dhe suksesit gjenerohen automatikisht.
• Rainbow Spreadsheet nga Tomer Sharon i Google. Një tabelë vizuale për bashkëpunimin midis studiuesit dhe ekipit. Lidhja çon në një artikull që përshkruan metodën, dhe ka gjithashtu një lidhje me një spreadsheet të Google me një shabllon.

Me përvojë, shumica e shënimeve mund të merren gjatë testit. Nëse nuk e keni arritur në kohë, është më mirë të shkruani gjithçka që mbani mend menjëherë pas testit. Nëse i ktheheni analizës pas disa ditësh, me shumë mundësi do t'ju duhet të rishikoni videon dhe të kaloni shumë më tepër kohë.

Përgatitja për testim

Përveç metodës, metrikës dhe vetë protokollit të testimit, duhet të vendosni për gjërat e mëposhtme:

Forma e komunikimit me moderatorin. Moderatori mund të jetë në të njëjtën dhomë me pjesëmarrësin e testit. Në këtë rast, do ta ketë të lehtë të bëjë pyetje në kohë. Megjithatë, prania e një moderatori mund të ndikojë tek i padituri: ai do të fillojë t'i bëjë pyetje moderatorit, duke e provokuar atë që ta shtyjë në mënyrë eksplicite ose të nënkuptuar.

Ne përpiqemi ta lëmë të anketuarin vetëm me produktin për të paktën një pjesë të testit. Në këtë mënyrë sjellja e tij bëhet më e relaksuar dhe e natyrshme. Dhe për të mos vrapuar përpara dhe mbrapa nëse diçka nuk shkon, mund të lini çdo mesazher me lidhje audio të ndezur në mënyrë që moderatori të kontaktojë të anketuarin nga dhoma e vëzhgimit.

Mënyra e vendosjes së detyrave. Detyrat mund të shpallen nga një moderator. Por në këtë rast, pavarësisht protokollit uniform të testimit, teksti i detyrës mund të shqiptohet paksa ndryshe çdo herë. Kjo është veçanërisht e vërtetë nëse testi kryhet nga disa moderatorë. Ndonjëherë edhe dallimet e vogla në formulim mund t'i vendosin të anketuarit në kushte të ndryshme fillestare.

Për të shmangur këtë, ju ose mund t'i "stërvitni" moderatorët që të lexojnë gjithmonë tekstet e detyrës, ose t'u jepni të anketuarve detyra në copa letre ose në ekran. Dallimet në formulim pushojnë së qeni problem nëse përdorni një skenar fleksibël, kur detyrat formulohen gjatë testit, bazuar në një intervistë me moderatorin.

Ju mund të përdorni mjetet e produktit për të vendosur detyra. Për shembull, gjatë testimit të ICQ, të anketuarit morën detyra përmes një dritareje bisede me një moderator, dhe kur testonin Mail.Ru Mail, ata i morën ato me letra. Kjo mënyrë e vendosjes së detyrave ishte sa më e natyrshme për këto projekte, dhe ne testuam shumë herë edhe skenarët bazë të korrespondencës.

Krijimi i një konteksti natyror. Edhe nëse po flasim për teste laboratorike, mendoni se si ta afroni përdorimin e produktit në test me kushtet reale. Për shembull, nëse jeni duke testuar pajisje celulare, si do t'i mbajnë të anketuarit ato? Për një imazh të mirë në video, është më mirë kur telefoni ose tableti është i fiksuar në një mbajtëse ose të shtrirë në një tavolinë. Sidoqoftë, kjo nuk e bën të qartë nëse të gjitha zonat janë të arritshme dhe të përshtatshme për t'u shtypur, sepse telefonat shpesh mbahen me njërën dorë, dhe me tableta ata shtrihen në divan.

Vlen të mendoni për mjedisin në të cilin do të përdoret produkti: a ka diçka që e shpërqendron personin, a është e zhurmshme, a ka një lidhje të mirë në internet. E gjithë kjo mund të simulohet në laborator.

Plani i testimit për klientin. Kjo është gjithashtu një fazë e rëndësishme përgatitore pasi përfshin ekipin e projektit. Ju nuk duhet t'i tregoni klientit të gjitha tiparet metodologjike të testit (si do të komunikoni me të anketuarin, si do të regjistroni të dhënat, etj.). Por sigurohuni t'i tregoni atij se cilat do të jenë detyrat dhe çfarë do të provoni mbi to. Ndoshta nuk keni marrë parasysh disa veçori të projektit, ose ndoshta ekipi i projektit do të ketë ide dhe hipoteza shtesë. Zakonisht përfundojmë me një shenjë si kjo:

Raporto planin. Natyrisht, raporti është shkruar në bazë të rezultateve të studimit. Por është një praktikë e mirë për të hartuar një plan raporti përpara kryerjes së testeve, bazuar në qëllimet dhe objektivat e studimit. Me një plan të tillë para jush, ju mund të kontrolloni skriptin tuaj për plotësinë, si dhe të përgatisni format më të përshtatshme për të kapur të dhënat për analizat e mëvonshme. Ju mund të vendosni që një raport nuk është i nevojshëm dhe se një dosje e përgjithshme vëzhgimesh është e mjaftueshme për ju dhe ekipin. Dhe nëse motivoni ekipin tuaj që ta plotësojë atë me ju, kjo do të jetë absolutisht e mrekullueshme.

Natyrisht, ju thjesht mund të "lëreni mikun tuaj të përdorë produktin" dhe të shihni se çfarë vështirësish ka ai ose ajo. Por një skenar i shkruar mirë do t'ju lejojë të mos humbisni çështje të rëndësishme dhe të mos e shtyni aksidentalisht të anketuarin drejt përgjigjeve që ju nevojiten. Në fund të fundit, testimi i përdorshmërisë është një eksperiment i thjeshtuar, dhe në çdo eksperiment, përgatitja paraprake është e rëndësishme.

Protokolli për çdo test të përdorshmërisë përbëhet nga pjesët e mëposhtme:

• Udhëzim ose informim (mirëseardhje, përshkrim i ngjarjes, nënshkrimi i dokumenteve).
• Intervistë hyrëse (test shqyrtimi, intervistë e shkurtër rreth përdorimit të produktit, kontekstit dhe skenarëve).
• Puna me produktin (detyrat e testimit).
• Mbledhja e përshtypjeve përfundimtare të produktit bazuar në përvojën e testimit.

Udhëzim ose informim

Pavarësisht nga lënda e testimit, çdo studim fillon në të njëjtën mënyrë. Çfarë duhet bërë:

Krijo një atmosferë. Njihuni me personin, ofroni çaj, kafe ose ujë, tregoni se ku është tualeti. Mundohuni ta relaksoni pak të anketuarin, pasi ai mund të jetë nervoz para ngjarjes. Zbuloni nëse ishte e lehtë t'ju gjeja, pyesni se si jeni.

Përshkruani procesin. Na tregoni se çfarë lloj ngjarjeje e pret të anketuarin, sa kohë do të zgjasë, nga cilat pjesë përbëhet dhe çfarë do të bëni. Sigurohuni që t'i vini në dukje të anketuarit se kontributi i tij do të ndihmojë në përmirësimin e produktit dhe se nuk po testoni aftësitë e një personi. Nëse jeni duke incizuar video, paralajmëroni të paditurin për këtë dhe thuajini se të dhënat nuk do të shfaqen në internet. Unë them diçka si kjo:

Ne jemi të vendosur në zyrën e Mail.Ru Group. Sot do të flasim për projektin XXX. Kjo do të zgjasë rreth një orë. Fillimisht do të flasim pak, pastaj do t'ju kërkoj të përpiqeni të bëni diçka në vetë projektin dhe më pas do të diskutojmë përshtypjet tuaja. Ne do të incizojmë atë që po ndodh në dhomë dhe në ekranin e kompjuterit. Regjistrimi është i nevojshëm vetëm për analiza; nuk do ta shihni veten në internet.

Ne po bëjmë kërkime për ta përmirësuar projektin XXX, për të kuptuar se çfarë duhet të rregullohet në të dhe në cilin drejtim duhet të zhvillohet. Prandaj, ju kërkoj të shprehni hapur çdo koment: pozitiv dhe negativ. Mos kini frikë të na ofendoni. Nëse diçka nuk ju shkon gjatë studimit të një projekti, merreni me qetësi. Kjo do të thotë se ne kemi gjetur një problem që ekipi i projektit duhet ta rregullojë. Gjëja kryesore është të mbani mend se ne nuk po ju testojmë, ju po testoni produktin. Nëse jeni gati, ju sugjeroj të filloni.

Për të nënshkruar dokumente. Si rregull, ky është pëlqimi për përpunimin e të dhënave personale, dhe ndonjëherë edhe një marrëveshje për moszbulimin e informacionit rreth testimit. Për testet me të mitur, kërkohet pëlqimi i prindërve që fëmija i tyre të marrë pjesë në studim. Zakonisht ua dërgojmë prindërve paraprakisht dhe u kërkojmë ta sjellin me vete. Sigurohuni që të shpjegoni pse po kërkoni të nënshkruani dokumentet dhe t'u jepni kohë për t'i shqyrtuar ato. Në Rusi, njerëzit janë të kujdesshëm ndaj çdo dokumenti që kërkohet të nënshkruhet.

Vendosja e pajisjeve. Nëse përdorni gjurmimin e syve, pajisje biometrike ose thjesht regjistroni video, tani është koha për t'i aktivizuar të gjitha. Paralajmëroni të paditurin kur të filloni regjistrimin.

Intervistë hyrëse

Ai zgjidh problemet e mëposhtme:

Kontrollo rekrutimin. Për të qenë në anën e sigurt, gjithmonë filloni atje - edhe nëse i besoni agjencisë ose personit që e ka gjetur të paditurin. Më shumë se një herë gjatë testit kemi zbuluar se i anketuari i ka keqkuptuar pyetjet dhe në fakt nuk e ka përdorur produktin pikërisht ashtu siç na duhej. Mundohuni të shmangni formalitetin dhe shmangni pyetjet nga pyetësori i shqyrtimit: personi mund ta dijë tashmë se çfarë të përgjigjet.

Skenarët dhe konteksti për përdorimin e produktit. Edhe nëse nuk keni shumë kohë për testin, mos e anashkaloni këtë hap. Të paktën në përgjithësi, zbuloni nga i anketuari se çfarë problemesh zgjidh ai me ndihmën e produktit, nëse përdor projekte të ngjashme, në çfarë kushtesh ndërvepron me ta dhe nga cilat pajisje. Përgjigjet do t'ju ndihmojnë të kuptoni më mirë arsyet e sjelljes së të anketuarit dhe nëse jeni duke përdorur një skenar fleksibël, atëherë do t'ju ndihmojnë të formuloni detyra të përshtatshme. Nëse keni kohë të mjaftueshme, kërkojini të anketuarit të tregojë se çfarë dhe si bën zakonisht. Ky mund të jetë një burim pyetjesh dhe njohurish të mëtejshme.

Pritjet dhe marrëdhëniet. Fillimi i testimit është një kohë e mirë për të zbuluar se çfarë di i anketuari për produktin, si ndihet për të dhe çfarë pret prej tij. Pas testit, ju do të jeni në gjendje të krahasoni pritjet tuaja me përshtypjen tuaj përfundimtare.

Për shumicën e testeve, kjo strukturë e intervistës hyrëse do të funksionojë. Nëse jeni duke testuar një produkt të ri, mund të dëshironi të kaloni pyetjet hyrëse. Nëse futeni në shumë detaje rreth një teme, mund të krijojë pritshmëri të caktuara për përdoruesit në lidhje me produktin. Prandaj, lini vetëm disa pyetje të përgjithshme për të krijuar kontakt me të anketuarin dhe menjëherë kaloni te detyrat, dhe është më mirë të diskutoni skenarët, marrëdhëniet dhe kontekstin pasi përdoruesi të ketë studiuar fillimisht produktin.

Puna me produktin, shkrimi i detyrave

Cilat janë detyrat?

Le të imagjinojmë se dëshironi të provoni një dyqan online. Ju keni skenarë të rëndësishëm (kërkimi dhe përzgjedhja e mallrave, procesi i porositjes), probleme të njohura (gabime të shpeshta në formularin e pagesës) dhe madje edhe një hipotezë se projektuesi ka bërë diçka të gabuar me filtrin e çmimit. Si të formuloni detyrat?

Detyra të fokusuara. Duket e qartë të bësh diçka të tillë: "Zgjidhni një makinë larëse enësh 45 centimetra të gjerë me funksionin e rrezeve të dyshemesë që kushton jo më shumë se 30 mijë rubla." Kjo e motivon të anketuarin të përdorë filtra dhe të krahasojë produktet me njëri-tjetrin. Ju mund të kontrolloni filtrin e çmimeve për të gjithë të anketuarit dhe të shikoni skenarin kryesor për zgjedhjen e një produkti. Detyra të tilla kanë të drejtën e jetës dhe janë të mira për testimin e hipotezave specifike (si me filtrin e çmimeve).

Sidoqoftë, nëse i gjithë testi përbëhet prej tyre, atëherë rrezikoni sa vijon:

• Kontrolli i ndërfaqes në vend. Do të gjeni vetëm çështje që lidhen me detajet e punës (filtroni sipas çmimit dhe gjerësisë). Nuk do të shihni probleme të tjera - të tilla si klasifikimi i produkteve ose filtra të tjerë - nëse nuk i vini në dukje gjithashtu. Por nuk ka gjasa të jeni në gjendje të përfundoni detyrat për të gjithë elementët e faqes.
• Mungesa e angazhimit. Përdoruesit shpesh kryejnë detyra të tilla mekanikisht. Kur shohin produktin e parë që përputhet me kriteret, ndalojnë. Ndoshta i anketuari nuk ka zgjedhur kurrë një pjatalarëse në jetën e tij dhe nuk i intereson se çfarë është "trare në dysheme". Sa më e ngjashme të jetë një detyrë me një situatë të jetës reale dhe sa më shumë kontekst të sigurojë që përdoruesi mund ta kuptojë, aq më të larta janë shanset për të angazhuar një të intervistuar që do të pretendojë se po zgjedh në të vërtetë një produkt. Dhe një përdorues i angazhuar "përjeton" më mirë ndërfaqen, lë më shumë komente, rrit shanset e tij për të gjetur probleme dhe për të ofruar njohuri të dobishme për sjelljen dhe karakteristikat e audiencës.
• Gama e ngushtuar e njohurive. Në jetën reale, përdoruesi ndoshta do të zgjidhte një produkt krejtësisht ndryshe. Për shembull, nuk do të përdorja fare filtra (dhe këtu i theksuat). Ose do të kërkoja një produkt bazuar në kritere që nuk janë në faqe. Duke dhënë detyra të ngurta dhe të fokusuara, nuk do të mësoni për kontekstin real të përdorimit të produktit, nuk do të gjeni skenarë që ekipi i projektit mund të mos ketë parashikuar dhe nuk do të mbledhë të dhëna për nevojat e përmbajtjes dhe funksionalitetit.

Detyrat me kontekst. Një mënyrë për të angazhuar më mirë përdoruesit është shtimi i historisë dhe kontekstit real në një detyrë të thatë. Për shembull, në vend të "Gjeni një recetë për byrek me kumbulla në faqen e internetit", sugjeroni sa vijon: "Do të keni mysafirë brenda një ore. Gjeni diçka për të pjekur gjatë kësaj kohe. Ju keni gjithçka për biskotën në frigorifer, si dhe disa kumbulla. Por, për fat të keq, nuk ka gjalpë.”

Një qasje e ngjashme mund të përdoret me një dyqan online. Për shembull: “Imagjinoni sikur po zgjidhni një dhuratë për motrën tuaj. Kohët e fundit tharësja e saj u prish dhe ajo do të ishte e lumtur të merrte një të re. Ju duhet të plotësoni 7 mijë rubla. Është e rëndësishme që i anketuari me të vërtetë të zgjedhë një person të vërtetë për të cilin do të "blejë" dhuratën (nëse nuk ka motër, sugjeroni një të afërm ose mik tjetër). Faktori kryesor për detyra të tilla është realiteti dhe qartësia e kontekstit. Është e lehtë të imagjinohet se po zgjidhni një dhuratë për familjen tuaj, por është shumë më e vështirë të imagjinohet se jeni "një kontabilist që përgatit një raport vjetor".

Një shembull i mrekullueshëm i kësaj qasjeje është "metoda Bollywood", e cila u shpik nga eksperti indian UX Apala Lahiri Chavan. Ajo argumenton se indianët, si shumë aziatikë, e kanë të vështirë të flasin hapur për ndërfaqen. Por, duke e imagjinuar veten si heronj të situatave dramatike imagjinare (si në filmat e tyre të preferuar), ata hapen dhe fillojnë të marrin pjesë aktive në testim. Prandaj, detyrat për indianët duhet të duken diçka si kjo:

Imagjinoni që mbesa juaj e re e dashur po martohet. Dhe pastaj zbuloni se burri i saj i ardhshëm është një mashtrues, dhe i martuar. Ju duhet urgjentisht të blini dy bileta fluturimi për në Bangalore për veten tuaj dhe për gruan e mashtruesit në mënyrë që të prishni dasmën dhe të shpëtoni familjen nga turpi. Nxitoni!

Detyrat e bazuara në përvojën e të anketuarve. Ju kujtojmë: për testim të suksesshëm, të anketuarit duhet të korrespondojnë me audiencën e projektit. Prandaj, për të kontrolluar një dyqan online të pajisjeve shtëpiake, ne rekrutojmë ata që kanë zgjedhur së fundmi pajisje ose po i zgjedhin ato tani. Kjo është pikërisht ajo që ne do të përdorim kur krijojmë detyra bazuar në përvojën e të anketuarve. Ekzistojnë dy mundësi për të përdorur këtë qasje:

• Parametrat e të anketuarit. Në këtë rast, ju përshtatni detyrat fikse për të anketuarit. Për shembull, në rastin e një dyqani pajisjesh shtëpiake dhe një detyrë për të punuar me filtra, ju pyesni personin se çfarë saktësisht ka blerë së fundmi. Zbuloni kriteret (çmimi, funksionet) dhe ofroni për të përsëritur "blerjen" në faqen tuaj të internetit.
• Skenarët e të anketuarve. Detyrat formohen plotësisht në bazë të përvojës së pjesëmarrësve. Për të kuptuar se cilët skenarë duhet të kontrollohen, moderatori zbulon saktësisht se si personi e ka zgjidhur problemin në jetë dhe sugjeron ta bëjë atë në faqen e internetit. Për shembull, një blerës kaloi një kohë të gjatë duke krahasuar disa modele përpara se të zgjidhte. Edhe nëse faqja nuk ka një funksion të përshtatshëm, ftoni të anketuarin të krahasojë produktet për të kuptuar se në cilat parametra do të mbështetet. Ndoshta do të merrni ide se si duhet të duket funksioni i krahasimit dhe gjithashtu do të përshtatni faqen e produktit me këtë skenar.

Detyra të tilla ofrojnë shumë shembuj realë të kryerjes së operacioneve bazë në një produkt. Kjo shpesh shkakton një gamë shumë më të gjerë problemesh dhe gjetjesh. Për më tepër, ju lejon të testoni produktin në skenarë të rinj që nuk i keni konsideruar bazë ose as që i keni menduar.

Kur testuam projektin Mail.Ru Real Estate, ishin detyrat e bazuara në përvojën e të anketuarve që na ndihmuan të bënim shumë zbulime. Ne pamë që kur kërkonin një apartament në rajonin e Moskës, njerëzit tregojnë stacionet e fundit të metrosë në gjeofiltër, që do të thotë se këto janë stacione që mund të arrihen nga rajoni. Prisnim që filtri i metrosë kërkonte një apartament pranë stacionit. Mësuam gjithashtu se si skenarët e kërkimit për ndërtesat e reja ndryshojnë nga ato dytësore, gjë që ndihmoi në zhvendosjen e kërkimit për ndërtesa të reja në një seksion tjetër të faqes - me filtrat e vet dhe konceptin e vet për përshkrimin e apartamenteve. Unë rekomandoj gjithashtu të lexoni artikullin e shkëlqyer të Jared Spool mbi përfitimet e detyrave të tilla.

Detyra pa detyra. Ndonjëherë është më mirë të mos u ofroni përdoruesve fare detyra për të punuar me projektin, por të shihni se ku ata vetë fillojnë të njihen me produktin. Jepini të anketuarit një hyrje: “Imagjinoni që vendosni të provoni këtë produkt. Do të të lë për disa minuta. Bëni atë që do të bënit në jetën reale. Nuk të jap asnjë detyrë”.

Është e rëndësishme që moderatori të largohet nga dhoma në këtë moment. Përndryshe, përdoruesi tundohet të pyesë menjëherë diçka, për të sqaruar: “A duhet të regjistrohem? Si mund ta bëj këtë?” e kështu me radhë.

Ky lloj detyre është i dobishëm për produkte krejtësisht të reja. Shpesh e përdorim për aplikacione dhe lojëra celulare. Kështu zbulojmë nëse përdoruesit lexojnë materiale trajnimi, cilat detaje tërheqin menjëherë vëmendjen, çfarë kuptojnë njerëzit për konceptin e produktit dhe si i përshkruajnë më pas aftësitë e tij. Pas detyrës së lirë, planifikohen skenarë specifikë.

Një fushë tjetër e aplikimit për detyra falas janë projektet e përmbajtjes. Nëse doni të kuptoni se si lexohen artikujt tuaj (ku qëndrojnë për një kohë të gjatë, çfarë kapërcejnë, cilat elemente në faqe u kushtojnë vëmendje), atëherë thjesht lini të anketuarin vetëm me projektin për disa minuta. Vetëm pa një moderator që shikon mbi supe, përdoruesi do të relaksohet dhe do ta lexojë tekstin në të njëjtën mënyrë si zakonisht. Kështu testojmë projektet "Mail.Ru News", "Mail.Ru Lady" dhe të tjerët. Kjo qasje bëri të mundur identifikimin e modeleve të ndryshme të sjelljes në sajt, modeleve të ndryshme të leximit të artikujve dhe të kuptuarit se cilat lloje materialesh duhet të formatohen ndryshe.

Bërja e detyrave të mira

Detyra e parë është e thjeshtë. Filloni testimin me detyra hyrëse dhe të thjeshta. I anketuari duhet të ndihet rehat me formatin e testit, veçanërisht nëse jeni duke përdorur metodën e të menduarit me zë të lartë: ata duhet të mësohen të shprehin mendimet dhe ndjenjat e tyre. Ju nuk duhet të hidhni menjëherë mbi të gjithë dhimbjen dhe vuajtjet e ndërfaqes.

Mos më jep asnjë sugjerim. Formuloni detyrat në mënyrë të tillë që të mos e shtyni të anketuarin të bëjë gjënë e duhur. Nëse dëshironi të provoni aftësinë për të shtuar produkte në të preferuarat në një dyqan online, bëni pa detyrën "Le ta shtojmë këtë televizor në të preferuarat", veçanërisht nëse butoni quhet në atë mënyrë. I anketuari, pasi të ketë lexuar detyrën, thjesht do të gjejë një buton në ekran me nënshkrimin e dëshiruar - ndoshta pa e kuptuar as se çfarë po bën saktësisht.

Shtë më mirë të shpjegoni kuptimin e detyrës pa përdorur terma në ndërfaqe. Për shembull: “Në faqe mund të ruani produktet që ju pëlqejnë dhe më pas zgjidhni cilin të porosisni. Le të përpiqemi ta bëjmë këtë me një televizor të tillë.”

Shikoni terminologjinë. Mos përdorni fjalë dhe simbole të paqarta. Kjo duket e qartë, por ne, pasi jemi mësuar me terma të caktuar, shpesh harrojmë se pak njerëz jashtë komunitetit të IT i njohin ato. Për shembull, kur testuam funksionalitetin e ri të fijeve (zinxhirët e shkronjave) në Mail.Ru Mail, patëm një kohë të vështirë. Në fund të fundit, përdoruesit që nuk janë të njohur me këtë funksion thjesht nuk kanë një term në kokën e tyre që do të tregonte fijet.

Në fund, ne nuk i quajtëm asgjë. Ne thjesht u treguam të anketuarve një kuti me fije të lidhura dhe diskutuam këtë veçori të re dhe i lejuam përdoruesit të zgjedhin fjalën për të treguar fijet. Kjo na ndihmoi të përdorim më vonë tekstet më të kuptueshme në materialet promovuese edukative.

Ndiqni jo vetëm detyrat, por edhe pyetjet e moderatorit, veçanërisht ato që vijnë nga ekipi gjatë testimit. Për shembull, kur diskutoni funksionet, nuk duhet të përdorni fjalën "bar": jo të gjithë janë të njohur me të. Vetëm disa vjet më parë, jo të gjithë përdoruesit e dinin as fjalën "shfletues". Mënyra më e mirë për të formuluar detyrat varet nga audienca e testimit. Ju nuk duhet të shkoni në ekstremin tjetër, duke shpjeguar të gjitha termat me radhë. Për shembull, lojtarët me përvojë nuk kanë nevojë të shpjegojnë se çfarë janë "buff", "frag", "respawn" dhe kështu me radhë.

Më pak testim. Shpesh është joshëse të krijosh një llogari testimi për të anketuarin në sistem dhe të kryesh testime në të. Në fund të fundit, ju mund të testoni gjithçka në këtë llogari paraprakisht, të shmangni problemet dhe të mos humbni kohë për të regjistruar ose autorizuar një të anketuar. Shpesh është edhe teknikisht shumë më e lehtë të zbatohet një dizajn i ri mbi të dhënat e testimit sesa në të dhënat reale.

Sidoqoftë, me këtë qasje rrezikoni të merrni rezultate shumë më pak të dobishme, sepse veprimet e testimit nuk kanë pasoja reale. Situata bëhet krejtësisht artificiale; është e vështirë për përdoruesit që ta projektojnë atë në përvojën reale.

Për shembull, kur punojnë në llogarinë e tyre në një rrjet social, të anketuarit, si në jetën reale, do të bëjnë me kujdes gjithçka që mund të shohin miqtë e tyre (publikojnë lidhje, dërgojnë mesazhe). Kur vendosin kutinë e tyre postare, ata do të përpiqen të mos fshijnë letra të rëndësishme. Kur testoni dyqanet online, ndonjëherë përdoret një qasje ku shpërblimi duhet të shpenzohet drejtpërdrejt gjatë testit. Në këtë rast, i anketuari nuk do të prekë produktin e parë që i përshtatet detyrës, por do të zgjedhë atë që i nevojitet në të vërtetë.

Vetëm me të dhënat e testimit, do të gjeni probleme që lidhen vetëm me të, në vend që të testoni funksionalitetin në variacione të ndryshme. Për shembull, kur testuam panelin social të shfletuesit Amigo, një nga të anketuarit, i cili lidhi llogarinë e tij VKontakte me panelin, vuri në dukje menjëherë se ishte e papërshtatshme për të të lexonte në këtë mënyrë. Pothuajse i gjithë furnizimi përbëhej nga abonime në grupe me fotografi erotike. Dhe në panelin e ngushtë në foto ishte thjesht e pamundur të shihej asgjë.

Një problem tjetër me të dhënat e testit është se është e vështirë të kuptohet sistemi, pasi gjithçka përreth është e pazakontë. Për shembull, një përdorues i rrjetit social është mësuar të njohë faqen e tij nga fotografia e tij. Edhe gjatë testimit të prototipave, ne përpiqemi t'i personalizojmë sa më shumë që të jetë e mundur. Për shembull, kur testojmë prototipe të klikueshme në Odnoklassniki, ne gjithmonë i përshtatim ato për secilin përdorues, duke futur emrin dhe foton e tij, dhe ndonjëherë lajmet më të fundit, në faqe.

Mos u kufizoni nga ndërfaqja. Mos harroni se ndërveprimi me një produkt shpesh nuk kufizohet vetëm në ndërfaqen. Nëse është e mundur, testoni produktet ose shërbimet e lidhura dhe lidhjet ndërmjet tyre. Gjatë testimit të lojërave, ne përpiqemi të kontrollojmë jo vetëm lojën, por edhe faqen e saj të internetit dhe shkarkimet e lidhura, regjistrimin në lojë dhe kërkimin e informacionit në forum. Dhe kur testova një dyqan në internet, kontrollova gjithashtu thirrjen e operatorit pasi vendosa një porosi, e cila dha rekomandime për qendrën e thirrjeve.

Mendoni për kohën. Për një skenar të mirë, është e rëndësishme t'i jepni përparësi detyrave. Me shumë mundësi, nëse sistemi është i madh dhe testi ka shumë qëllime, do të dëshironi të bëni shumë detyra. Megjithatë, një i anketuar i lodhur nuk do të jetë më i dobishëm. Një test i mirë zgjat jo më shumë se një orë e gjysmë, dy është maksimumi. Përjashtim janë ndoshta lojërat. Dhe mbani mend se qëllimet tuaja nuk janë vetëm detyrat, por edhe intervistat, pyetësorët, vendosja e pajisjeve dhe nënshkrimi i dokumenteve. E gjithë kjo zakonisht zgjat të paktën gjysmë ore.

Nëse ka shumë detyra dhe nuk doni të hiqni dorë nga disa, mund t'i vendosni ato me më pak prioritet në rotacion, domethënë të tregoni vetëm pjesë të të anketuarve. Ose bëni një pjesë të testit të detyrueshëm për të gjithë, dhe pjesën tjetër shikoni vetëm me ata që kanë kohë të mjaftueshme. Por këta me shumë mundësi do të jenë të anketuarit më të suksesshëm.

Vlerësoni dobinë e detyrës. Mendoni nëse përputhet vërtet me hipotezat tuaja. Për shembull, ju dëshironi të testoni funksionin e abonimit të lajmeve në një faqe interneti. Detyra "Abonohu ​​në buletinin" do të kontrollojë vetëm nëse buletini mund të gjendet nga ata që e kërkojnë atë. Megjithatë, njerëzit rrallë vijnë në sit për t'u abonuar në lajme. Detyra nuk vlen për jetën reale. Ju duhet të kuptoni nëse mundësia për t'u abonuar vërehet nga ata që kryejnë detyra krejtësisht të ndryshme.

Kjo mund të kontrollohet në mënyra të ndryshme, në varësi të zbatimit të funksionit. Nëse një person ishte i angazhuar në detyra në të cilat ai mund të kishte parë opsionin e abonimit, pyeteni nëse është në sit. Vetëm sigurohuni që të sqaroni se ku e pa këtë mundësi ose si u zbatua për t'u siguruar që i padituri nuk është thjesht dakord me ju.

Nëse një ofertë abonimi është e integruar në procesin e regjistrimit ose arkëtimit, shikoni nëse i anketuari përfiton prej saj dhe diskutoni atë pas detyrës. Ka shumë pak mundësi që në kushte laboratorike njerëzit të abonohen në listat e postimeve, por mund të kontrolloni nëse një person i kushtoi vëmendje kësaj mundësie, çfarë pret nga lista e postimeve, etj.

Mbledhja e përshtypjeve përfundimtare

Qëllimi i fazës përfundimtare të testimit është të mbledhë përshtypjet e punës me produktin, të kuptojë se çfarë i pëlqeu përdoruesit dhe çfarë e shqetësoi atë dhe të vlerësojë kënaqësinë subjektive. Në mënyrë tipike, kjo pjesë e testit përdor një kombinim të një interviste me një moderator dhe plotësimin e pyetësorëve formalë.

Intervistë me moderatorin

Në intervistën përfundimtare, ne gjithmonë u bëjmë të anketuarve përafërsisht të njëjtat pyetje: "Cilat ishin përshtypjet tuaja?", "Çfarë ju pëlqeu dhe çfarë jo?", "A kishte ndonjë gjë që dukej e vështirë apo e papërshtatshme?", "Çfarë ishte mungon?” , “Çfarë do të dëshironit të ndryshonit në produkt?” Është koha për të sqaruar aspekte të paqarta të sjelljes së të anketuarit nëse nuk e keni bërë këtë gjatë testit. Nëse, para testit, keni zbuluar nga përdoruesit qëndrimin e tyre ndaj markës ose produktit dhe pritshmëritë e tyre prej tij, zbuloni nëse diçka ka ndryshuar. Kur intervistoni, kushtojini vëmendje sa vijon:

Dëshira sociale. Trajtoni rezultatet e intervistës me shumë kujdes. Nëse gjatë testit shpesh dëgjoni komente impulsive nën ndikimin e problemeve, atëherë në intervistën përfundimtare do të lulëzojë dëshira sociale.

Disa njerëz mendojnë se kur flasin për probleme në një produkt, ata po pranojnë paaftësinë e tyre. Të tjerët thjesht nuk duan të mërzitin një moderator të këndshëm. Shumë shpesh, të anketuarit (sidomos gratë) që vuajtën gjatë gjithë testit thonë se gjithçka është, në parim, normale. Reagimi negativ mund të diktohet edhe nga dëshirueshmëria sociale: nëse i anketuari beson se qëllimi i testit është të gjejë të metat, ai përpiqet me zell t'i gjejë ato.

Kuotat dhe prioritetet. Megjithëse të gjitha fjalët e testuesve në intervistën përfundimtare shpesh duhet të ndahen me dy apo edhe dhjetë, kjo nuk do të thotë se ato janë të kota. Bazuar në mënyrën se si të anketuarit përmbledhin përshtypjet e tyre, ju mund të nxirrni përparësitë. A është produkti "mut i plotë"? Çfarë ndikoi konkretisht në këtë? Cilin nga problemet e shumta i padituri kujton më shumë dhe e konsideron më të bezdisshëm?

Megjithatë, merrni parasysh faktin që detyra e fundit mbahet mend më së miri. Është gjithashtu shumë e dobishme të gjurmosh se çfarë mbiemrash përdorin të anketuarit për të përshkruar produktin dhe me çfarë krahasojnë përvojën e tyre.

Të mos harrojmë të mirat. Shumë shpesh, një raport i testimit të përdorshmërisë është një listë e gjatë e problemeve të gjetura gjatë testit. Në përgjithësi, gjetja e problemeve është një nga detyrat kryesore të kërkimit. Por mos harroni për aspektet pozitive të produktit.

Së pari, një raport pa rezultate pozitive thjesht demotivon ekipin. Dhe së dyti, është e dobishme të dini se çfarë pëlqejnë përdoruesit në lidhje me produktin: çka nëse gjatë ridizajnimit të ardhshëm ata vendosin të heqin funksionin që të gjithëve u pëlqeu aq shumë. Prandaj, sigurohuni që të pyesni të anketuarit për aspektet pozitive të produktit, edhe nëse ata kritikuan ndërfaqen gjatë testimit.

Qëndrimi ndaj "dëshirave". Me shumë mundësi, të anketuarit, përveç përshtypjeve të tyre, do të shprehin dëshira dhe ide. Detyra juaj është të kuptoni se cili është problemi pas propozimeve. Sepse zgjidhjet që ofrojnë përdoruesit me shumë mundësi nuk do t'ju përshtaten. Në fund të fundit, pjesëmarrësit e testimit nuk janë projektues; ata nuk janë të vetëdijshëm për veçoritë dhe kufizimet e zhvillimit. Megjithatë, pas çdo kërkese të tillë fshihet një nevojë që ju duhet ta kapni. Nëse një i anketuar thotë se i duhet absolutisht një buton i madh jeshil këtu, sigurohuni që të pyesni: pse?

Masa e kënaqësisë

Shpesh, sipas fjalëve të të anketuarit në intervistën përfundimtare, është e vështirë të kuptohet nëse i pëlqeu produkti apo jo, dhe akoma më e vështirë të krahasohet qëndrimi i disa të anketuarve që vunë në dukje si avantazhet ashtu edhe disavantazhet. Këtu studiuesit i vijnë në ndihmë pyetësorët. Së pari, kur plotësoni pyetësorin (sidomos para se të flisni me moderatorin), ndikimi i dëshirueshmërisë famëkeqe shoqërore është pak më i vogël, megjithëse nuk do të shpëtoni plotësisht prej tij. Së dyti, pyetësori ju jep parametra të qartë për krahasimin e skenarëve, produkteve ose fazave të projektit.

Përpilimi i një pyetësori të mirë është një temë më vete dhe shumë e madhe. Formulimi, peshoret dhe shumë më tepër janë të rëndësishme këtu. Pyetësorët e gatshëm dhe të provuar mund të jenë një ndihmë e mirë: ata tashmë janë përmirësuar dhe testuar shumë herë. Problemi i vetëm është se pothuajse të gjithë këta pyetësorë nuk kanë përkthime zyrtare në rusisht. Natyrisht, mund t'i përktheni vetë, por nga pikëpamja metodologjike, përkthimet duhet të testohen për të kontrolluar korrektësinë e formulimit. Megjithatë, pyetësorët mund të shërbejnë si udhëzues kur krijoni pyetësorët tuaj.

Ka pyetësorë që jepen pas çdo detyre për të vlerësuar kënaqësinë me skenarë specifikë. Për shembull:

• Pyetësori pas skenarit (ASQ). Tre pyetje rreth kompleksitetit, produktivitetit dhe sugjerimeve në sistem.
• Pyetje e vetme e thjeshtë (SEQ) . Një pyetje në lidhje me kompleksitetin e skenarit.

Dhe ka pyetësorë që përdoren tashmë në fazën përfundimtare të testimit. Këtu janë disa shembuj që ne përdorim kur është e nevojshme:

• Shkalla e përdorshmërisë së sistemit dhe pyetësori i përdorshmërisë së sistemit pas studimit. Dy pyetësorë klasikë dhe të njohur të krijuar më shumë se 20 vjet më parë. Të dyja përbëhen nga deklarata. Të anketuarit duhet të tregojnë nivelin e pajtimit me ta. Të gjitha këto deklarata karakterizojnë përdorshmërinë e produktit nga këndvështrime të ndryshme. Për shembull: "Unë mund të gjeja lehtësisht informacionin që më duhej", "Aftësitë e ndryshme të sistemit janë lehtësisht të arritshme" etj.
• . Një pyetësor që na ndihmon shpesh gjatë testeve. Përdoruesi pajiset me një grup mbiemrash nga të cilët zgjedh ata që mund të karakterizojnë produktin. Si rezultat, ju merrni një re fjalësh - karakteristikat e projektit tuaj. Shpesh kjo teknikë sjell rezultate shumë interesante.
• Pyetësori i përvojës së lojës. Pyetësorët klasikë të përdorshmërisë nuk mund të aplikohen në lojëra: përfshirja në lojë është shumë më e rëndësishme sesa kuptueshmëria e ndërfaqeve. Prandaj, gjithmonë duhet të krijoni pyetësorë të veçantë për lojëra ose të përdorni Pyetësorin e Përvojës së Lojërave. Pyetësori përmban disa module: një modul bazë, një bllok në lojë, një post-pyetësor dhe një pyetësor për aftësitë sociale të lojës.
Materiali i publikuar nga përdoruesi. Klikoni butonin "Shkruaj" për të ndarë mendimin tuaj ose për të folur për projektin tuaj.

Dizenjimi i një produkti, uebsajti ose aplikacioni është një proces shumë i gjatë që kërkon durim, njohuri dhe një sërë mjetesh. Për të kuptuar se çfarë funksionon në të vërtetë dhe çfarë jo, është e rëndësishme të dini se çfarë mendojnë përdoruesit. Këtu hyn testimi i përdoruesit.

Duke bashkuar forcat, UXPin, UserTesting dhe Optimal Workshop vendosën të përshkruanin procesin UX që ndoqën për një Yelp hipotetik:

I gjithë procesi ishte më shumë si një sprint dizajni, i përbërë nga projekte 1-3 javore të fokusuara në zgjidhjen e problemeve specifike.

Një përmbledhje e shkurtër e procesit të projektimit UX

1. Përkufizimi i produktit

Në fazën fillestare, specialistët përcaktuan propozimin e vlerës, avantazhin e padrejtë dhe modelin e përgjithshëm të biznesit. Meqenëse Yelp tashmë kishte pasur sukses të konsiderueshëm në tërheqjen e vizitorëve, ata vendosën se do të ishte interesante të kuptonin se si mund të rrisnin frekuencën e përdorimit. Më pas, u zhvillua një plan i përgjithshëm testimi.

2. Testimi dhe analiza

Gjatë fazës së eksplorimit, ekipi shqyrtoi në detaje planin e testimit dhe kaloi në seanca të pamoderuara. Demografia e përdoruesve u përcaktua dhe detyrat specifike u detajuan. Gjatë punës, u përdorën metoda të ndryshme testimi, duke filluar nga analizimi i të dhënave të ndërveprimeve të përdoruesve me faqen, klasifikimi i kartave në distancë dhe testimi me klikimin e parë.

Sipas UserTesting, një nga parimet kryesore të testimit të përdorshmërisë është përdorimi i detyrave të përgjithshme dhe specifike. E para ju lejon të zbuloni se çfarë mendojnë përdoruesit, ndërsa e dyta zbulon arsyet e zhgënjimit.

Gjatë gjithë testimit, zhvilluesit iu përmbajtën parimeve të mëposhtme:

• Përpunimi i tekstit. Për qëllime nxjerrjeje përfitim maksimal specialistët i rregulluan udhëzimet disa herë për të siguruar që gjuha të ishte sa më koncize dhe inkurajuan veprime specifike. Ky është një parakusht për testimin e pamoderuar në distancë, pasi udhëzimet me shkrim janë të vetmet direktiva për pjesëmarrësit.
• Kryerja (testi pilot). Pasi udhëzimet ishin gati, u krye testimi i pamoderuar në distancë me një përdorues nga grupi i testimit. Ai gjithashtu dha komente mbi vetë udhëzimet në mënyrë që ekipi të korrigjonte çështje të vogla dhe të siguronte qartësi të plotë.
• Sigurimi i detyrave me pyetje përkatëse. Për secilën detyrë, pjesëmarrësi i testit duhej t'i përgjigjej pyetjes "A u krye detyra?", si dhe "Vlerëso nivelin e lehtësisë/vështirësisë". Përgjigja në pyetjen e parë e bëri të qartë nëse detyra ishte e realizueshme; ndërsa e dyta na lejoi të gërmojmë më thellë në përmirësimet e mundshme të dizajnit.
• Shmangia e pyetjeve kryesore. Testimi përdori pyetje të tilla si "Sa e lehtë apo e vështirë ishte për ju të përfundoni këtë detyrë?" në vend të “Sa e vështirë ishte kjo detyrë?”, e cila parandalon mundësinë e një përgjigjeje të njëanshme.

Për të mbledhur të dhëna cilësore dhe sasiore, specialistët kryen tre teste të përdorshmërisë në distancë, secila prej të cilave përfshinte të paktën 5 persona. Pas identifikimit të pikave të dhimbjes, ata zhvilluan rrjedhat e detyrave, duke simuluar hapat e secilit përdorues bazuar në dizajnin aktual. Pas analizimit të tyre dhe identifikimit të të metave të përdorshmërisë, ata përmirësuan flukset, të cilat shërbyen si parimet funksionale ridizajnimi.

3. Projektimi dhe përsëritja

Glen Lipka, nënkryetar i Përvojës së Përdoruesit, beson se një ndërfaqe e qëndrueshme është më e mirë se një ndërfaqe e përsosur e përdoruesit. Konsistenca ushqen njohjen, e cila nga ana tjetër çon në konvertime më të shpeshta. Më poshtë janë disa parime udhëzuese:

• Dizajn për informacion. Njerëzit përdorin faqet e internetit jo për të admiruar dizajnet e bukura, por sepse kanë nevojë për përmbajtje. Në rastin e përshkruar, duke qenë se Yelp është një faqe për kërkimin e tregut të shërbimeve lokale, nevojitet një ridizajnim shpërndarje më të mirë informacioni i duhur për njerëzit e duhur dhe testimi i arkitekturës së informacionit duke përdorur klasifikimin e kartave ishte një pjesë integrale e këtij procesi.
• Duke ndjekur parimin MAYA (Më e Avancuar por e Pranueshme)., "më i avancuari dhe në të njëjtën kohë i perceptuari." Ndërsa ekipi donte të siguronte eksperienca më e mirë për përdoruesit e rastësishëm të Yelp, ata nuk donin të krijonin diçka kaq të huaj që mund t'i çaktivizonte përdoruesit me përvojë ose ngatërroni të rejat.
• Studimi i modeleve të ndërfaqes së përdoruesit. Janë studiuar modelet ekzistuese ndërfaqja e përdoruesit në faqe të tjera të njohura dhe gjeti diçka që mund të adoptohej prej tyre.
• Bëjeni sitin të këndshëm dhe të lehtë për t'u përdorur (i përdorshëm). Përvoja për përdoruesit e rastësishëm të Yelp duhej të ishte më e qartë. Në të njëjtën kohë, specialistët donin të ruanin një të këndshme pamjen faqe.

Qëllimi përfundimtar ishte arritja e një maksimumi lokal. Projekti u përfundua pasi kostot tejkaluan përfitimet e përsëritjes shtesë. Duke pasur parasysh kohën e kufizuar të sprintit të dizajnit, zhvilluesit nuk u fokusuan në arritjen e maksimumit global.

Kuptimi i biznesit tuaj përpara testimit

Para se të filloni të punoni në UX, së pari duhet të kuptoni biznesin tuaj. Çfarë problemesh zgjidh, si sjell para? Në çfarë mënyrash është i suksesshëm dhe në çfarë mënyrash mund të përmirësohet?

Kështu, në fazën e parë të ridizajnimit, ju analizoni modelin e biznesit, identifikoni përmirësimet e nevojshme UX dhe më pas vendosni për hipotezat dhe një plan testimi.

Për hapin e parë, ekspertët zgjodhën sepse është një vizualizim i lehtë dhe në të njëjtën kohë gjithëpërfshirës i biznesit:

Ne nuk do t'ju mërzitim me të gjithë dokumentacionin, kështu që thjesht shikoni se si mund ta bëni këtë për qëllime UX në Yelp shembull:

• Më së shumti problemi kryesor: Njerëzit në një qytet të caktuar duan [produktin/shërbimin] [më të mirë/më të shpejtë/më të lirë/më të lehtë].
• 3 funksionet më themelore: Vlerësimet e përdoruesve, rrjedha e aktivitetit, kërkimi sipas qytetit/kategorisë.
• Propozim Unique Value: Aftësia për të listuar bizneset, për të shtuar komente dhe për të parë bizneset e rekomanduara nga miqtë dhe përdoruesit e tjerë.
• “Përparësi e padrejtë” (ajo që nuk mund të kopjohet ose blihet): Efektet e rrjetit të të pasurit një bazë të madhe përdoruesish.

Shumica pika të rëndësishme janë funksioni i kërkimit dhe arkitektura e informacionit. Nëse njerëzit nuk mund të gjejnë atë që u nevojitet, ata nuk do të shkruajnë komente. Ridizajnimi duhet të organizojë dhe drejtojë më së miri njerëzit drejt informacionit që u nevojitet.

2. Përcaktimi i objekteve testuese të përdoruesve

Duke pasur parasysh bazën tashmë të madhe të përdoruesve të faqes, u vendos që fushat më interesante të kërkimit do të ishin normat e goditjeve dhe mbajtja e përdoruesve. Sipas Neil Patel, drejtor i Përgjithshëm QuickSprout, shtimi ose heqja e veçorive mund t'i shtojë vlerë produktit. Bazuar në këto konsiderata, ne vendosëm për pyetjet e nevojshme:

• Çfarë veçorish përdorin njerëzit kur zgjedhin një restorant? (p.sh. foto, vlerësime, etj.)
• A mund të zgjedhin përdoruesit një restorant bazuar në disa kritere specifike?
• A e dinë përdoruesit se si të ruajnë variacionet?
• A mund të zbulojnë nëse një vendndodhje e caktuar është aktualisht e hapur?

3. Përzgjedhja e metodave të testimit

Meqenëse projekti i përshkruar bazohej në sprintet e projektimit, zhvilluesit donin që ai të ishte gjithëpërfshirës, ​​por edhe me kosto efektive. Zgjedhja u bë në favor të testimit të pamoderuar në distancë, i cili përfshinte analiza të llojeve të kartave të filmuara, renditjen e pemëve dhe testimin me klikimin e parë. Me ndihmën e këtyre testeve, ekspertët ishin në gjendje të zbulonin se si pjesëmarrësit e testit e përdorin produktin në jetën e tyre, cilat informacione i japin përparësi dhe cilat veprime janë më të njohurat.

Planifikimi dhe mbledhja e të dhënave cilësore

Testimi i përdorshmërisë në distancë duke përdorur softuer special (për shembull, UserTesting) për të regjistruar ekranin dhe zërin e pjesëmarrësit ju lejon të shihni veprimet e përdoruesit dhe të dëgjoni mendimet e tij ndërsa ai kryen një detyrë specifike.

Për të kryer testimin e përdoruesit, së pari duhet të përcaktoni se cila audiencë i përshtatet qëllimeve tuaja kërkimore.

Në rastin tonë ishte përdoruesit aktualë Yelp, i cili vizitoi këtë faqe herë pas here.

Kriteret e përzgjedhjes si mosha, gjinia, niveli i të ardhurave ose niveli i aftësive në internet nuk ishin të rëndësishme. Për shkak se ky studim u krye vetëm për qëllime të analizës cilësore, studimi nuk kërkonte rëndësi statistikore për të konfirmuar gjetjet. Ata ndoqën praktikat më të mira të industrisë dhe kryen studimin e tyre me 5 përdorues. Më në fund, për të mbajtur të thjeshtë sprintin e dizajnit, ata testuan Yelp vetëm në një kompjuter desktop.

Qëllimi i testimit ishte të zbulohej se si këta përdorues përballen me disa detyra të një natyre të përgjithshme (për të përcaktuar më shumë funksione të rëndësishme) dhe, nga të paktën, me një detyrë më pak të zakonshme (për të zbuluar nëse dinë të përdorin veçori më të avancuara).

Detyrat e përgjithshme përfshinin:

• Detyrë e fokusuar - gjeni një kompani bazuar në parametra specifikë
• Detyrë e hapur - gjeni një kompani me shumë pak direktiva
• Një detyrë shumë specifike - gjeni një vend specifik dhe zbuloni informacion specifik rreth tij

Zhvilluesit ishin të interesuar të zbulonin se si përdoruesit ndërveprojnë me filtrat dhe mbi çfarë baze zgjedhin një kompani të caktuar.

Për detyra më pak të zakonshme, ata siguruan opsione të ndryshme për çdo grup përdoruesish. Për shkak se kishte disa ankesa nga përdoruesit e regjistruar të Yelp në lidhje me veçoritë e Faqerojtësve dhe Listimeve, Yelp u kërkoi përdoruesve të regjistruar (Grupi 1) ta ruanin kompaninë për referencë në të ardhmen. Për përdoruesit pa llogari (grupi 2), detyra ishte të gjenin një ngjarje. Ishte e rëndësishme të shihej nëse do të përdornin funksionin e kërkimit apo jo kur të përfundonin këtë detyrë dhe si do të merrnin një vendim se në cilën ngjarje do të merrnin pjesë.

Në fund të çdo detyre, pjesëmarrësve iu kërkua të shkruanin nëse ishin të suksesshëm në përmbushjen e detyrës dhe të vlerësonin nivelin e vështirësisë ose lehtësinë e përmbushjes së saj.

Pas përzgjedhjes së lëndëve dhe përgatitjes së pyetjeve të testit, u krye testimi i vetë përdoruesit dhe një orë më vonë u morën regjistrimet video për analiza të mëtejshme.

Analiza cilësore e kërkimit të përdoruesve

Pasi të ketë përfunduar hulumtimi, është koha për të analizuar rezultatet dhe për të përcaktuar problemet kryesore që përdoruesit kanë hasur në faqen e internetit Yelp. Dhe ja çfarë zbuluam:

1. Funksioni i kërkimit ishte pikënisja kryesore për çdo detyrë.

Të pesë pjesëmarrësit përdorën shiritin e kërkimit, edhe në detyra ku mund të kishin bërë lehtësisht pa të.

4 nga 5 pjesëmarrësit iu drejtuan menjëherë funksionit të kërkimit për të gjetur një restorant. Vetëm një përdorues filloi të shfletonte kategoritë, të cilat i gjeti menjëherë shumë të papërshtatshme dhe përfundoi duke iu drejtuar edhe shiritit të kërkimit.

2. Skeda Ngjarjet nuk ishte mjaft e spikatur.

Në një detyrë, pjesëmarrësve pa llogari Yelp iu kërkua të gjenin një ngjarje interesante në qytetin e tyre këtë fundjavë që po vjen. Ekspertët donin të dinin nëse do të përdornin skedën Ngjarjet në krye të faqes:

Mjaft e çuditshme, askush nuk përdori skedën Ngjarjet. Një testues shkoi në shiritin e kërkimit, ndërsa një tjetër shkoi në kategorinë Arte dhe Argëtim.

3. Funksioni i faqerojtësve doli të ishte i paqartë dhe askush nuk përdori lista.

Zhvilluesit donin të zbulonin se cilën metodë do të zgjidhnin përdoruesit për të kursyer hapësirë ​​për referencë të mëvonshme. Ka dy mënyra për ta bërë këtë në Yelp: shënoni vendin ose krijoni një listë.

Nga tre pjesëmarrësit:

• Njëri përdori faqerojtësit për të shpëtuar kompanitë, por u ankua se procesi zgjati shumë.
• Njëri filloi të kursente kompanitë duke përdorur faqeshënuesit, por ndaloi për të njëjtën arsye si përdoruesi i mësipërm.
• Një përdorues nuk e kuptoi fare se si të ruante kompanitë në sit dhe e braktisi detyrën.

Dy pjesëmarrës që përdorën faqerojtësit thanë se do të ishte mirë të mund ta bënin këtë edhe nga faqja e rezultateve të kërkimit në vend të
për të shkuar në faqen e secilës kompani për këtë qëllim.

4. Gjetja e një lokacioni specifik doli të ishte një detyrë shumë e shpejtë dhe e lehtë.

Të pesë përdoruesit që kishin për detyrë të gjenin një vendndodhje specifike dhe të zbulonin nëse ai ishte aktualisht i hapur, e përfunduan me sukses dhe e vlerësuan si shumë të lehtë.

5. Përdoruesit përdorën fotografi për të përcaktuar atmosferën e restorantit.

Kur iu kërkua të gjente një restorant me një atmosferë të caktuar, asnjë nga pesë pjesëmarrësit nuk u përpoq të përdorte shiritin e kërkimit. Në vend të kësaj, tre shikuan fotot e restorantit në Yelp, njëri vizitoi uebsajtin e restorantit dhe i fundit mendoi se simbolet e kostos ($,$$,$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$) njërin një vizitoi një vizitoi një vizitoi një vizitoi faqen e restorantit një vizitoi një vizitoi fotot e restorantit, njëri vizitoi ambientin e duhur.

6. Filtrat u përdorën nga pjesëmarrësit, por mund të përmirësoheshin.

Në një detyrë për të gjetur një restorant për një grup prej 15 personash, tre nga pesë pjesëmarrësit përdorën filtrin "I përshtatshëm për grupe të mëdha", një tjetër përdori funksionin "Libër" dhe më pas lëvizi poshtë faqen e rezultateve derisa gjetën një restorant që përputhej. kërkesën.

Përdoruesi i fundit u përpoq të zgjidhte dy kategori për të filtruar rezultatet, por kur klikoi në njërën prej opsioneve, e dyta u zhduk në atë moment.

Kur pjesëmarrësit kërkuan për një restorant duke përdorur parametra të caktuar, një nga kërkesat ishte gjetja e një restoranti brenda 20 dollarëve/person. Dy nga pesë përdorues ishin të hutuar nëse një restorant me këtë buxhet duhet të klasifikohet në kategorinë $, $$, ose $$$. Njëri prej tyre tha se nuk e dinte se çfarë kuptimi kishin simbolet dhe tjetri zgjodhi kategorinë e gabuar. Tre përdoruesit e mbetur zgjodhën saktë kategorinë $$.

Kuptimi i simboleve nuk shfaqet gjatë zgjedhjes së filtrit, por vetëm kur një person shkon në faqen e një restoranti të caktuar. Meqenëse pritjet e çmimeve janë shumë subjektive, ishte e paqartë për pjesëmarrësit se cilën kategori duhet të zgjidhnin.

Mbledhja e të dhënave sasiore rreth sjelljes së përdoruesit

Goli i radhës ishte më shumë analiza e detajuar. Për ta bërë këtë, ekspertët kryen testimin dhe testimin e klikimit të parë me karta të mbyllura.

1. Renditja me karta vrima duke përdorur mjetin OptimalSort.

Renditja me karta të mbyllura përfshin dhënien e pjesëmarrësve karta që përmbajnë emra, të cilët pjesëmarrësit më pas duhet t'i përputhen me kategoritë ekzistuese (në krahasim me klasifikimin me karta të hapura, ku përdoruesit duhet të krijojnë vetë kategoritë). Kur emërtoni kartat, duhet t'i përmbaheni parimit "sa më e thjeshtë aq më mirë". Disa udhëzime që vlejnë për klasifikimin me fytyrë lart dhe me fytyrë lart:

• Nuk duhet të përzieni kategoritë e prindërve dhe fëmijëve. Me fjalë të tjera, përdorni kategori të të njëjtit nivel, përndryshe do t'i ngatërroni pjesëmarrësit.
• Siguroni formularë të hapur për reagime shtesë pas testimit.
• Mbani në mend se ndonjëherë përdoruesit nuk i grupojnë të dhënat. Mungesa e një grupimi mund të jetë po aq informuese sa prania e tij. Në këtë rast, sigurohuni që të pyesni pjesëmarrësin pse.

Renditja e kartave të përdorura në testin e përshkruar kishte tre qëllime të thjeshta:

• Përcaktoni se sa shpesh përdorin njerëzit filtrat e kërkimit në Yelp
• Përcaktoni se cilët filtra janë më të rëndësishëm
• Përcaktoni se cilët filtra janë më pak të rëndësishëm

Në total, zhvilluesit kishin 47 harta që tregonin të 47 filtrat e kërkimit Yelp (çmimi, distanca, etj.). Më pas pjesëmarrësve iu kërkua t'i renditnin ato në kategori me rëndësi: "shumë e rëndësishme", "disi e rëndësishme", "jo e rëndësishme" dhe "Nuk e di se për çfarë shërben ky filtër":

2. Testimi i klikimit të parë duke përdorur veglën Chalkmark

Ky testim kap zonën e faqes ku përdoruesi klikon për të përfunduar detyrë specifike. Këtu janë disa këshilla për ta bërë atë:

1. Shkruani qartë detyrat. Sigurohuni që pjesëmarrësi është duke menduar se si ta zgjidhë problemin, jo vetëm se ku të klikojë.
2. Përcaktoni mënyra më të mira për të përfunduar detyrën. Duke filluar me faqja kryesore, ndërto gjithçka mënyrat e mundshme për të arritur çdo qëllim.
3. Lini mënjanë një kohë specifike për të përfunduar detyrat.

Ky testim duhet të ketë:

• Përcaktoni nëse arkitektura e informacionit ju lejon të përfundoni shpejt një detyrë
• Përcaktoni nëse shkurtoret e navigimit janë të qarta

Studiuesit u kërkuan përdoruesve të kryenin detyra të caktuara, duke u ofruar atyre pamje nga ekranet e faqeve Yelp. Më pas ata analizuan rezultatet (hartën e nxehtësisë) dhe sa shpejt pjesëmarrësit i përfunduan këto detyra.

Analiza sasiore e hulumtimit të përdoruesve

Pas analizës cilësore, të dhënat nga dy sondazhe me sensorë në distancë u analizuan duke përdorur mjetin Optimal Workshop.

1. Rezultatet e testimit të filtrave të kërkimit në Yelp duke përdorur klasifikimin e kartave të mbyllura

92.5% e pjesëmarrësve thanë se përdorin rregullisht filtrat e kërkimit të faqes.

Filtrat më të rëndësishëm për përdoruesit ishin "Hap Tani", "Pranimi". kartat e kreditit" dhe "Oferta speciale".

Më shumë se 88% e pjesëmarrësve vendosën se 7 filtrat nuk ishin aspak të rëndësishëm.

Si rezultat i këtij hulumtimi, u identifikuan tre qëllime kryesore për ridizajnimin e faqes kryesore të Yelp:

• Bëjini filtrat më të njohur të kërkimit më të dukshëm.
• Hiqni filtrat e papërdorur të kërkimit ose ridizajnoni ato në mënyrë që filtrat më të zakonshëm të kenë përparësi dhe filtrat më pak të zakonshëm të jenë lehtësisht të aksesueshëm.
• Renditni kartat e mbyllura në kategoritë ekzistuese për të përcaktuar se cilët filtra duhet të futen në secilën kategori sipas përdoruesve. Nëse zbulohen mosmarrëveshje të mëdha midis pjesëmarrësve, arkitektura e informacionit do të duhet të rindërtohet.

Faqja kryesore Yelp Klikoni së pari në rezultatet e testit

2. 30% e pjesëmarrësve e gjetën faqen "të mbushur me njerëz" ose "konfuze".

Harta e nxehtësisë tregoi ndryshime të rëndësishme në vendin ku klikuan përdoruesit. Pjesëmarrësve iu kërkua të gjenin një restorant me çmim të arsyeshëm që mund të strehonte deri në 20 persona. Përfundimi i detyrës zgjati mesatarisht 15 sekonda - që është shumë në kushtet e internetit. Në imazhin e mëposhtëm, mund të shihni se 55% kanë klikuar në artikullin e menusë "Restorantet" në këndin e sipërm djathtas. Pjesa e mbetur prej 45% klikoi në vende krejtësisht të ndryshme. Të kesh përgjigje të mundshme në shumë vende në një faqe rrit ngarkesën njohëse të përdoruesve dhe gjasat e një klikimi të parë të pasaktë:

24% e pjesëmarrësve përdorën shiritin e kërkimit kur kërkonin një mekanik në qytetin e tyre (një nga detyrat). Shumica e pjesëmarrësve lundruan në kategoritë e shërbimeve të vendosura në anën e majtë të faqes. Por veprimi i dytë më i popullarizuar ishte ende përdorimi i shiritit të kërkimit.

Skeda Ngjarjet mashtronte përdoruesit kur iu kërkua të mësonin më shumë rreth një festivali të ardhshëm në qytetin e tyre. Skeda e ngjarjeve në paneli i sipërm navigimi i çon njerëzit në një faqe me ngjarjet kryesore (jo ato që kanë zgjedhur). Për të parë ngjarjet që planifikojnë të marrin pjesë, ata duhet të klikojnë në skedën e poshtme "Ngjarjet".

Si rezultat, 37% e njerëzve i injoruan të dyja këto skeda dhe shkuan direkt në shiritin e kërkimit. 37% e njerëzve klikuan në skedën e dëshiruar Ngjarjet. 18% klikuan në një skedë të vendosur në shiritin kryesor të navigimit.

Bazuar në të dhënat sasiore të marra, u identifikuan detyrat e mëposhtme për ridizajnimin:

• Zvogëloni rrëmujën në faqe për ta bërë më të lehtë për përdoruesit të perceptojnë informacionin dhe të veprojnë.
• Krijoni emra të qartë, të paqartë të skedave dhe hiqni ato të paqarta që i çojnë përdoruesit në rrugë të gabuara.
• Kryeni një lloj harte të hapur të përmbajtjes kryesore për të përcaktuar se si përdoruesit mendojnë se informacioni duhet të organizohet dhe si do t'i emërtojnë kategoritë.
• Bëje më të dukshme skedën Ngjarjet.
• Ridizajnoni pamjen "Llogaria" në mënyrë që të mos ketë konfuzion midis menysë kryesore të faqes dhe menysë së llogarisë.

Dizajni dhe përsëritja me në qendër përdoruesin

Pasi të përfundojë analiza e të dhënave të përdoruesit, mund të filloni të krijoni dhe ripunoni dizajnin.

Jakob Nielsen, bashkëthemelues i Nielsen Norman Group, klasifikon shumicën e proceseve të projektimit që përfshijnë testimin e përdorshmërisë në dy kategori: dizajn përsëritës dhe dizajn paralel.

Në një proces përsëritës, ne thjesht kalojmë nga një version i dizajnit në tjetrin bazuar në atë që zbulojmë nga testimi i përdorshmërisë. Çdo shigjetë në grafikun e mëposhtëm përfaqëson një raund testimi dhe analize:

1 kornizë teli, përsëritje të shumëfishta → letër/kornizë ndërvepruese, përsëritje të shumëfishta → dizajne vizuale, përsëritje të shumëfishta

Me këtë proces, rekomandohet të paktën dy përsëritje për çdo skicë, kornizë teli dhe paraqitje. Sigurisht, ky proces mund të zgjerohet në varësi të madhësisë dhe kompleksitetit, dhe ju lehtë mund të krijoni 5-10 përsëritje për secilën fazë.

Ky proces projektimi thekson të menduarit krijues që herët. Versione të shumta të një dizajni që janë paksa të ndryshëm nga njëri-tjetri për sa i përket paraqitjes janë të preferueshme sesa përsëritjet.

3 dizajne të ndryshme të bëra në të njëjtën kohë → Testimi i përdoruesit (lidhur idetë më të mira dizajn) → 1 dizajn → Procesi i projektimit përsëritës

Një raund i madh i testimit të përdoruesve rezulton në një dizajn të unifikuar. Për ta përmirësuar më tej, është mirë të përdoret një proces përsëritës, në të cilin ndryshimet e vogla testohen në grupe të vogla prej 5-10 përdoruesish derisa dizajni të jetë përfundimtar.

Procesi i ridizajnimit Yelp i përshkruar ishte në thelb një proces paralel në lidhje me testimin UX të kryer që në fillim. Meqenëse ky ishte vetëm një ridizajn hipotetik, zhvilluesit u ndalën pas dizajnit të hapit 1. Nëse ky do të ishte një ridizajn i vërtetë, hapi tjeter do të ishte kryerja e testimeve të mëtejshme për të përmirësuar prototipin.

Skicimi

Për ridizajnimin e Yelp, skicimi ishte hapi i parë në ridizajnimin e faqes kryesore të Yelp dhe faqes së rezultateve të kërkimit.

Dizajni i faqes fillestare të Yelp mori dy përsëritje, me ekipin që u fokusua vetëm në strukturë.

Skica është bërë duke marrë parasysh disa nga çështjet kryesore të përdorshmërisë të identifikuara gjatë testimit të faqes kryesore:

• Rrit dukshmërinë e shiritit të kërkimit
• Bëje më të dukshme skedën Ngjarjet
• Optimizoni kategoritë

Përveç kësaj, u shtua një fund dhe "Rishikimi i ditës" u zhvendos nga ana e djathtë e faqes në fund.

2. Faqja e Rezultateve të Kërkimit Yelp

Për shkak se faqja e rezultateve përmban më pak larmi informacioni në krahasim me faqen kryesore, u desh vetëm një përsëritje për të skicuar dizajnin e ri.

Pikat e mëposhtme janë marrë parasysh në këtë skicë:

• Fotot duhet të jenë më të dukshme
• Përcaktoni kategoritë e çmimeve

Krijimi i një kornize teli

Ka mjaft debate në lidhje me kornizat me besueshmëri të ulët dhe të lartë. Zhvilluesit zgjodhën të parën sepse donin të fokusoheshin vetëm në strukturën në këtë fazë.

Duke pasur parasysh kompleksitetin e faqes aktuale fillestare të Yelp, u deshën 4 përsëritje. Përveç rregullimit të çështjeve të përdorshmërisë, ata gjithashtu donin të ruanin
Aspektet e SEO (për shembull, një listë e qyteteve të tjera). Më poshtë do të përqendrohemi në përsëritjen më të fundit.

• Përmirësimet e shiritit të kërkimit

Dizajni aktual:

Shiriti i kërkimit është në krye të faqes.

Korniza e modifikuar:

Zhvilluesit kanë shtuar më shumë saktësi dhe gjithashtu kanë ofruar hapësirë ​​të lirë rreth panelit për ta bërë atë të dallohet më shumë. Meqenëse shkrimi i komenteve është një ndërveprim kyç për Yelp, ata shtuan gjithashtu një buton "Shkruaj një koment" në këndin e sipërm majtas.

• Optimizoni listën e kategorive

Dizajni aktual:

Korniza e modifikuar:

Dizajni i ri është më vizual dhe paraqet vetëm 8 kategori në të njëjtën kohë. Për të parë më shumë, përdoruesit thjesht klikojnë në butonin "Më shumë kompani", i cili është zhvendosur më pranë ⅓ e sipërme e faqes për një theks më të fortë vizual.

• Bëni më të lehtë gjetjen e skedës Ngjarjet

Dizajni aktual:

"Ngjarjet" ose fshihen në këndin e djathtë në shiritin e sipërm të navigimit (nuk tregohet këtu) ose shtyhen në një shirit anësor në mes të rrotullës.

Korniza e modifikuar:

Struktura e ndryshuar vendos "Ngjarjet" në qendër të rrotullës. Mund të futni një veçori Foto në të majtë të tekstit ose të shtoni një video që luhet në sfond.

• Reduktimi i Kaosit të Përgjithshëm

Dizajni aktual:

Korniza e modifikuar:

Çdo element dytësor si "Ngjarjet popullore" ose "Listat" (të cilat asnjëherë nuk janë përdorur as në testimin e përdorshmërisë) u zhvendosën në fund.

2. Faqet e rezultateve të kërkimit Yelp

Për shkak se faqet e rezultateve të kërkimit ishin më pak komplekse, ridizajnimi kërkonte vetëm dy përsëritje. Më poshtë do të përqendrohemi në përsëritjen më të fundit.

Dizajni aktual:

Filtrave dhe renditjes së Yelp nuk ka hierarki.

Korniza e modifikuar:

Korniza e re nxjerr në pah filtrat më të rëndësishëm dhe riorganizon të gjithë zonën në katrorë. Çdo kategori filtri përfshin vetëm katër opsione, të cilat japin rend vizual. Meqenëse 90% e përdoruesve e panë filtrin "Hap Tani" të rëndësishëm, zhvilluesit e theksuan atë si element i veçantë. Çmimet sqarohen me vargjet e dollarit dhe 7 filtra të parëndësishëm janë fshehur.

• Paraqitja e përmirësuar e rezultateve të kërkimit

Dizajni aktual:

Shumica e përdoruesve u mbështetën në foto për të përcaktuar atmosferën e një vendi, por ikonat e imazhit në listime ishin shumë të vogla. Nuk ka gjithashtu asnjë mënyrë për të ruajtur një kompani si një faqerojtës..

Korniza e modifikuar:

Ne kemi zmadhuar miniaturën dhe kemi zhvendosur butonin "Ruaj për më vonë" në krye për shënime të lehta. U ndryshua edhe faqosja dhe u ndanë adresa dhe numri i telefonit.

Prototipi: saktësi e ulët dhe e lartë

Ndërsa korniza teli ka të bëjë me strukturën, prototipizim ka të bëjë me përvojën. Prototipi mund të ketë gjithashtu besueshmëri të ulët ose të lartë.

1. Prototipi me besnikëri të ulët

Për shkak se këto prototipa janë në thelb të papërfunduara, njerëzit ofrojnë reagime më objektive për veçoritë bazë dhe dizajnin e përgjithshëm.

Zhvilluesit nga UXPin, UserTesting dhe Optimal Workshop donin të ishin në gjendje të shfletonin kategoritë, të zgjidhnin filtrat dhe të kalonin midis faqja kryesore dhe faqja e rezultateve të kërkimit ishte një përvojë e qetë për pjesëmarrësit. Nëse ky do të ishte një ridizajn i vërtetë, hapi i tyre i ardhshëm do të ishte testimi i këtij prototipi nga përdoruesi dhe më pas përsëritja përsëri.

2. Prototipi me saktësi të lartë

Prototipi me besnikëri të lartë është ideal për fazat e mëvonshme të dizajnit dhe përsëritja mbulon gjëra të tilla si pamja, marka dhe detaje të tjera.

Ekspertët shtuan saktësi duke përdorur bibliotekën e tyre të elementeve të ndërfaqes së përdoruesit. Ajo që nuk mund të bëhej në shfletues u krijua në Photoshop ose Sketch dhe më pas u importua drejtpërdrejt në UXPin duke përdorur drag & drop. Shtresat u ruajtën, kështu që ishte vetëm një çështje për të klikuar mbi elementë dhe për të shtuar ndërveprime.

Përsëri, nëse ky do të ishte një ridizajn i vërtetë, ekipi do të testonte prototipin e ri në të njëjtat detyra dhe do të përsëriste sipas nevojës.

konkluzioni

Sfida më e madhe me të cilën përballen dizajnerët dhe menaxherët e produkteve nuk është mënyra se si funksionon tregu apo teknologjitë e ndryshme, por si sillen njerëzit. Ajo që përdoruesit thonë dhe çfarë bëjnë ata janë dy gjëra krejtësisht të ndryshme, dhe mënyra e vetme për ta verifikuar këtë është testimi.

Testimi i përdorshmërisë është më shumë se një shënim në listën e kërkesave. Kjo është arsyeja më bindëse për të zgjidhjet e projektimit. Në fund të fundit, nëse nuk po dizajnoni për përdoruesit, atëherë po dizajnoni vetëm për veten tuaj.

Nga rruga, dizajni i faqes së internetit Yelp të përshkruar në këtë artikull ka pësuar disa ndryshime dhe tani duket kështu:

Është e mundur që zhvilluesit e tij kanë përdorur parimet e listuara më sipër për të arritur një rezultat që të kujton disi atë të arritur nga specialistët nga UXPin, UserTesting dhe Optimal Workshop

Testimi i përdorshmërisë do të tregojë se sa i përshtatshëm është që përdoruesi të gjejë informacion dhe të kryejë veprime në sit. Kjo ju lejon të kuptoni në gjysmë të rrugës se çfarë të bëni më pas - lini dizajnin të njëjtë ose modifikoni atë.

Gabimi më i vogël mund të dështojë në test. Në këtë artikull, do të mësoni se çfarë duhet të keni parasysh në çdo fazë të testimit.

Ajo që është e rëndësishme

Çdo test është unik në qëllim dhe objektiva. Sidoqoftë, ka pika të përgjithshme që duhen sqaruar që në fillim:

• Ku të fillojë?
• Në cilat faza duhet të kaloni?
• Si të mos humbisni detaje të rëndësishme?
• Cilat gracka do të duhet të kapërceni?
• Si të merrni të dhëna të vlefshme dhe domethënëse?

Algoritmi i mëposhtëm do të ndihmojë me planifikimin.

Hapi 1: Përcaktoni qëllimin tuaj

Formuloni një rezultat të qartë të studimit dhe vendosni se cilat të dhëna mblidhen më mirë për këtë.

Testi mund të përfshijë pyetje të përgjithshme:

• Cili navigacion përmirëson përvojën e përdoruesit?
• Si ndërveprojnë vizitorët me aplikacionin/faqen?

Ose ato specifike:

• Çfarë i pengon përdoruesit të ndërmarrin veprimet e synuara në faqe?
• Çfarë ju tërheq vëmendjen kur bëni një porosi?

Megjithatë, sa më shumë pyetje në programin e kërkimit, aq më e gjerë është fusha për gabime në interpretim. Pyetni vetëm atë që ju ndihmon të arrini qëllimin tuaj.

Hapi 2: Tërhiqni pjesëmarrësit e duhur

Këta janë vizitorët e faqes dhe përdoruesit e synuar.

Zbuloni se kush po përdor sistemin aktual dhe vendosni se cilët klientë të mundshëm po synoni.

Përcaktoni numrin e pjesëmarrësve. Zakonisht nga 3 në 8. Sa më shumë të ketë, aq më shumë gabime të përdorshmërisë mund të identifikohen. Kjo është se si duket varësia:

Hapi 3: Zgjidhni një format

Testimi i përdorshmërisë personale

Është mirë sepse ju lejon të lexoni gjuhën e trupit dhe të vlerësoni sjelljen e njerëzve në jetën reale.

• Vëzhguesi i heshtur: Ju qëndroni pranë përdoruesve, nuk ndërveproni me ta, por analizoni sjelljen e tyre dhe mënyrën se si ata përballen me detyrat.
• Metoda e mendimit me zë të lartë: pjesëmarrësit përshkruajnë gjithçka që bëjnë dhe mendojnë ndërsa shkojnë. Kjo jep një vizion të qartë të asaj që përafërsisht po ndodh në mendjet e vizitorëve.
• Metoda e ndërveprimit sinergjik: dy përdorues kryejnë detyra së bashku dhe ndihmojnë njëri-tjetrin. Ju nuk u jepni atyre asnjë sugjerim dhe vlerësoni se si i kapërcejnë vështirësitë kur punojnë me sitin.

Testimi i përdorshmërisë në distancë

Kjo është një alternativë ndaj testimit personal që ju kursen kohë dhe para. Përdoruesit kryejnë detyrat ku dhe si është e përshtatshme për ta.

• Moderuar: Ju ndërveproni me një pjesëmarrës në internet.
• I pamoderuar: Nuk mund t'i bëni pyetje ose të ndërhyni në asnjë mënyrë.

Hapi 4: Formuloni objektivat/skenarët

Këtu janë dy lloje të detyrave:

• E hapur/eksploruese: Zakonisht më eksploruese dhe eksploruese. Ky lloj kërkon më shumë se një përgjigje dhe përgjigjet ndryshojnë nga përdoruesi në përdorues. Ju u jepni pjesëmarrësve një minimum informacioni rreth ekzekutimit.
• E mbyllur/Specifike: Më e ngushtë dhe e orientuar drejt qëllimit. Ato kufizojnë qëllimin e studimit dhe prodhojnë rezultate më të sakta.

Është e rëndësishme të gjesh një terren të mesëm. Si ta bëjmë atë?

Kërkesat e detyrës

• Detyrë ≠ pyetje

Pse? Nuk ka asnjë përfitim nga bërja e pyetjeve me përgjigje të parashikueshme ose të çmendura.

• Formulimi specifik

Mos i lini përdoruesit të pyesin se çfarë të bëjnë ose cili është hapi tjetër.

Në të njëjtën kohë, mos u përqendroni në detajet më të vogla dhe të parëndësishme, mbuloni vetëm ato aspekte të sistemit që janë të rëndësishme për ju.

• Shmangni udhëzimet

Gjithashtu nuk ka nevojë të shkoni në ekstremin tjetër dhe të jepni udhëzime se si të kaloni saktë testin. Në vend të rezultateve të besueshme, do të merrni atë që prisni vetë, dhe atëherë cili është kuptimi i testimit?

• Krijoni kushte afër atyre reale

Në këtë mënyrë ju do të merrni një mendim të sinqertë nga përdoruesit për sistemin: çfarë mendojnë ata, si i kapërcejnë vështirësitë dhe çfarë përfundimisht del prej tij.

Hapi 5: Krijoni pyetësorë

Ekzistojnë dy lloje kryesore të pyetësorëve të testit të përdorshmërisë.

Para-pyetësorë

Sa shpesh blini online?

• Asnjëherë;
• Blerë 1-2 herë vitin e kaluar;
• Rreth 3-7 herë në vit;
• Rregullisht (specifikoni sa shpesh).

Ju vlerësoni se si të angazhoni në mënyrë më efektive audiencën tuaj të synuar dhe nga çfarë varet kjo.

Pyetësorë pas testimit

Këto pyetje ndihmojnë për të kuptuar përshtypjet e pjesëmarrësve për testin. Kërkojini atij t'ju tregojë nëse ishte e lehtë apo e vështirë për të të përdorte sistemin, nëse kjo përvojë e frymëzoi apo e zhgënjeu.

Si ju pëlqen aplikacioni?

• Lehtë për t'u përdorur;
• Vështirë për t'u përdorur.

Ju lutem shpjegoni pse mendoni kështu? (pyetje e hapur).

Hapi 6: Bëni një provë

"Përsëritja" e studimit ndihmon në vlerësimin e gatishmërisë dhe identifikimin dhe zgjidhjen e hershme të problemeve.

Një test pilot do t'ju tregojë se sa kohë duhet të ndani për secilën detyrë. Nëse ka shumë, renditni sipas rëndësisë dhe lidhjes me qëllimin kryesor.

Provojeni vetë ose kërkoni nga kolegët tuaj që të bëjnë testin së pari. Një ose dy pjesëmarrës në provë është më se i mjaftueshëm për të kapur gabimet dhe për t'u përgatitur për eksperimentin e vërtetë.

Nëse një pilot është i suksesshëm, ai gjithashtu prodhon zbulime të dobishme dhe ndonjëherë të papritura.

E rëndësishme! Tërhiqni përdorues që nuk janë të njohur me të gjitha nuancat e sistemit që po testoni.

Hapi 7: Regjistroni rezultatet

Nuk ka asnjë metodë universale për analizën e të dhënave. Zgjidhni atë që funksionon për ju.

Përmblidhni vështirësitë që hasën përdoruesit dhe nxirrni përfundime. Ju mund t'i kategorizoni problemet dhe t'i renditni ato sipas ashpërsisë ose rëndësisë. Përcaktoni se për cilat ia vlen të punoni së pari dhe cilat të hiqni nga lista.

Rasti: testi i përdorshmërisë në veprim

Qëllimi: përgjigjuni pyetjeve dhe ndryshoni seksionet e nevojshme website:

• A është e lehtë të gjesh një produkt specifik në një faqe?
• Sa e lehtë është ta krijosh sipas dëshirës dhe ta shtosh në shportë?