Kako sprovesti analizu grešaka u UX istraživanju: praktičan vodič sa AI promptovima

Šta je analiza grešaka?

Analiza grešaka (Error Analysis) je fokusirana metoda inspekcije koja uzima trenutke u kojima korisnici nešto pogrešno urade — pogrešni klikovi, neuspele predaje formi, napušteni tokovi, tiketi podrške, rage clicks — i pretvara ih u strukturisani, prioritizovani backlog problema upotrebljivosti. Umesto da postavlja široko pitanje “da li su korisnici uspeli”, analiza grešaka pita drugačije: “gde su korisnici pali, zašto su pali i koji padovi najviše koštaju biznis”. Jedan prolaz analize grešaka na fokusiranom toku traje od jednog do tri dana, daje kategorizovanu listu svih jedinstvenih režima otkaza sa frekvencijom i ozbiljnošću i govori timu šta da popravi prvo kada inženjerski kapacitet nije dovoljan.

Na koje pitanje odgovara metoda?

Gde u ovom toku korisnici prave greške i koliko često se svaka greška dešava?
Da li su otkazi koje vidimo izazvani dizajnom, mentalnim modelom korisnika, sadržajem ili sistemskim bagom?
Koji otkazi potpuno blokiraju izvršenje zadatka, a koji su samo trenje iz kojeg korisnik može da se izvuče?
Koja dva ili tri režima otkaza čine većinu tiketa podrške i koliko bi koštalo da se poprave?
Nakon redizajna, da li je stopa otkaza na glavnom zadatku zaista pala i da li su se pojavili novi režimi otkaza?
Koje greške su koncentrisane na konkretne segmente korisnika, uređaje ili pretraživače, a koje pogađaju sve podjednako?

Kada koristiti analizu grešaka

Nakon moderiranog ili nemoderiranog testa upotrebljivosti, kada imate video, beleške ili samoprijave problema koje treba kodirati u strukturisanu listu otkaza pre nego što počnete da prioritizujete popravke.
Kada tiketi podrške, povratne informacije unutar proizvoda ili logovi rage clicks ukazuju na obrazac otkaza u konkretnom toku, ali još niko nije kvantifikovao koji otkazi su najvažniji.
Posle lansiranja ili redizajna, kada tim treba da zna da li je nova verzija smanjila ili pomerila stopu otkaza pre nego što odluči o sledećem krugu posla.
Kada analitika pokazuje oštar pad na konkretnom koraku, ali brojevi sami po sebi ne objašnjavaju zašto korisnici odlaze — analiza grešaka pretvara “šta” u “zašto”.
Kada je LLM funkcionalnost u produkciji i timu treba da razume njene specifične režime otkaza (halucinacije, greške retrieval-a, odgovori van teme) pre definisanja metrika evaluacije.
Kada izvršni nivo pita “da li proizvod postaje bolji”, a timu treba odbranjivo i ponovljivo merenje koje se može pratiti kroz release-ove.

Nije prava metoda kada još nema podataka — analiza grešaka zavisi od posmatranih otkaza u realnim sesijama, logovima ili kanalima podrške, i ne može da generiše uvide na praznoj tabli. Takođe je pogrešan izbor za rana discovery pitanja o motivaciji ili nezadovoljenim potrebama korisnika; za to su potrebni intervjui ili dnevničke studije. Analiza grešaka kaže gde se trenutni proizvod lomi, ali ne i šta sledeće graditi. Konačno, ne koristite je kao zamenu za test upotrebljivosti na novom proizvodu — bez baznih zadataka i posmatranja, nema toka grešaka koji bi se analizirao.

Šta dobijate na izlazu

Taksonomija režima otkaza: mali skup imenovanih, međusobno isključivih kategorija (tipično šest do deset) u koje se može smestiti svaka posmatrana greška, sa jednolinijskom definicijom svake.
Kodirani log grešaka: red po posmatranom otkazu sa tagovima kategorije, ozbiljnosti, ekrana ili koraka gde se desio, segmenta korisnika i doslovne izjave ili snimka ekrana kada postoji.
Tabela frekvencija: koliko često se svaki režim otkaza pojavljuje, raščlanjeno po zadatku i segmentu, kako bi tim video koji otkazi su masovni a koji su rubni slučajevi.
Matrica ozbiljnosti: svaki jedinstveni otkaz ocenjen po uticaju (da li blokira zadatak, da li je oporaviv, da li je kozmetika) kako bi tim mogao da prioritizuje protiv inženjerskog kapaciteta.
Beleške o uzrocima: za svaki visokoprioritetni režim otkaza kratak pasus koji objašnjava najverovatniji uzrok — dizajn, sadržaj, mentalni model, tehnički bag — na osnovu dokaza.
Preporučene popravke: konkretni predlozi izmena vezani za svaki visokoprioritetni režim otkaza, sa grubom procenom napora kako bi tim mogao da planira sledeći sprint.
Readout brief: dokument od pet do deset strana ili kratka prezentacija sa naslovnim otkazima, kategorizovanim backlog-om, akcionim planom i opisom metode kako bi se buduće analize mogle uporediti sa ovom osnovom.

Učesnici i podaci

Učesnici: niko se direktno ne regrutuje. Analiza grešaka je sekundarna analiza nad podacima koji su već prikupljeni drugom metodom — sesije testa upotrebljivosti, snimci ekrana, tiketi podrške, logovi grešaka, widgeti za povratne informacije ili samoprijave iz anketa.
Količina podataka: za podatke moderiranog testa upotrebljivosti, fokusirani tok sa pet do dvanaest učesnika daje dovoljno grešaka za smislen prolaz. Za log ili tiket podatke, praktični minimum je pedeset do dvesta opservacija po toku; više je bolje za retke režime otkaza.
Priprema: 0,5–1 dan za definisanje obima, prikupljanje izvornih podataka i izbor alata za kodiranje.
Otvoreno kodiranje: 0,5–1 dan da se pročita svaka opservacija, napiše slobodna tekstualna oznaka za svaki otkaz i izdrži iskušenje da se oznake prerano nateraju u kategorije.
Izgradnja taksonomije: pola dana za grupisanje slobodnih oznaka u mali skup imenovanih kategorija i jednolinijske definicije.
Strukturisano kodiranje: 0,5–1 dan da se ponovo pročita svaka opservacija i dodeli finalna oznaka taksonomije, ozbiljnost i tag segmenta.
Sinteza i pisanje: 0,5–1 dan za izgradnju tabele frekvencija, ocenu ozbiljnosti, beleške o uzrocima i sam brief.
Ukupno trajanje: 2–4 dana od početka do kraja za fokusirani tok sa pedeset do nekoliko stotina opservacija.

Kako sprovesti analizu grešaka (korak po korak)

1. Definišite obim i izvor podataka

Pre nego što dodirnete bilo koje podatke, zapišite tačno koji tok, koji zadatak, koji vremenski prozor i koji segment korisnika analizirate. Obim poput “otkazi naplate na mobilnom vebu za nove korisnike u poslednjih 30 dana” daje upotrebljive nalaze; obim poput “greške u proizvodu” daje neodređeni izveštaj na koji niko ne može da reaguje. Zatim izaberite izvor podataka koji odgovara obimu: video i beleške iz moderiranog testa upotrebljivosti, snimci ekrana iz nemoderirane studije, tiketi podrške iz help desk-a, logovi grešaka frontenda, widgeti za povratne informacije, ili neka kombinacija. Različiti izvori hvataju različite otkaze, pa budite eksplicitni o tome koje koristite a koje ne.

2. Prikupite reprezentativan uzorak

Povucite uzorak opservacija dovoljno velik da na površini izađu česti režimi otkaza i nekoliko retkih. Za moderirane podatke to je sve što ste prikupili — pet do dvanaest sesija. Za logove ili tikete ciljajte na pedeset do dvesta opservacija na toku koji se analizira; za proizvode sa visokim saobraćajem uzorkujte po segmentu umesto nasumično, kako bi manje grupe bile zastupljene. Pri uzorkovanju namerno uključite i sesije u kojima su korisnici uspeli — kontrast čini obrasce otkaza vidljivim. Sačuvajte uzorak na jednom mestu (folder, red za anotaciju, tabela) tako da svaki prolaz kodiranja radi sa istim setom.

3. Otvoreno kodiranje: zapišite šta vidite, ne šta mislite

Prođite kroz svaku opservaciju u uzorku i napišite slobodan tekstualni komentar koji opisuje prvo mesto gde je nešto pošlo naopako. Ostanite deskriptivni: “korisnik je kliknuo na pogrešnu karticu proizvoda i nije primetio 30 sekundi” ili “predaja forme je propala bez vidljive poruke o grešci”. Još ne pokušavajte da otkaz uguraite u kategoriju — to dolazi kasnije. Otvoreno kodiranje je korak u kojem puštate podatke da govore; nateravanje kategorija prerano će vas naterati da propustite režime otkaza koje niste očekivali. Ako jedna sesija sadrži više grešaka, fokusirajte se na prvi otkaz koji je bio bitan, jer su naredne greške obično posledice prethodne.

4. Klasterujte oznake u taksonomiju

Kada imate slobodne tekstualne oznake za svaku opservaciju, rasporedite ih i grupišite slične. Cilj je mali skup — šest do deset kategorija je optimum — međusobno isključivih režima otkaza sa jednolinijskom definicijom za svaku. Tipične kategorije uključuju slips (korisnik je hteo pravu akciju ali je promašio), mistakes (korisnik je sledio pogrešan mentalni model), confusions (dvosmislenost interfejsa je dovela do oklevanja ili vraćanja), sistemske greške (sam proizvod se polomio), sadržajni otkazi (terminologija ili copy nisu bili jasni) i abandonments (korisnik je odustao bez eksplicitne greške). Za LLM proizvode taksonomija izgleda drugačije — halucinacije, otkazi retrieval-a, odgovori van teme, problemi sa formatiranjem, izostanak follow-up-a. Ne izmišljajte kategorije koje podaci ne podržavaju; ako ste videli samo jedan primer “validacije forme”, on živi pod “sistemske greške”, ne kao zaseban red.

5. Strukturisano kodiranje: ponovo označite sve protiv taksonomije

Sada se vratite na svaku opservaciju i dodelite kanonsku oznaku taksonomije, ozbiljnost i tag segmenta. Ovo je prolaz koji pretvara sirove beleške u kvantifikovani dataset. Za svaku opservaciju zabeležite pet polja: gde (ekran ili korak), šta (posmatrano ponašanje), kategorija (iz vaše taksonomije), ozbiljnost (cosmetic / minor / major / critical ili skala 0–4) i segment (tip korisnika, uređaj, pretraživač, doba dana). Ako pronađete opservacije koje se ne uklapaju ni u jednu kategoriju taksonomije, imate dve opcije: proširite taksonomiju ako je nepodudaranje pravi obrazac, ili dodajte korpu “other” i pregledajte je na kraju. Izdržite iskušenje da proširite taksonomiju iznad deset kategorija — sve preko toga postaje previše granularno da bi bilo korisno.

6. Izgradite tabelu frekvencija i matricu ozbiljnosti

Prebrojite koliko često se svaki režim otkaza pojavljuje, raščlanjeno po zadatku, segmentu i ozbiljnosti. Brojte broj jedinstvenih korisnika koji su pogođeni otkazom, ne broj događaja — jedan korisnik koji deset puta uhvati isti bag priča drugačiju priču od deset korisnika koji ga svaki uhvate jednom. Izgradite jednostavnu matricu sa kategorijama na jednoj osi i ozbiljnošću na drugoj; ćelije gde se kritični otkazi gomilaju su mesta na kojima tim treba prvo da se fokusira. Gde je moguće, ponderišite svaki otkaz po verovatnom uticaju na biznis: otkaz na stranici naplate koji blokira prihod vredi više od otkaza na stranici podešavanja koju niko ne vidi.

7. Dijagnostikujte uzroke top otkaza

Za top tri do sedam režima otkaza napišite kratak pasus koji objašnjava zašto se ovaj otkaz dešava. Razlikujte četiri uzroka: problem dizajna (raspored, etikete ili affordance su zaveli korisnika), neusklađenost mentalnog modela (korisnik je očekivao drugačiji model nego što proizvod nudi), sadržajni otkaz (formulacija ili terminologija nisu bili jasni), ili tehnički bag (sam proizvod se polomio). Svaki ima drugu popravku i drugi tim za dodelu, pa dijagnoza je važna za akciju. Koristite direktne dokaze — citirajte doslovnu opservaciju, povežite se sa snimkom ekrana ili sesije — umesto interpretacije, kako bi dizajn i inženjerski lideri mogli sami da provere zaključak.

8. Prioritizujte i predložite popravke

Ocenite svaki visokoprioritetni otkaz po tri dimenzije: ozbiljnost (koliko jako boli korisnika kada se desi), frekvencija (koliko često realan korisnik na njega nailazi) i poslovni uticaj (efekat na aktivaciju, retention, konverziju, support cost). Sumirajte tri ocene da biste dobili rang prioriteta, a zatim izaberite top pet do deset otkaza koji idu u sledeći sprint. Za svaki nacrtajte konkretnu preporučenu popravku i grubu procenu napora (small, medium, large). Završite manjim skupom otkaza koje treba pratiti, ali odložiti — obično nisko-ozbiljne probleme koje bi bilo jeftino popraviti kao bočni efekat veće izmene.

9. Napišite brief i prezentujte stejkholderima

Napravite brief od pet do deset strana ili kratku prezentaciju. Otvorite obimom, izvorom podataka i naslovnim nalazom na prvoj strani. Prođite kroz svaki krupni režim otkaza sa frekvencijom, ozbiljnošću, uzrokom, dokazima i preporučenom popravkom. Završite prioritizovanim akcionim planom i jednostraničnim dodatkom o metodi tako da sledeća analiza može da reprodukuje pristup. Prezentujte lično product, design i engineering liderima umesto da šaljete dokument mejlom — razgovor na readout-u je mesto gde stejkholderi kalibriraju ozbiljnost i posvećuju se popravkama. Pun kodirani log priložite kao referencu za tim koji će implementirati izmene.

Kako AI menja analizu grešaka

AI compatibility: partial — Većina analize grešaka je mehaničko poklapanje obrazaca preko bučnih tekstualnih podataka, a moderni LLM-ovi su jako dobri upravo u tom poslu. Štos je u tome što najvredniji sudovi — definisanje pravog obima, razlikovanje stvarnog režima otkaza od jedinstvenog slučaja, kalibracija ozbiljnosti prema poslovnom uticaju i objašnjenje uzroka za svaki top otkaz — i dalje zahtevaju čoveka koji poznaje proizvod. AI sažima prolaze otvorenog kodiranja i klasterovanja sa dana u sate, što istraživaču oslobađa vreme za dijagnozu i prioritizaciju.

Šta AI ume

Klasterovanje slobodnih opservacija u taksonomiju: Na nekoliko stotina sirovih beleški o greškama iz nemoderiranog testa ili eksporta tiketa podrške, LLM može da grupiše slične opservacije, predloži šest do deset koherentnih kategorija otkaza i napiše jednolinijske definicije za nekoliko minuta — isti posao koji bi istraživaču oduzeo pola dana sortiranja kartica.
Pokrenuti strukturisani prolaz kodiranja na velikoj skali: Kada taksonomija postoji, LLM može da ponovo označi svaku opservaciju protiv nje sa visokom konzistentnošću i istakne rubne slučajeve za ručni pregled. Ovo je korak koji se istorijski loše skalirao sa veličinom uzorka; AI uklanja usko grlo i dozvoljava analizi da pokrije stotine ili hiljade opservacija umesto desetina.
Oceniti ozbiljnost po fiksnoj rubrici: Model koji primenjuje jednopasusnu rubriku ozbiljnosti na svaki otkaz daje konzistentne ocene koje istraživač može da proveri uzorkom umesto da ocenjuje od nule. Drift kalibracije između ručnih kodera je hroničan problem ovog metoda; AI ga rešava za rutinske slučajeve.
Rudariti tikete podrške i transkripte snimaka sesija u potrazi za obrascima otkaza: Alati poput Dovetail-a, Marvin-a, Notably-ja i istraživačke funkcionalnosti Gong-a mogu da progutaju velike količine nestrukturisanog feedback-a, podignu na površinu teme koje se ponavljaju i povežu svaku sa doslovnim citatima — pretvarajući plast sena pritužbi u strukturisanu listu otkaza.
Analizirati režime otkaza LLM aplikacija: Za proizvode sa ugrađenim LLM funkcionalnostima, platforme za evaluaciju (Langfuse, Humanloop, Braintrust, Promptfoo) automatizuju workflow otvorenog kodiranja na produkcijskim trace-ovima, klasteruju otkaze u imenovane režime i dozvoljavaju timu da prati stope otkaza kroz promene modela i prompta.
Napraviti nacrt readout brief-a: Sa kodiranim logom i tabelom frekvencija, LLM može da napravi prvi nacrt brief-a organizovanog po režimima otkaza, sa naslovnim nalazima, tabelama frekvencija i preporučenim popravkama. Istraživač ga zatim prepisuje za ton, izoštrava prioritizaciju i uklanja neizbežnu lažnu sigurnost.

Šta zahteva čoveka istraživača

Definisanje obima i izbor izvora podataka: AI će rado klasterovati šta god mu date, ali odlučivanje o tome koji tok je važan, koji vremenski prozor da povučete i koje izvore da kombinujete je proizvodni sud koji se oslanja na poznavanje poslovnog konteksta. Pogrešite ovde — i analiza je tehnički ispravna, ali beskorisna.
Dijagnoza uzroka iz ograničenih dokaza: Razlikovanje problema dizajna od neusklađenosti mentalnog modela od sadržajnog otkaza od baga zahteva poznavanje toga kako proizvod radi, ko je korisnik i šta je tim već probao. Modeli će pogađati uzroke iz samog teksta i davati uverljive ali pogrešne dijagnoze.
Kalibracija ozbiljnosti prema poslovnoj realnosti: Jednopasusna rubrika ozbiljnosti ne može da uhvati da je oklevanje na stranici naplate kritičan signal odliva u ovoj konkretnoj kompaniji, dok je oklevanje na stranici podešavanja kozmetika. Ozbiljnost mora ponovo da se usidri u poslovnom uticaju od strane nekoga ko zna i jedno i drugo.
Uočavanje režima otkaza koje model nije video: AI klasterovanje teži ka čestim kategorijama i tiho ispušta retke rubne slučajeve koji su često najvažniji — otkaz koji pogađa jedan posto korisnika u toku visokog prihoda, ili novi režim otkaza koji je doneo poslednji release. Istraživač mora ručno da pročita outliers pre nego što poveruje taksonomiji.
Razgovor na readout-u: Stejkholderi se posvećuju popravkama na sastanku, ne u dokumentu. AI može da napravi odbranjiv nacrt, ali živa diskusija u kojoj product, design i engineering pregovaraju o prioritetima i kompromisima je mesto gde izveštaj zaista pokreće promenu.

AI-pojačani workflow

Pre AI-ja, analiza grešaka na sto opservacija oduzimala je tri do pet dana analitičarskog vremena: dan da se pročita svaka opservacija i napišu otvoreno kodirane beleške, pola dana da se napravi taksonomija na stikerima, dan da se sve ponovo kodira protiv taksonomije, pola dana da se napravi tabela frekvencija, ostatak da se napiše brief. Usko grlo bila su dva prolaza kodiranja — sporo, repetitivno i sklono driftu kako pažnja analitičara opada oko osamdesete opservacije.

Sa AI-jem u workflow-u, isti projekat se sažima na jedan do dva dana. Istraživač provodi jedan sat oblikujući obim i birajući izvor podataka, a zatim ubacuje sirove opservacije u LLM sa promptom koji za nekoliko minuta daje nacrt taksonomije. Istraživač pregleda taksonomiju, ureduje gde je model propustio kontekst i dodaje režime otkaza koje je model spojio. Strukturisani prolaz kodiranja zatim radi protiv očišćene taksonomije mašinskom brzinom, sa istraživačem koji uzorkom proverava 10–20% oznaka i nadjačava gde je potrebno. Tabela frekvencija i matrica ozbiljnosti se generišu automatski. Vreme istraživača ide u korake koji su najvažniji: obim, dijagnoza uzroka i razgovor na readout-u.

Štos je isti kao za AI-pomognut desk research i heuristic evaluation: ubrzanje je realno samo kada čovek verifikuje izlaz AI-ja umesto da mu veruje. Studije LLM-driven kvalitativnog kodiranja pokazuju da modeli pouzdano klasteruju lake obrasce, ali tiho ispuštaju retke i dvosmislene, i da ocene ozbiljnosti driftuju ka sredini rubrike osim ako čovek ne sidri. Istraživači koji izvuku najviše vrednosti od AI-ja ovde tretiraju ga kao brzog junior kodera — koristan za masovni prolaz, nikada poveren kao finalni odgovor, uvek upareni sa čovekom koji čita outliers i poseduje dijagnozu.

Primer iz prakse

E-commerce kompanija srednje veličine je videla pad od 12% u završetku mobilne naplate nakon redizajna koji je spojio ekrane adrese, plaćanja i pregleda u jednu dugu stranicu. Analitika je jasno pokazivala pad, ali nije objašnjavala šta se dešava između početka stranice i neuspelih predaja. Product manager je imao dve nedelje da povrati izgubljenu konverziju pre praznične sezone.

Vodeća istraživačica je povukla tri toka podataka u prozoru od 14 dana: 180 snimaka sesija filtriranih po mobilnim korisnicima koji su počeli naplatu ali nisu završili, 240 tiketa podrške sa tagovima ključnih reči checkout i log frontend grešaka iz Sentry-ja za isti period. Snimke je učitala u Dovetail, tikete u Google Sheet, a Sentry izuzetke u zasebnu karticu. Pokrenula je prolaz otvorenog kodiranja na uzorku od 60 snimaka i 60 tiketa, pišući slobodne oznake za prvi posmatrani otkaz u svakoj. Zatim je ubacila svih 120 slobodnih oznaka u Claude sa promptom za klasterovanje i dobila nacrt taksonomije od sedam režima otkaza — tri od kojih je zadržala doslovno, tri uredila radi jasnoće, a jednu podelila na dve jer je spajala sadržajni otkaz sa stvarnim bagom. Zatim je ponovo kodirala svih 420 opservacija (180 snimaka + 240 tiketa) protiv očišćene taksonomije za dva dana.

Tabela frekvencija je otkrila da je 41% svih otkaza dolazilo iz jednog režima: korisnici su tapkali polje automatski popunjene adrese očekujući da je urede inline, a umesto toga su dobijali modal za izbor adrese koji je gubio kontekst korpe kada bi pritisnuli “back”. Sentry log je potvrdio JavaScript grešku na handleru zatvaranja modala. Preporučena popravka je bila da se modal potpuno ukloni i da se automatski popunjena adresa uređuje inline. Inženjering je izbacio izmenu za tri dana, režim otkaza je nestao iz sledećeg uzorka, a stopa završetka naplate se oporavila za 9 poena u prvoj nedelji — oko tri četvrtine prvobitnog gubitka. Analiza je istraživaču oduzela četiri dana rada, manje od polovine onoga što bi tražio naredni moderirani test upotrebljivosti.

AI prompti za ovaj metod

4 spremnih AI prompta sa placeholderima — kopirajte i popunite svojim kontekstom. Svi prompti za analizu grešaka →.