Kako sprovesti heurističku evaluaciju: praktičan vodič sa AI promptovima

Šta je heuristička evaluacija?

Heuristička evaluacija (heuristic evaluation) je ekspertski metod inspekcije u kojem 3–5 obučenih evaluatora nezavisno prolazi kroz interfejs i ocenjuje ga prema fiksnom skupu principa upotrebljivosti, najčešće 10 heuristika Jakoba Nielsena. Svaki evaluator beleži svako uočeno kršenje, vezuje ga za određenu heuristiku, dodeljuje mu severity, i tim potom sjedinjuje pojedinačne liste u jedan prioritizovani backlog problema. Heuristička evaluacija je najjeftiniji i najbrži način da se otkriju sistemski problemi upotrebljivosti u proizvodu pre nego što se novac potroši na inženjering ili formalno testiranje upotrebljivosti — pun prolaz sa tri evaluatora na fokusiranom flow-u traje jedan do tri dana i pouzdano hvata oko 75% problema koji bi se inače pojavili kasnije na testiranju upotrebljivosti.

Na koje pitanje odgovara metoda?

Gde ovaj interfejs krši poznate principe upotrebljivosti i koja kršenja su najozbiljnija?
Koji ekrani ili flow-ovi imaju najkoncentrisanije probleme upotrebljivosti, a koji su sigurni za isporuku takvi kakvi jesu?
Koje očigledne probleme treba popraviti pre pokretanja skupog testa upotrebljivosti, kako bi test sesije ciljale prava pitanja umesto da hvataju očigledne bagove?
Koje dizajn-odluke protivreče industrijskim konvencijama na način koji će nas koštati learnability za nove korisnike?
Koji obrasci UX duga se ponavljaju kroz proizvod (loš feedback, nedostatak prevencije grešaka, nedosledna terminologija) i zaslužuju sistemsku popravku umesto pojedinačne zakrpe?
Za postojeći živi proizvod — gde su mesta sa najvećim uticajem za dizajn-investicije pri ograničenom inženjerskom budžetu?

Kada koristiti heurističku evaluaciju

Rano u dizajn-ciklusu, kada wireframe-ovi ili maketi postoje ali proizvod još nije izgrađen — heuristička evaluacija hvata očigledne probleme dok ih je još jeftino menjati.
Pre bilo kog testa upotrebljivosti, da se očiste očigledna kršenja kako bi učesnici testa trošili vreme na pitanja na koja samo pravi korisnici mogu da odgovore.
Pri reviziji živog proizvoda čiji je UX degradirao tokom vremena i timu je potreban strukturisan način da prioritizuje dug bez regrutovanja korisnika.
Pri ulasku u projekat kao spoljni konsultant ili agencija, kada treba brz i branjiv pregled stanja proizvoda u nekoliko dana.
Kada budžet ili rok potpuno isključuju testiranje upotrebljivosti, a timu i dalje treba lista problema upotrebljivosti zasnovana na dokazima.
Pri obučavanju junior dizajnera ili PM-ova razvijanju UX instinkta — pokretanje heurističkih evaluacija na pravim proizvodima jedan je od najbržih načina da se interno usvoje principi upotrebljivosti.

Metoda nije pravi izbor kada je pitanje o dubljem “zašto” iza ponašanja korisnika, motivaciji ili nezadovoljenim potrebama — heuristička evaluacija pronalazi samo kršenja poznatih principa, ne nove kategorije problema koje heuristike ne pokrivaju. Takođe propušta probleme koji zavise od specifičnih mentalnih modela prave grupe korisnika (specijalizovana terminologija, domenski workflow-ovi, potrebe pristupačnosti koje heuristike ne pokrivaju). Heuristička evaluacija je dopuna testiranju upotrebljivosti, ne zamena; timovi koji isporučuju proizvod samo na osnovu heurističke evaluacije dosledno propuštaju otkaze koji se pojavljuju samo kad pravi korisnici pokušaju da završe prave zadatke. Konačno, ovo nije revizija pristupačnosti ili kvaliteta sadržaja — za njih su potrebne posebne provere (WCAG revizija, content review).

Šta dobijaš (artefakti)

Workbook heurističke evaluacije: strukturisan dokument po evaluatoru sa svakim zapažanjem označenim prema prekršenoj heuristici, ekranom ili flow-om, i preporučenom popravkom.
Konsolidovani spisak problema: spojen izlaz svih evaluatora, duplikati uklonjeni, kontradikcije razmotrene, svaki problem dobio finalnu severity ocenu.
Backlog sa severity ocenama: svaki problem ocenjen po standardnoj skali (obično cosmetic / minor / major / critical, ili Nielsen-ova 0–4 skala) tako da tim može da prioritizuje popravke prema inženjerskom kapacitetu.
Klaster-mapa: problemi grupisani po temama (navigacija, feedback, terminologija, greške, forme) tako da sistemski problemi postanu vidljivi umesto plitke liste pojedinačnih bagova.
Anotirani screenshot-ovi: svaki veliki problem ilustrovan odgovarajućim ekranom sa pozivom na kršenje, kako bi inženjeri i PM-ovi videli ono što je evaluator video.
Action plan: top 5–15 problema prioritizovanih po severity, učestalosti i poslovnom uticaju, sa konkretnim preporučenim popravkama i grubom procenom napora.
Readout deck ili brief: dokument od 5–10 strana ili kratka prezentacija koja vodi stejkholdere kroz metodu, glavne probleme i preporučene sledeće korake.

Učesnici i trajanje

Učesnici: direktno ne postoje — heuristička evaluacija je ekspertska inspekcija. “Učesnici” su 3–5 obučenih evaluatora koji nezavisno prolaze kroz interfejs.
Evaluatori: 1 evaluator hvata oko 35% problema upotrebljivosti, 3 evaluatora oko 60%, 5 evaluatora oko 75% (Nielsen 1994). Tri su najčešća optimalna tačka za produktne timove.
Vreme za pripremu: 0,5–1 dan za definisanje opsega, brifovanje evaluatora o heuristikama, pripremu screenshot-ova ili pristupa testu, izbor alata za beleženje.
Nezavisna evaluacija: 2–4 sata po evaluatoru za fokusiran flow, više za složen proizvod. Svaki evaluator radi sam, ne videći nalaze drugih.
Konsolidacija: od pola dana do celog dana za sjedinjavanje nalaza, razmatranje neslaganja, kalibraciju severity i grupisanje problema u teme.
Sinteza i pisanje: 0,5–1 dan za brief, anotirane screenshot-ove i prioritizovani action plan.
Ukupno vreme: 1–3 dana od početka do kraja za tipičan produktni flow sa tri evaluatora.

Kako sprovesti heurističku evaluaciju (korak po korak)

1. Definiši opseg i grupu korisnika

Odluči koji deo proizvoda ćeš evaluirati pre nego što brifuješ bilo kog evaluatora. Uzmi 1–3 kritična korisnička flow-a koja se mapiraju na zadatke visoke vrednosti (onboarding, checkout, glavni job-to-be-done) umesto da pokušavaš da pokriješ ceo proizvod. Eksplicitno navedi koji ekrani, stanja, uređaji i tipovi korisnika su u opsegu, a koji su izvan. Uzak opseg daje konkretne, akcione nalaze; širok opseg daje mutan, mišljenjima zasićen izveštaj. Zapiši tip korisnika koji evaluatori treba da prihvate — početnik koji prvi put isprobava proizvod i power user koji prolazi rutinski zadatak primetiće sasvim različite probleme.

2. Izaberi skup heuristika i brifuj evaluatore

Za većinu produktnih timova, 10 heuristika upotrebljivosti Jakoba Nielsena su prava polazna tačka jer su dobro dokumentovane, široko primenljive i odmah prepoznatljive svakome ko je radio u UX-u. Za specijalizovane domene dodaj odozgo domenski skup — Bastien & Scapin za ergonomsku dubinu, Gerhardt-Powals za kognitivni inženjering, WCAG quick reference za pristupačnost. Brifuj svakog evaluatora o izabranom skupu pre nego što počnu. Ako tim nikada nije sproveo heurističku evaluaciju zajedno, sprovedite 30-minutnu probnu rundu na proizvodu treće strane (aplikacija za vremensku prognozu, mali SaaS landing) tako da se svi kalibrišu na onome što se računa kao kršenje.

3. Odluči kako beležiti nalaze

Izaberi jedan deljeni šablon i zahtevaj od svakog evaluatora da ga koristi. Standardni format je red po zapažanju sa kolonama za ekran ili flow, šta se kvari, prekršenu heuristiku, severity i preporučenu popravku. Izbegavaj labave alate poput Figma komentara ili stikera — pretvaraju konsolidaciju u noćnu moru. Deljena tabela (Google Sheets, Airtable) radi za većinu projekata; za vizuelne evaluacije, NN/g-jev besplatan workbook PDF ili Miro tabla sa jednim prostorom po evaluatoru oba rade dobro. Kakav god alat da je izabran, svaki evaluator mora prvo privatno zabeležiti svoje nalaze; deljenje tokom nezavisnog prolaza pristrasi celu evaluaciju.

4. Prođi kroz interfejs dvaput

Svaki evaluator prolazi svaki flow najmanje dvaput. Prvi prolaz je za orijentaciju — upoznaj se sa proizvodom, nauči osnovni rečnik, završi svaki zadatak jednom bez pokušaja pronalaženja problema. Drugi prolaz je za evaluaciju — vrati se polako kroz iste flow-ove, ovaj put namerno proveravajući svaki ekran prema heuristikama. Većina evaluatora pronalazi više problema na drugom prolazu nego na prvom jer orijentacioni prolaz sklanja kognitivni teret “šta ovaj proizvod uopšte radi” sa stola. Planiraj 2–4 sata po evaluatoru za ovaj korak.

5. Beleži svako zapažanje kao strukturisani problem

Za svaki problem zapiši pet stvari: gde se problem pojavljuje (ekran, flow, tačan element), šta tačno ide naopako (vidljivo ponašanje, ne mišljenje), koju heuristiku krši (jednu primarnu, opciono sekundarnu), zašto je važno (uticaj na završetak zadatka ili poverenje), i jednu konkretnu preporučenu popravku. Citiraj tačan tekst ili opiši tačnu interakciju umesto da prepričavaš. Snimi screenshot. Disciplina pisanja u ovom formatu odvaja pravu heurističku evaluaciju od dizajn-roasta tipa “ovo mi se ne dopada” — svaki problem treba da bude reproducibilan od strane nekoga ko nije bio u sobi.

6. Oceni severity prema fiksnoj skali

Posle nezavisne evaluacije ali pre konsolidacije, svaki evaluator ocenjuje svaki problem na istoj skali severity-ja. Najčešća je 4-stepena skala: cosmetic (vizuelni polish, nema uticaja na zadatak), minor (vidljivo trenje ali zadatak uspeva), major (značajno trenje, verovatno izaziva greške ili oklevanje), critical (blokira završetak zadatka ili izaziva nepovratne greške). Originalna 0–4 skala Nielsena (no problem, cosmetic, minor, major, catastrophe) radi jednako dobro. Pravilo odluke je jednostavno: ako problem blokira nekoga da uradi svoj posao, kritičan je; ako samo iritira, minor je ili cosmetic. Dosledan severity je ono što čini konsolidovani backlog akcionim.

7. Konsoliduj i spoji liste

Dovedi sve evaluatore u jednu sobu (ili jedan poziv) sa njihovim nezavisnim listama. Prođite kroz svaki problem zajedno, grupišite duplikate, razmotrite neslaganja, ponovo kalibriši severity tamo gde su evaluatori isti problem ocenili različito. Diskusija je mesto gde se vrednost akumulira — jedan evaluator je uhvatio problem navigacije, drugi je uhvatio problem prevencije grešaka na istom ekranu, i diskusija otkriva da su to lica jednog dubljeg problema. Zabeleži spojenu listu na jednom mestu i označi svaki problem heuristikom, severity-jem, ekranom i preporučenom popravkom. Ako konsenzus o severity-ju ne može da se postigne, povisi za jedan stepen; cena popravke ne-problema je niža od cene isporuke pravog kritičnog baga.

8. Grupi probleme u teme

Grupi konsolidovane probleme u 3–7 tematskih klastera: navigacija i informaciona arhitektura, feedback i status sistema, prevencija grešaka i oporavak, terminologija i sadržaj, forme i unosi, vizuelni dizajn i hijerarhija, pristupačnost. Klasterovanje pretvara 30–60 pojedinačnih problema u šačicu glavnih obrazaca koje stejkholderi mogu zadržati u glavi i delovati po njima. Tim koji izađe sa readout sastanka pamteći “imamo problem sa feedback-om i problem sa navigacijom” isporučiće bolje popravke od tima koji je dobio tabelu od 47 redova.

9. Prioritizuj i napiši action plan

Oceni svaki klaster (ili svaki problem, ako je lista kratka) po tri dimenzije: severity (koliko jako udara po korisniku), učestalost (koliko često korisnici nailaze), poslovni uticaj (koliko utiče na aktivaciju, retenciju, konverziju ili troškove podrške). Saberi ocene ili koristi prostu high/medium/low matricu. Uzmi top 5–15 stavki za sledeći sprint. Završi konkretnim preporučenim popravkama i grubom procenom napora; brief koji isporučuje samo dijagnoze bez preporuka mnogo je teži za produktne timove da se na njega oslone.

10. Napiši brief i prezentuj stejkholderima

Napravi brief od 5–10 strana ili kratak deck koji se otvara opsegom i metodom, na prvoj strani sumira glavne nalaze, a zatim prolazi kroz svaku glavnu temu sa anotiranim screenshot-ovima i citatima evaluatora, i završava prioritizovanim action plan-om. Prezentuj produktnim, dizajn i inženjerskim lidovima lično umesto slanja dokumenta mejlom; diskusija na readout-u je mesto gde stejkholderi kalibrišu severity, pristaju na prioritete i obavezuju se na popravke. Pun backlog i konsolidovanu tabelu drži prikačene kao referencu za tim koji će zaista implementirati promene.

Kako AI menja heurističku evaluaciju

AI compatibility: partial (delimično). Moderni multimodalni LLM-ovi mogu da čitaju screenshot-ove i sprovode kredibilan prvi prolaz prema 10 heuristika Nielsena, ali nedavne peer-reviewed studije (Zhong, McDonald, Hsieh 2025; Vasiu et al. 2026) pokazuju da AI evaluatori hvataju različit i delimično preklapajući skup problema u poređenju sa ljudskim ekspertima, sa primetnim slepim tačkama na kontekstno zavisnim problemima. Realistična podela je da AI obrađuje rutinske površinske provere (loading stanja, oznake dugmadi, greške formi, kontrast boja, jasnoću copy-ja), dok ljudi donose odluke o opsegu, poslovnom kontekstu, severity-ju i problemima koji zavise od stvarnog mentalnog modela korisnika.

Šta AI može

Pokrenuti prvi prolaz pregleda screenshot-ova: Multimodalni modeli poput Claude, GPT-4o i Gemini mogu uzeti set screenshot-ova, proći kroz svaki i proizvesti strukturisanu listu kandidatskih kršenja prema 10 heuristika Nielsena za nekoliko minuta. Ovo je obično 50–70% temeljno koliko ljudski ekspert na rutinskim flow-ovima i korisna polazna tačka za ljudskog evaluatora.
Generisati listu provere heuristika za određeni flow: Sa opisom flow-a i ciljnog korisnika, LLM može proizvesti prilagođen skup yes/no pitanja za svaku od 10 heuristika, kastomizovan za ekrane koji se pregledaju. Ovo sažima pripremu za ljudski tim sa nekoliko sati na nekoliko minuta.
Označavati i konsolidovati nalaze više evaluatora: Kada više evaluatora preda zapažanja u slobodnom tekstu, LLM može pročitati sirove liste, deduplikovati slične probleme, predložiti imena klastera i predložiti spojen backlog sa severity ocenama — posao koji je ranije trajao pola dana sastanaka konsolidacije.
Dosledno ocenjivati severity: Drift kalibracije između ljudskih evaluatora je hroničan problem. LLM koji primenjuje fiksnu severity rubriku na svaki problem proizvodi dosledne, branjive ocene koje ljudski evaluatori potom mogu prepisati slučaj po slučaj umesto ocenjivanja iz nule.
Unakrsno proveravati nalaze prema pristupačnosti (WCAG) istovremeno: Model može primeniti Nielsenove heuristike i WCAG 2.2 kriterijume u istom prolazu, označavajući probleme koji krše oba i proizvodeći kombinovan rizik score. Alati poput Heurilens, Stark AI i Figma plagina za heurističku evaluaciju automatizuju ovu unakrsnu proveru.
Praviti nacrt readout brifa: Sa konsolidovanom listom problema, LLM može proizvesti prvi nacrt brifa organizovan po temama sa glavnim nalazima, anotiranim primerima i preporučenim popravkama. Ljudski istraživač potom prepisuje za ton i izoštrava prioritizaciju.

Šta zahteva ljudskog istraživača

Definisanje opsega i korisničke perspektive: AI će rado pokrenuti evaluaciju na bilo kom flow-u na koji ga uperiš, ali odluka koji flow-ovi su najvažniji, koji tip korisnika prihvatiti i šta ostaviti je produktna procena koja zavisi od poznavanja posla. Pogreši ovde i nalazi AI će biti tačni ali beskorisni.
Hvatanje kontekstno zavisnih kršenja: AI sistematski propušta probleme gde kršenje zavisi od mentalnog modela korisnika, okolnog workflow-a ili domenskih konvencija koje model nikada nije video. Specijalizovani B2B alati, regulisane industrije i kulturno specifični flow-ovi su najteže slepe tačke.
Kalibracija severity-ja prema poslovnoj realnosti: Model može oceniti severity prema generičkoj rubrici, ali znanje da je “oklevanje na stranici naplate” kritičan signal churn-a u ovoj specifičnoj kompaniji dok je “nedoslednost u podešavanjima” cosmetic zahteva poznavanje modela prihoda i baze klijenata proizvoda.
Razlikovanje pravih kršenja od namernih dizajn-kompromisa: Hamburger meniji krše “recognition rather than recall” ali su pravi izbor na mobilnom. AI evaluatori dosledno označavaju ova kao prave probleme; čovek zna kada da brani kompromis. Bez tog filtera AI izveštaj postaje šum.
Diskusija konsolidacije: Vrednost više evaluatora dolazi od sastanka gde sjedinjuju svoje liste, ne od samih lista. AI može deduplikovati i klasterovati, ali razgovor gde se “problem navigacije” jednog evaluatora ispostavi kao “problem prevencije grešaka” drugog je mesto gde se pojavljuju glavni nalazi.

AI-pojačan workflow

Pre AI-ja, heuristička evaluacija fokusiranog flow-a sa tri evaluatora trajala je 2–3 dana od početka do kraja: pola dana priprema, četiri sata po evaluatoru u nezavisnom radu, pola dana konsolidacija i ocenjivanje severity-ja, pola dana pisanje brifa. Usko grlo bio je nezavisni evaluacioni prolaz — tri pametna dizajnera, svaki prolazi iste ekrane i zapisuje iste rutinske probleme.

Sa AI u workflow-u isti projekat sažima se na jedan do dva dana. Lid istraživač troši sat na uokvirivanje opsega i tipa korisnika, zatim hrani screenshot-ove svakog ekrana multimodalnom modelu sa custom promptom koji prolazi kroz 10 heuristika Nielsena. Model vraća strukturisanu prvu listu kandidatskih problema po ekranu za nekoliko minuta. Dva ljudska evaluatora zatim uzimaju taj prvi prolaz kao polaznu tačku, sami prolaze kroz iste flow-ove kako bi potvrdili, proširili, prepisali i dodali kontekstno zavisne probleme koje je model propustio. Evaluatori troše vreme na procenu, ne na ponavljane mehaničke provere. Konsolidacija ide brže jer problemi već dele strukturu i rečnik; kalibracija severity-ja ide brže jer je model već predocenio sve prema istoj rubrici. Brief dobija prvi nacrt od modela i finalni prolaz od ljudskog istraživača.

Caka je ista kao kod AI-asistiranog desk research-a: ušteđeno vreme zavisi od pravog ljudskog prolaza verifikacije nad izlazom AI-ja. Studije koje su merile AI-only heurističke evaluacije protiv human-only našle su false positives (model je označavao probleme kojih nije bilo), false negatives (model je propuštao probleme koji su bili važni) i sklonost da preopterećuje vizuelne sitnice dok podcenjuje kontekstno zavisne probleme. Istraživači koji ovde dobijaju najviše vrednosti od AI-ja tretiraju ga kao temeljnog ali naivnog junior evaluatora: koristan za prvi prolaz, nikada se ne smatra finalnim odgovorom, uvek u paru sa čovekom koji poznaje proizvod.

Alati

Workbook-ovi i šabloni heurističke evaluacije: besplatan workbook PDF od NN/g, Maze šablon, Eleken UX heuristic evaluation forma, Figma plagin za heurističku evaluaciju, CSIR šabloni promptova od AIPrm.

Beleženje u tabelama i dokumentima: Google Sheets, Airtable, Notion baze — standardni format za beleženje problema sa redom po zapažanju i doslednim kolonama.

Vizuelni workspace i konsolidacija: Miro, Mural, FigJam — korisni u fazi konsolidacije gde tim grupiše stikere po temama; napravi jedan prostor po evaluatoru pre sastanka konsolidacije.

AI-asistirana heuristička evaluacija: Claude, GPT-4o, Gemini za prvi prolaz pregleda screenshot-ova; Heurilens za automatizovanu evaluaciju prema Nielsenovim heuristikama; specijalizovani GPT-ovi obučeni na Nielsenovim heuristikama; AI komponente Lookback, Marvin i Dovetail za sintezu izlaza više evaluatora.

Unakrsne provere pristupačnosti: WAVE, axe DevTools, Stark za Figma, Lighthouse i ekstenzija Microsoft Accessibility Insights — uparite ih sa heurističkom evaluacijom kada je pristupačnost u opsegu.

Alati za anotirane screenshot-ove: CleanShot X, Snagit, Loom (za video walkthrough), Markup.io, Shottr — koriste se za prikačivanje vizuelnih dokaza koje svaki problem potrebuje u readout-u.

Dobro se kombinuje sa

Usability Testing Moderated (Ut) — Moderirano testiranje upotrebljivosti: Heuristička evaluacija je kanonska priprema za moderirano testiranje upotrebljivosti. Prvo pokreni heurističku evaluaciju da očistiš očigledne probleme, zatim pokreni testiranje upotrebljivosti da fokusiraš pitanja na koja samo pravi korisnici mogu da odgovore. Nielsen Norman Group dokumentuje ovo uparivanje trideset godina.
Cognitive Walkthrough (Cw) — Kognitivni walkthrough: Obe metode su ekspertske inspekcije, ali postavljaju različita pitanja — heuristička evaluacija proverava dizajn prema principima, kognitivni walkthrough proverava da li korisnik koji prvi put dolazi može da otkrije sledeći korak na svakom ekranu. Pokretanje zajedno daje potpuniju sliku za rane faze dizajna.
Accessibility Testing (At) — Testiranje pristupačnosti: Heuristička evaluacija i testiranje pristupačnosti obe inspektuju interfejs na usklađenost sa pravilima; uparivanje u istom prolazu hvata probleme koji krše i Nielsenove heuristike i WCAG, i proizvodi jedan zajednički backlog umesto dva.
Analiza sadržaja: Kada heuristička evaluacija iznese klaster “Sadržaj i terminologija”, prati ga analizom sadržaja pravih korisničkih povratnih informacija (tiketi podrške, recenzije) da bi potvrdio da li problemi terminologije koje su evaluatori označili stvarno spotiču žive korisnike.
Survey (Sv) — Anketa: Kratka post-task anketa (npr. SUS ili SUPR-Q) na pravim korisnicima dopunjuje heurističku evaluaciju kvantifikujući opaženu severity problema sa korisničke strane. Zajedno proizvode daleko ubedljiviji poslovni slučaj nego pojedinačno.

Primer iz prakse

B2B SaaS kompanija isporučila je novi dashboard za cene i naplatu za svoje enterprise klijente i počela da vidi skok od 30% u tiketima podrške sa žalbom “ne mogu da pronađem fakturu” u dve nedelje od pokretanja. Produktni menadžer hteo je da razume uzrok pre nego što odobri redizajn i imao je nedeljni budžet. Pokretanje testa upotrebljivosti trajalo bi tri nedelje uz regrutaciju, a timu podrške trebao je odgovor brže.

Lid istraživač je sprovela heurističku evaluaciju za tri dana. Definisala je opseg kao “enterprise admini koji pokušavaju da nađu i preuzmu svoje fakture za poslednja tri meseca”, uzela 10 Nielsenovih heuristika plus brz WCAG 2.2 prolaz i regrutovala dva dizajnera iz susednih timova kao drugog i trećeg evaluatora. Svaki evaluator je prošao flow dvaput (jedan sat orijentacionog prolaza praćen dvosatnim evaluacionim prolazom) i beležio nalaze u deljenom Google Sheet-u u strogom formatu: ekran, element, heuristika, šta se kvari, severity, preporučena popravka. Takođe je hranila screenshot-ove u Claude sa custom promptom koji je sproveo prvi prolaz prema istim heuristikama, a zatim koristila izlaz modela kao četvrtog “junior evaluatora” — prihvatajući neke nalaze i prepisujući druge tamo gde je Claude pogrešno pročitao kontekst.

Konsolidacija je trajala pola dana i iznela 38 problema u šest tema. Glavni nalaz bio je nedvosmislen: redizajn je premestio preuzimanje fakture sa primarne akcije na landing strani naplate u pod-flow sa tri klika unutar taba “Istorija naloga”, što je kršilo heuristike #6 (recognition rather than recall) i #7 (flexibility and efficiency of use) i objašnjavalo skoro sve tikete podrške. Glavna preporuka bila je iznošenje dugmeta “Preuzmi poslednju fakturu” na landing stranu naplate; inženjerski napor procenjen je na pola sprinta. Popravka je isporučena dve nedelje kasnije, tiketi podrške su se vratili na baseline u nedelju dana od izdanja, a heuristička evaluacija je koštala oko 18 sati istraživačkog vremena kroz tim — naspram 60+ sati koje bi uporediv test upotrebljivosti zahtevao.

Greške početnika

Preskakanje nezavisnog prolaza

Najveći pojedinačni način otkaza je dozvoliti evaluatorima da vide međusobne nalaze pre nego što je nezavisan walkthrough završen. Ceo statistički slučaj korišćenja 3–5 evaluatora je da svaki hvata drugačiji podskup problema; ako se sinhronizuju rano, sažimaš tri perspektive u jednu i pokrivenost pada na otprilike koliko bi jedan evaluator uhvatio sam. Uvek pokreći nezavisan prolaz u privatnim sveskama ili odvojenim listovima, i deli liste samo na sastanku konsolidacije.

Beleženje mišljenja umesto zapažanja

Beleške poput “ovo deluje zbunjujuće” ili “raspored je neuredan” beskorisne su u konsolidovanom backlog-u jer niko ne može da deluje po njima. Svaki problem mora da uključi konkretan element, vidljivo ponašanje, heuristiku koju krši i konkretnu preporučenu popravku. Disciplina pisanja “Submit dugme ostaje sivo bez poruke o grešci kada je polje email-a prazno (#9 — error recovery)” umesto “forma je bagovita” je ono što odvaja heurističku evaluaciju koja vodi ka popravkama od one koja se ignoriše.

Tretiranje svakog kršenja heuristike kao pravog problema

Heuristike su smernice, ne zakoni. Hamburger meniji krše “recognition rather than recall” ali su pravi izbor za većinu mobilnih dizajna. Confirm-modali krše “user control and freedom” ali su neophodni za nepovratne akcije. Heuristički evaluator koji označava svako udžbeničko kršenje bez provere da li je kompromis nameran proizvodi bučan izveštaj koji gubi kredibilitet u dizajn timu. Uvek proveri nameru dizajna pre nego što zalogiraš kršenje kao pravi problem.

Mutna ili nedosledna severity skala

Severity je poluga koja pretvara 38 problema u listu od 5 stvari koje treba popraviti u ovom sprintu. Ako dva evaluatora rade sa različitim mentalnim modelima “minor” naspram “major”, spojeni backlog je besmislen. Izaberi jednu eksplicitnu skalu (4-stepena cosmetic/minor/major/critical ili Nielsen-ova 0–4), definiši svaki nivo jednom rečenicom-testom (“da li blokira završetak zadatka?”), i ponovo kalibriši na sastanku konsolidacije svaki put kada se evaluatori ne slažu.

Preskakanje koraka prioritizacije

Heuristička evaluacija koja se završava tabelom od 47 redova bez action plan-a retko vodi bilo kakvoj popravci. Tim dobija dokument, jednom ga prelista i vraća se na postojeći roadmap. Uvek završavaj projekat eksplicitnom top 5–15 prioritizovanom listom ocenjenom po severity, učestalosti i poslovnom uticaju, i prezentuj je lično umesto slanja tabele. Razgovor na readout-u je mesto gde se popravke obavezuju.

AI prompti za ovaj metod

4 spremnih AI prompta sa placeholderima — kopirajte i popunite svojim kontekstom. Svi prompti za heurističku evaluaciju →.