Igor Gubaidulin

... arba dar kartą apie amžiną temą: kas geriau – tinkamumo ekspertų nuomonė ar realių vartotojų testas.

Šiuo klausimu tenka diskutuoti stebėtinai dažnai ir daug. Jis yra vienas dažniausiai užduodamų klausimų mūsų vartotojų testavimo mokymų metu, todėl nusprendėme dar kartą apžvelgti už ir prieš argumentus.

Viena nuomonių stovykla teigia, kad tinkamumo testavimas (angl. usability testing) yra nereikalingas, jei svetainę, programą ar kitą sistemą įvertino ir parašė rekomendacijas tinkamumo srities specialistas. Šią nuomonę bandoma pagrįsti tuo, kad žmonės yra pakankamai lengvai nuspėjami, todėl savo srities specialistas turėtų pastebėti ir įvertinti tinkamumo problemas. Tai tiesa, bet tik iš dalies.

Alternatyvios nuomonės gynėjai teigia, kad ekspertas, atsižvelgiant į savo patirtį, gerąsias praktikas ar tinkamumo rekomendacijas, pastebės pagrindines tinkamumo problemas. Tačiau praktika rodo, kad beveik visada vartotojų testavimų metu randamos problemos, kurios sukelia nuostabą net patyrusiems specialistams. Tai vyksta dėl paprastos priežasties. Kokie nuspėjami mes beatrodytume iš pirmo žvilgsnio, iš prigimties esame iracionalūs (iš Dan Ariely ir Jonah Lehrer knygų) ir dažnai net nežinome koks bus mūsų elgesys tam tikroje situacijoje (Malcolm Gladwell) kol joje neatsiduriame. Dažniausiai ekspertai nėra tikrieji svetainės vartotojai ir vartotojų elgesį prognozuoja remdamiesi tuo, kaip patys suvoka tiriamos sistemos veikimo modelį. Todėl realybė ir specialistų įsivaizdavimas, kaip vartotojai naudojasi sistema, gali stipriai skirtis.

Kas yra kas?

Tinkamumo revizija – tai sąlyginai greitas sistemos tinkamumo gerinimo būdas. Dažnai analizei ir pastebėjimų/rekomendacijų rašymui užtenka ne dienų, o valandų. Tokios tinkamumo revizijos metu bus rastos akivaizdžios, tipiškos problemos. Be to, anot Jim Ross, tinkamumo revizija gali būti naudinga dar ir dėl to, kad jos metu rastų tinkamumo klaidų spektras yra platesnis (nes tikslingai ir detaliai peržiūrima daugiau naudotojo sąsajos dalių negu vartotojų testavimo metu). Daugiausiai kritikos šis metodas susilaukia dėl rekomendacijų subjektyvumo, priklausomybės nuo eksperto kvalifikacijos bei sugebėjimo (arba tiksliau to sugebėjimo trūkumo) įsijausti į tikslinio vartotojo situaciją ir tikėtiną naudojimo scenarijų.

Tinkamumo testavimas - dažnai laikomas tikslesniu metodu, nes suteikia tikrų vartotojų testu pagrįstą informaciją. T.y. remiamasi ne eksperto nuomone, o tuo kaip su sistema dirbti sekasi realiems sistemos vartotojams. Tik nepainiokime šio tyrimo būdo su fokus grupėmis - standartinis tinkamumo testavimas yra atliekamas atskirai su kiekvienu vartotoju, o ne jų grupe. Anksčiau šis metodas daugiausiai buvo kritikuojamas dėl laiko ir kaštų. Tačiau neapsigaukite, šiais laikais tinkamumo testavimas gali būti ne tik organizuojamas tyrimų laboratorijoje, bet ir nuotolinis (pvz. naudojant tokius įrankius kaip Usabilla), o tai jau nereikalauja tokių didelių laiko ir pinigų resursų kaip anksčiau.

Kas geriau?

Atsakydami į klausimą ar reikia iš viso testuoti vartotojus, mes pritariame nuomonei "kaip galima iš viso kalbėti apie į vartotoją orientuotą dizainą (angl. user centered design) be pačių vartotojų?". Tačiau neneigiame ir ekspertinės peržiūros naudos. Dilemos prasideda kaip norima pasirinkti tik vieną iš metodų pagal tai, kuris iš jų yra geresnis. Tokiu atveju vieno universalaus atsakymo į "Kas geriau?" klausimą nebūna.

Taip pat reikėtų nepamiršti, kad tinkamumo tyrimų sritis toli pažengė per praėjusius porą dešimtmečių. Dabar labiausiai vertinamas ne gebėjimas nustatyti, kuris metodas geresnis, o gebėjimas jungti skirtingus tyrimo metodus ir kurti lanksčius tyrimo planus pritaikytus kiekvienai specifinei situacijai. Todėl ir tinkamumo revizija su tinkamumo testavimu nebėra tarpusavyje nesuderinami. Pavyzdžiui, ruošiantis testavimui, ekspertai atsakingi už testavimo scenarijaus paruošimą vis tiek turi peržiūrėti sistemą, o tai jau didelė dalis tinkamumo revizijos. Jei tokios revizijos metu bus rastos akivaizdžios problemos ir iš karto pataisytos, testuojant vartotojus bus galima susikoncentruoti ties kitais klausimais, į kuriuos ekspertas be tikrų vartotojų testo negalėtų vienareikšmiškai atsakyti.

Tinkamumo revizija ir tinkamumo testavimas abu yra naudingi ir kartu leidžia identifikuoti didžiausią įmanomą taisytinų aspektų kiekį. Bandymas griežtai pasirinkti tik vieną iš metodų reikalauja kompromisų - kažko tenka atsisakyti, o ko būtent geriau atsisakyti nuspręsti galima tik pagal situacijos specifiką, pvz. kiek turima laiko, biudžeto, kokioje stadijoje yra projektas, kaip greitai reikalingi rezultatai, ką norima sužinoti apie sistemą, kokias funkcijas reikai patikrinti ir t.t.

Įrašas parašytas kartu su Ramune Norkute į Idea Code įmonės tinklaraštį.