UX audito sąrašas: kaip rasti svetainės naudojimo problemas ir nustatyti prioritetus

Svetainė gali atrodyti puikiai ir vis tiek versti žmogų per daug stengtis. Reikalinga paslauga slepiasi po neaiškiu meniu pavadinimu. Forma atmeta atsakymą, bet nepaaiškina kodėl. Kitas žingsnis jūsų komandai akivaizdus, tačiau pirmą kartą apsilankiusiam žmogui — ne.

UX audito sąrašas padeda tokius momentus patikrinti nuosekliai. Pradėkite nuo užduočių, kurias žmonės ateina atlikti jūsų svetainėje. Užfiksuokite, kas jiems trukdo, ir nustatykite problemų prioritetus pagal poveikį naudotojams bei verslui.

Rezultatas turėtų būti sprendimai, kuriais galima remtis: ką taisyti, ką dar išsiaiškinti ir kaip patikrinti, ar pakeitimai padėjo.

Ką gali atskleisti UX auditas

UX auditas — nuoseklus vertinimas, kaip gerai svetainė padeda ja besinaudojantiems žmonėms. Priklausomai nuo turimų duomenų, jame galima derinti specialisto peržiūrą, analitiką, klientų aptarnavimo informaciją ir naudojamumo tyrimus.

Šie šaltiniai atsako į skirtingus klausimus. Analitika gali parodyti, kuriame žingsnyje žmonės pasitraukia. Žinutė klientų aptarnavimo komandai — pasikartojantį nesusipratimą. Stebėjimas, kaip žmogus atlieka užduotį, gali padėti suprasti, kas ją apsunkina.

Specialisto peržiūra padeda pastebėti tikėtinas problemas, bet neįrodo, kaip elgiasi jūsų auditorija. „Nielsen Norman Group“ taip pat pabrėžia šį skirtumą: heuristinis vertinimas papildo naudotojų tyrimus, o jų nepakeičia. Daugiau apie heuristinį vertinimą.

Aiškiai įvardykite, ką tikrinote ir ko dar nežinote. Vien užklausos pateikimo kelio peržiūros nereikėtų pristatyti kaip visos svetainės įvertinimo.

Kaip atlikti UX auditą: pradėkite nuo užduoties

Pasirinkite naudotojo tikslą ir susiekite jį su verslo tikslu. Pavyzdžiui, potencialiam klientui reikia suprasti, ar siūlote tinkamą paslaugą, o jūsų verslui reikia aktualių užklausų.

Tuomet suformuluokite realistišką užduotį: „Raskite jūsų projektui tinkamą paslaugą, išsiaiškinkite, kas į ją įeina, ir užduokite komandai klausimą.“ Instrukcijoje neišduokite, kurį meniu ar mygtuką rinktis. Norite įvertinti, ar pats kelias suprantamas.

Prieš pradėdami sutarkite dėl:

• Apimties: kokius kelius, puslapių tipus ir būsenas tikrinsite.
• Konteksto: aktualių įrenginių, naršyklių, kalbų ir prisijungusio ar neprisijungusio naudotojo būsenų.
• Įrodymų: analitikos, paieškos užklausų, klientų atsiliepimų ar ankstesnių tyrimų, prie kurių iš tiesų turite prieigą.
• Sėkmės: kaip atrodo sėkmingai atlikta užduotis, įskaitant patvirtinimą po veiksmo.

Veiksmams, kurie sukurtų tikrus užsakymus ar užklausas, naudokite testavimo aplinką. Jei kurio nors žingsnio negalite patikrinti, užfiksuokite šį apribojimą, užuot pažymėję, kad viskas veikia.

Svetainės UX audito sąrašas

Prie kiekvieno punkto pažymėkite: tvarkinga, yra problema, netikrinta arba netaikoma. „Tvarkinga“ reiškia, kad problema neaptikta jūsų tikrintomis sąlygomis, o ne garantiją kiekvienam lankytojui.

1. Paskirtis ir kitas žingsnis

• Ar pirmą kartą apsilankęs žmogus supranta, kas siūloma ir kam tai skirta?
• Ar pagrindinė antraštė pasako ką nors konkretaus, užuot apsiribojusi šūkiu?
• Ar lengva rasti kitą veiksmą ir ar jo pavadinimas paaiškina, kas įvyks?
• Ar tarpusavyje konkuruojantys mygtukai be reikalo neapsunkina pasirinkimo?

Pabandykite pradėti nuo paslaugos puslapio, ne tik nuo pagrindinio. Žmogus gali ateiti neturėdamas konteksto, kurį pateikia pradinis puslapis.

2. Navigacija ir informacijos paieška

• Ar meniu pavadinimai auditorijai suprantama kalba nurodo, kur veda?
• Ar galima atskirti panašias paslaugas ar kategorijas?
• Ar aišku, kur žmogus yra ir kaip grįžti į ankstesnį lygį?
• Jei yra paieška ar filtrai, ar jie padeda tęsti, kai rezultatų nėra?

Eikite konkrečiu keliu turėdami klausimą. „Ar galiu tai rasti?“ naudingiau nei „Ar meniu atrodo tvarkingai?“

3. Turinys ir sprendimo priėmimas

• Ar sprendimui reikalinga informacija pateikiama prieš pagrindinį kvietimą veikti?
• Ar peržvelgus antraštes galima rasti atsakymus apie apimtį, tinkamumą ar kitus žingsnius?
• Ar nepažįstami terminai paaiškinami ten, kur vartojami?
• Ar nuorodos, kontaktai ir papildoma informacija atitinka puslapio pažadą?

Informacijos trūkumas gali atrodyti kaip dizaino problema. Jei žmogus nesupranta, kas įeina į paslaugą, ryškesnis mygtukas į jo klausimą neatsakys.

4. Formos ir klaidų taisymas

• Ar kiekvienas laukas turi aiškų, neišnykstantį pavadinimą ir ar pažymėti privalomi laukai?
• Ar formato reikalavimai paaiškinami dar prieš padarant klaidą?
• Ar klaidos pranešimas nurodo konkretų lauką ir paaiškina, kaip jį pataisyti?
• Ar po klaidos išsaugoma teisingai įvesta informacija?
• Ar sėkmingai pateikus formą rodomas aiškus patvirtinimas ir paaiškinama, kas bus toliau?

Išbandykite ne tik teisingus, bet ir nepilnus bei netinkamus atsakymus. Jei testavimo aplinka leidžia, patikrinkite, kas nutinka nepavykus pateikti formos ar nutrūkus ryšiui.

5. Naudojimas telefone

• Ar tikrame telefone galima pasiekti ir naudoti navigaciją, formas bei pagrindinius veiksmus?
• Ar fiksuoti elementai, reklaminės juostos arba ekrano klaviatūra neuždengia svarbaus turinio?
• Ar valdiklius lengva paspausti netyčia neaktyvuojant greta esančio veiksmo?
• Ar kelias tebeveikia, kai tekstas persikelia į kitą eilutę, turinys išsiskleidžia arba pasukamas ekranas?

Susiaurintas kompiuterio naršyklės langas tinka pradinei patikrai. Tačiau jis neparodo visų sąveikų, su kuriomis susidursite telefone.

6. Prieinamumo pagrindai

• Ar pagrindinę užduotį galima atlikti klaviatūra ir matyti, kuris valdiklis aktyvus?
• Ar antraštės prasmingos, formų laukai turi pavadinimus, o informatyvūs vaizdai — tinkamus tekstinius atitikmenis?
• Ar padidintas tekstas išlieka įskaitomas, o svetainė — naudojama?
• Ar svarbi informacija perteikiama ne vien spalva ir ar pakankamas teksto kontrastas?

Tai pradiniai patikrinimai, o ne išsamus prieinamumo vertinimas. W3C „Easy Checks“ pabrėžia, kad net įveikus bazinius patikrinimus gali likti reikšmingų kliūčių. W3C gairės pradinei peržiūrai.

7. Įkėlimas, sistemos atsakas ir netikėtos būsenos

• Ar aišku, kada svetainė vykdo veiksmą?
• Ar žmogus gali suprasti, kad veiksmas pavyko, nepavyko arba vis dar vyksta?
• Ar įkeliant pasislenkantis turinys nesukelia netyčinių paspaudimų ir neuždengia informacijos?
• Ar tušti ekranai, neveikiančios nuorodos ir nepasiekiamos paslaugos pasiūlo prasmingą kitą žingsnį?

Aptikę problemą užrašykite įrenginio ir ryšio sąlygas. „Svetainė atrodo lėta“ sunku paversti konkrečiu darbu. „Šiomis sąlygomis pateikus formą nerodomas joks pranešimas“ jau suteikia komandai kryptį tyrimui.

UX audito pavyzdžiai: nuo pastebėjimo iki aiškios išvados

Toliau pateikti iliustraciniai pavyzdžiai. Jie parodo, kaip aprašyti problemą, ir nėra Flair kliento projekto audito išvados.

Pavyzdys: forma, kuri verčia spėlioti

Pastebėjimas: įvedus netinkamą el. pašto adresą, virš laukų rodomas pranešimas „Įvyko klaida“. Jis nenurodo el. pašto lauko ir nepaaiškina reikiamo formato.

Pasekmė naudotojui: prieš tęsdamas žmogus turi pats išsiaiškinti, kas nepavyko.

Siūlomas pakeitimas: prie el. pašto lauko parodyti konkretų pranešimą, susieti jį su lauku pagalbinėms technologijoms ir išsaugoti kitus atsakymus. Jei klaida neleidžia pateikti formos, nukreipti fokusą į tinkamą klaidų suvestinę arba netinkamai užpildytą lauką, kad pranešimą būtų galima aptikti.

Patikrinimas: pakartoti netinkamo el. pašto įvedimo užduotį naudojant klaviatūrą ir pagalbinių technologijų patikrą, pataisyti atsakymą ir įsitikinti, kad formą galima pateikti iš naujo nevedant teisingų duomenų.

Pavyzdys: paslaugų pavadinimai, slepiantys skirtumus

Pastebėjimas: paslaugų puslapyje siūloma „Launch“, „Grow“ ir „Transform“. Prie visų yra toks pats mygtukas „Sužinoti daugiau“, bet nepaaiškinta, kokiam projektui kuri paslauga skirta.

Pasekmė naudotojui: žmogus turi atsidaryti kelis puslapius, kad suprastų, kuris variantas atitinka jo poreikius.

Siūlomas pakeitimas: išlaikyti prekės ženklo charakterį, bet prie kiekvienos paslaugos pridėti paprastą aprašymą ir prasmingą nuorodos pavadinimą.

Patikrinimas: paprašyti auditoriją atitinkančių žmonių pasirinkti paslaugą realistiškam projektui ir paaiškinti pasirinkimą. Prieš laikant pakeitimą pasiteisinusiu, patikrinti, ar aprašymai padeda priimti numatytą sprendimą.

Prioritetus nustatykite pagal pasekmes, ne vien taisymo paprastumą

Ilgas išvadų sąrašas gali sudaryti įspūdį, kad viskas skubu. Prieš spręsdami, ką daryti, atskirkite kelis klausimus.

Rimtumas: kiek problema apsunkina užduotį su ja susidūrusiam žmogui?

Naudokite paprastą darbinę skalę, dėl kurios sutaria komanda:

Poveikis verslui: kurį tikslą problema veikia ir kiek tiesiogiai? Pagrindiniame užklausos pateikimo kelyje esanti problema dabartiniam verslo tikslui gali būti svarbesnė už panašią kliūtį retai naudojamame informaciniame puslapyje. Be duomenų šio vertinimo nepaverskite teiginiu apie prarastas pajamas.

Aprėptis: kas ir kokiomis sąlygomis susiduria su problema? Jei duomenų nėra, pažymėkite, kad nežinoma. Mažas bendras srautas nereiškia, kad visiška kliūtis konkrečiai naudotojų grupei nesvarbi.

Išvadų pagrįstumas: ar atkūrėte funkcijos gedimą, stebėjote žmonių sunkumus, ar specialisto peržiūroje įžvelgėte tikėtiną riziką? Tai skirtingi įrodymai. Tiksliai įvardykite, ką kiekvienas jų leidžia teigti.

Pastangos ir priklausomybės: ko reikia problemai ištirti ar ištaisyti? Įtraukite už dizainą, turinį ir programavimą atsakingus žmones. Iš pažiūros mažas pakeitimas gali priklausyti nuo bendro komponento ar išorinės paslaugos.

Tuomet pasirinkite veiksmą:

• Taisyti pirmiausia: patvirtintos užduotis blokuojančios problemos ir rimtos kliūtys svarbiuose keliuose.
• Planuoti toliau: reikšmingi trukdžiai, kai pakeitimui pagrįsti pakanka įrodymų.
• Tirti: galimai svarbios problemos, kurių priežastis ar poveikis naudotojui dar neaiškus.
• Atidėti į darbų sąrašą: mažesnio poveikio patobulinimai, prie kurių verta grįžti atliekant susijusius darbus.

Tai pagrindas komandos diskusijai, o ne formulė, pateikianti objektyviai teisingą balą. Paprastus patobulinimus galima įgyvendinti kartu su didesniais darbais, bet dėl jų rimtos kliūtys neturėtų laukti be galo.

Paprasta UX audito prioritetų lentelė

Šią struktūrą nukopijuokite į komandos darbinį dokumentą. Vienas įrašas — viena problema. Užpildyti stulpeliai tęsia iliustracinius pavyzdžius; jų prioritetai preliminarūs ir turi būti peržiūrėti pagal tikrus įrodymus.

Naujai problemai užfiksuokite: ID → užduotis ir URL → sąlygos → įrodymai → pasekmė naudotojui → rimtumas → poveikis verslui → aprėptis ir pagrįstumas → pastangos → veiksmas → atsakingas žmogus → priėmimo patikra → pakartotinės patikros rezultatas.

Pastebėjimą atskirkite nuo rekomendacijos. „Žmonės negali atpažinti tinkamos paslaugos“ aprašo problemą, kurią reikia ištirti. „Pridėti karuselę“ jau įsipareigoja sprendimui, dar nežinant, ar jis padės.

Užbaikite planu, kurį galima įgyvendinti

Išvadas aptarkite su žmonėmis, kurie keis svetainę. Sutarkite dėl atsakomybių, priklausomybių ir pirmųjų veiksmų. Jei išvada dar neaiški, kitas žingsnis gali būti tyrimas, o ne dizaino keitimas.

Įgyvendinę pakeitimą pakartokite pradinę užduotį aktualiomis sąlygomis. Pasikeitus bendram komponentui patikrinkite susijusius puslapius. Kur tinka, rezultatą vertinkite papildomais naudojamumo testais arba palyginamais analitikos duomenimis. Vien konversijos pokytis neįrodo, kodėl jis įvyko.

Naudingas auditas suteikia komandai aiškesnį kitą žingsnį. Tai gali būti nedideli patobulinimai, konkrečios dalies atnaujinimas arba papildomas tyrimas. Apimtį turėtų lemti įrodymai.

Jei jūsų svetaine naudotis sudėtingiau, nei turėtų būti, papasakokite, ką žmonės joje turi atlikti. Galėsime aptarti, kurias patirties vietas verta įvertinti atidžiau ir koks kitas žingsnis būtų prasmingas.

Dažniausi klausimai

Ar galiu atlikti UX auditą neturėdamas analitikos?

Taip. Galite peržiūrėti pagrindines užduotis, atkurti funkcines problemas ir pasitelkti turimus klientų atsiliepimus. Aiškiai pažymėkite, kai aprėptis ar poveikis nežinomi. Be elgsenos duomenų arba naudotojų tyrimų dalis išvadų liks hipotezėmis.

Kuriuos puslapius tikrinti pirmiausia?

Pradėkite nuo naudotojams ir verslui svarbiausių kelių. Įtraukite jų pradžios vietas, sprendimo puslapius, veiksmus, klaidas ir patvirtinimus. Pridėkite pagrindinių puslapių šablonų pavyzdžius, kad nepraleistumėte bendrų problemų.

Ar automatinis įrankis gali atlikti auditą už mane?

Įrankiai gali aptikti dalį techninių ar prieinamumo problemų ir padėti surinkti įrodymus. Tačiau vieni jie nenustatys, ar auditorijai suprantami paslaugų aprašymai ir ar kelias padeda priimti realų sprendimą. Jų išvadas derinkite su rankine peržiūra ir aktualiais naudotojų pastebėjimais.

Kaip dažnai kartoti UX auditą?

Atitinkamus kelius peržiūrėkite po reikšmingų pakeitimų ir atsiradus naujų problemą rodančių duomenų. Dažnis turėtų priklausyti nuo svetainės pokyčių ir jos užduočių svarbos. Sutartus pataisymus tikrinkite vos juos įgyvendinę, nelaukdami kito visos svetainės audito.