You are on page 1of 9

Upotrebljivosti Heuristika

Jednostavan I prirodan dijalog Korisniki interfejs bi trebalo maksimalno pojednostaviti, poto svaka dodatna informacija na ekranu predstavlja jednu stvar vie za nauiti, pogreno interpretirati I pretraiti. Interfejsi bi trebalo da odgovaraju korisnikovom zadatku na najprirodniji mogudi nain kako bi mapiranje izmeu kompjuterskih koncepta I korisnikih bilo to jednostavnije , a korisnikova navigacija kroz interfejs minimalizovana. Ideal ka kome se tei je prezentovanje tane informacije koju korisnik trai u tano vreme kad se ona potrebna. Grafiki dizajn I boja Dobar grafiki dizajn je bitan za postizanje jednostavnog I prirodnog dijaloga u modernim kompjuterskim sistemima sa grafikim korisnikim interfejsom ( Marcus 1992 ) . Pored dobijanja pomodi od strane grafikog dizajnera postoje I druge opcije koje mogu dovesti do jednostavnijih dijaloga. Koristedi mumble screens moemo prototipirati izgled ekrana (kao to je prikazano na figuri11 gde je sav tekst zamenjen slovima m) abstrahovajudi detalje sadraja I fokusirajudi se sa problem sa prikazom. Za izgled ekrana trebalo bi koristiti getalt pravila ljudske percepcij ( Rock I Palmer 1990) da bi se povedalo korisnikovo razumevanje veze izmeu dijalognih elemenata. Prema ovim pravilima stvari se posmatraju ujedinjeno/grupisano ako su blizu jedna drugoj, ako su zatvorene linijama I boksovima, ako se pomeraju I menjaju zajedno, lie po obliku, boji,veliini ili tipografiji.. Primer na figuri 12 bi vedina ljudi percipirala kao dve velike grupe objekata usled brlizine istih u grupi porededi sa udaljenodu dve grupe. Dalje bi vedina ljudi smatrala da levi set objekata sadri dva seta objekata koji su jo srodniji zbog postojanja kudita na est objekata u gornjem desnom uglu I isticanja etri objekta u donjem levom uglu. Desni set objeketa de percepirati kao da sadri tri grupe, sredinja grupa de odskakati od pozadina poto je manja. Pomenuti principi grafike structure trebaju da se koriste kako bi se pomoglo korisniku da razume structure interfejsa. Na primer meni moe da koristi liniju za odvajanje ili kodiranje bojom ( McDonald 1988) kako bi podelio opcije u srodne grupe, od kojih de svaka biti jednostavnija za razumevanje poto de se svaka opcija percipirati u relevantnom kontekstu. Slino dialog boxes mogu da grupiu srodne opcije I zatvore ih u kutije ili odvoje linijama I belim poljima. Poto de korisnik percipirati structure prema prezentovanim principima, treba voditi rauna da se ne grupiu nepovezani objekti na nain na koji bi delovalo da pripadaju zajendo. Uzmimo primer bankarske izjave sa slededin layoutom: Balans $1,000. OO[

$2,000.00 ta je balans? Hiljadu ili dve hiljade dolara? Pravilo blizine de navesti mnoge ljude da percipiraju obeleje Balans povezano sa brojem $2 000 , iako je moda namera bila da ta oznaka sadri broj $1000. Principi grafikog dizajna mogu takoe pomodi korisnicima da prioritizuju svoju panju na ekran tako to de napraviti da najbitniji detalji budu primetnji od manje bitnih. Kao to se moe primetiti na desnom delu Figure 12, male oblasti bez linija de odskakati od pozadine, ovo se moe postidi I hajlajtovanjem na razliite naine jarkim bojama, tipografijom, vedim fontom. Takoe informacija koja je prva prezentovana , ako uzmemo u obzir uobiajne korisnike direkcije ( sa leve strane na vrhu u mnogim kulturama) bi trebala da privue vie panje. Upotreba treperujudih objekata za ovu shvrhu se preporuuje samo u ekstremnim sluajevima, poto esto odvradaju panju I iritiraju. Na alfanumerikim terminalima UPPERCASE MOE TAKOE DA SE KORISTI DA SKRENE KORISNIKOVU PANU, ali ovu metodu treba koristiti tedljivo poto je u proseku 10% sporija za itanje neko tekst sa mixedcase. Pri koridenju boje u dizajnu ekrana ( Rice 1991; Travis 1991) ovo su tri najvanija orijentira: Bez preterivanja. Najbolje je ograniiti dizajn na par konzistentno ponovljenih boja. Kodiranje boja bi trebalo ograniiti na ne vie od 5 do 7 razliitih boja poto je teko memoristai I razlikovati vedi broj ( napredni korisnici su u stanju da razlikuju oko 11 boja ( Durret I Trezona 1982) ). Svetle sive I zadimljeni pastel su esto bolja opcija za pozadinu nego vritede boje. Postarajte se da se interfejs moe koristiti bez boja. Uzmite u obzir da je jedan deo populacije pati od daltonizama, stoga kolor kodirane informacije treba dopuniti redudantnim znacima koji de omoguditi tumaenje ekrana ak I bez mogudnosti diferencijacije boja. Primera radi ikone koje treba da se obriu mogu promeniti boju u crvenu radi brze indentifikacije, ali takoe mogu biti oznaene I znakom X. Najbolje bi bilo testirati system sa jednim brojem koristina koji pate od daltonizma, meutim ovo ne bi bilo sveobuhvatno poto postoje mnogi pojavni oblici istog. Dobro bi bilo proveriti kako interfejs izgleda na monohromnim ekranima, poto su neki korisnici ogranieni na koridenje istih. Pokuajte da koristite boje radi kategorizacije, diferencijacije I obeleavanja, a ne radi davanja informacija, posebno ne kvantitativnih informacija.

Pravilo da je manje vie nije upotrebljivo u informacionom sadraju ekrana ni za izbor opcija I interakcijskih mehanizama programa. esta dizajn-zamka je ovo verovanje da pruaje mnotva opcija I vie naina njihovog izvoanja moe zadovoljiti svaije potrebe. Ponekad moemo kreirati dizajn specijalno za korisnike poetnike sa jednostavnim interfejsom koji ih titi od nepotrebne kompleksnosti koja treba naprednijim korisnicima. Vedina sistema koja ovo praktikuje obino ima dva nivoa interfejsne kompleksnosti poetniki mod I ekspertski mod, ali u principu je mogude obezbediti vie ugneenih nivoa zarad povedane kompleksnosti. Ova nested dizajn strategija se ponekad zove training wheels ( varroll 1990)

5.2 Govoriti korisnikovim jezikom Za korisnik-centrini dizajn neophodno je izbagavati sistemske termine umesto kojih treba korisniki interfejs bazirati na terminologiji iz korisnikovig jezika. Naalost, mogudnost da se sam korisnik pita kakav jezik eli da vidi u interfejsu nije praktino izvodljiva jer dovodi do fenomena verbalnih nesuglasica, poto postoji toliko razliitih rei I sinonima koji se koriste za oznaavanje iste stvari. Furnaes et al (1987) je otkrio da je verovatnoda da dva koristika oznae istog imenitelja ne veda od 7-18% u zavisnosti od fenomena koji treba imenovati. ak I kad bi pitali vie korisnika I iskoristili ime koje je pomenula vedina I dalje je to 15-36% korisnika ije je ima prolo izbor, to znai da ostatak ostaje nezadovoljan izabranim nazivom. Mnogo bolju alternative predstavlja glasanje, gde bi korisnici dobili da glasaju za par imena sa kreirane liste. Ovakve liste se mogu napraviti na vie naina ukljuujudi ideje eksperata korisnikih sistema, uz pomod razliitih anketiranja korisnika, developera itd. U jednom eksperimentu (Bloom 1987-88) imena za features mail merge sistema su bila odabrana na tri razliita naina: Tehniki termini po sugestijama originalnih developera sistema: polje variabli, token karakteri, snimci, delimetri itd. Termini predloeni od strane vedine korisnika kad sui m dati kratki opisi koncepata: deo, marker, jedinica, period itd. Pobednika imena izvuena glasanjem kada su korisnicima dali vie alternativnih termina na koje su oni glasali: komponenta, placeholder, informacija, paket, odvaja itd.

Mapiranje I Metafore Metafore korisnikih interfejsa ( Carroll et al. 1988; Wozny 1989) predstavljaju mogude naine uspostavljanja mapiranja izmeu kompjuterskog sistema I nekog referentnog sistema poznatom korisnicima iz realnosti. Primera radi, operacija brisanja faila je esto bila predmet metafore u grafikim korisnikim interfejsima sa ikonicom u obliku kante za smede, crne rupe, sekaa papira koji simboliu brisanje. Premda ne moemo redi da je crna rupa korisnik-centrina, sve ove ikone predstavljaju metodu povezivanja korisnikovih iskustava I znanja iz ivota sa konceptom brisanja kompjuterskih failova. Problem se pojavljuje kod sigurnosti podataka. Naime, najsavremeniji operativni sistemi ne briu sadraj faila sa diska kada je fajl izbrisan. Najede je jedini rezultat brisanja faila oslobaanje mesta koje de iskoristiti drugi failovi u bududnosti. Ovo praktino znai da de biti mogude itanje izbrisanog faila sve dok se preko njega u memoriji ne overwrituje neki drugi fail. Korisnici koji imaju osetljive podatke na diskovima ne mogu da se oslone na brisanje failova kao opciju koja im osigurava dokumente u sluajevima kada neko drugi ima pristup njihovom prostoru na disku ( kad je prodat ili poslat na popravku nap.). 5.3 Minimizovanje korisnike memorijske opteredenosti ( memory load)

Kompjuteri imaju sposobnost veoma dobrog pamdenja, stoga bi trebalo u to vedoj meri smanjiti opteredenje pamdenja korisniku.Generalno je ljudima lake da se sete informacija ukoliko im je ponovo prikazana , nego kad treba da se oslone na sopstveno pamdenje. Ukoliko je neophodno znati veliki broj pravila da bi se odredilo ponaanje sistema, onda de korisnik morati da naui I zapamti sva ta pravila to predstavlja opteredenje. Sa druge strane, ako system nije optereden pravilima, onda de korisnik trebati da naui svaki element dijaloga ponaosob, a nemogude je predvideti ponaanje elementa dijaloga ukoliko nam ved nije poznat ( I upamden) nain na koji isti radi. Koridenje generikih komanda ( Rosenberg I Moran 1984) predstavlja jedan nain putanja par pravila da upravljaju kompleksnim sistemom. Kao to je prikazano na Figuri 13, generine komande ine da se slina stvar dogodi u razliitim situacijama, inedi dovoljnim za korisnika da naui par komandi kako bi radio sa mnotvom razliitih informacija. Jedna od glavnih prednosti generikih komandi je da one podravaju transfer uenja od jedne oplikacije do druge, poto korisnik ne mora da ponovo naui komande koje ved zna ( Ziegler et al 1986) 5.4 Konzistentnost Konzistentnost predstavlja jedan od osnovnij principa upotrebljivosti. Ukoliko korisnici znaju istu komandu ili da de ista akcija uvek imati isti efekat, osedade se mnogo slobodnije u koridenju sistema I bide ohrabreni da probaju strategije istraivakog uenja poto de ved imati deo znanja koji je neophodan za upavljanje novih delova sistema ( Lewis et al. 1989). Istu informaciju treba prezentovati na istoj lokacijina svim ekranima I kutijama za dijalog, I to treba formatirati na isti nain kako bi podstakli prepoznavanje. Mnogi aspekti konzistentnosti postaju laki za postizanje ukoliko se prati korisniki interfejsni standarf u dizajniranju, poto de standard u tom sluaju spacifikovati mnoge detalje dijaloga kao nap. Kako indicirati pop-up meni ili koj typeface koristiti u listi veliine fontova. Videti Poglavlje 8 za diskusiju korisnikih interfejsnih standarda, naine povadanja potovanja istih, samim time I konzistentnosti. Naalost, potovanje standard nije dovoljno da se osigura konzistentnost, poto standardi ostavljaju veliku slobodu dizajnerima. Pogledati diskusiju o koordinaciji korisnikih interfejsa u Sekciji 4.6 (strana 90) za naine promocije konzistentnosti za vreme dizajna interfejsa. 5.5 Povratna informacija Sistem bi trebao da informie korisnika u kontinuitetu ta radu I kako interpretira korisnikove inpute. Povratna informacija ne bi trebalo da eka da se pojavi greka: Sistem bi trebalo da obezbedi I pozitivnu povratnu informaciju, kao I deliminu povratnu informaciju kad mu je omogudena. Na primer, nain za pisanje Nemakog slova ii na mnogim tastaturama podrazumeva prvo kucanje umlauta .. ; a potom kucanje karaktera koji bi trebalo d aide ispod dve take. Neki sistemi ne obezbeuju vidljivu povratnu informaciju kako prvi deo karaktera biva otkucan to navodi mnoge poetnike korisnike da zakljue da system ne ume da prepozna umlaut. Bolji dizajn bi bio da se pokae umlaut I onda promeni stralica na neki nain koji bi indicirao da system oekuje drugi deo karaktera. Vreme odgovora

Povratna informacija postaje posebno bitna u sluaju da sistemu treba dosta vremena da odgovori na odreene operacije. Osnovni savet kod vremena odgovora ostaje nepromenjen godinama ( Miller 1968, Card et al. 1991.): 0,1 sekunda predstavlja odokativni limit u kojem korisnik oseda da system odgovara simultano, stoga nikakva posebna povratna informacija nije potrebna sem prikazivanja rezultata 1.0 sekunda predstavlja odokativni limit u kojem korisnikov tok misli ostaje neprekinut iako de korisnik primetiti odlaganje. Obino nije neophodno postavljati specijalnu povratnu informaciju za vreme odlaganja koja su veda od 0,1 a manja od 1.0 sekundi, iako korisnik gubi osedaj direktnog obraivanja podataka. 10 sekundi je odokativni limit za zadravanje korisnikove panje na dijalogu. Za dua odgalanja korisnik de eleti da preduzme neki drugi zadatak dok eka da kompjuter zavri predhodni, s toga treba m dati povratnu informaciju koja indicira kada kompjuter oekuje da de biti gotov. Povratna informacija za vreme odgalanja je posebno vana ako se oekuje da vreme odgovora dosta varira, poto korisnici nede znati ta da oekuju.

Preporuuje se za procese u trajanju due od 10 sekundi koridenje procentno obeleavanje progresa. Indikatori progresa imaju tri osnovne prednosti: uverava korisnika da system nije pao I da radi na njegovom ili njenom problem, korisnik zna odokativno koliko de vremena trebati da se operacija obavi I moe da radi druge stvari za to vreme I ima ta da gleda na ekranu, pa je samim time ekanje manje naporno.

Neuspeh sistema Povratna informacija bi trebalo da se da I u sluaju neuspeha sistema. Mnogi sistemi nisu dizajnirani da daju ovu informaciju I jednostavno prestanu da odgovaraju korisniku kad se ugase/poremete. Naalost, nedostatak povratne informacije predstavlja gotovo najgoru mogudu povatnu informaciju poto ostavlja korisnika da pogaa ta je polo naopako. 5.6 Jasno obeleeni izlazi Korisnici ne vole da se osete zarobljenim u kompjuteru. Kako bi se povedao osedaj kontrole dijaloga korisnika system bi trebao da ponudi lak izlaz iz to vie situacija. Primera radi, dijalog kutija I sistemska stanja bi trebalo da imaju dugme za otkazivanje ili druge naine izlaska kako bi vratili korisnika nazad u preanje stanje. U mnogim sluajevima, izlaz se moe ponuditi u obliku undo naina izlaska koji vrada u preanje stanje system ( Abowd and Dix 1922; Yang 1922). Korisnici brzo naue da se oslanjaju na postojanje undo opcije., tako da bi trebalo istu ugraditi svuda po sistemu kao generiku komandu koja vrada u preanje stanje mnoge sistemske promene . Razni izlazi I undo opcije bi trebali da budu vidljivi u interfejsu I nezavisni od korisnikove mogudnosti pamdenja specijalnog koda ili obskurne kombinacije dirki.

Vidljivost je posebno znaajna za podravanje izlaza, poto de se korisnicima trebati ovaj mehanizam u sluaju da se nau na nepoznatoj teritoriji i uplae se od gubitka podataka ukoliko naine pogrean korak. 5.7 Preice Uprkos tome to bi trebalo biti mogude upravljanje korisnikim interfejsom uz pomod par optih pravila, trebalo bi takoe omoguditi naprednim korisnicima bre upravljanje sistemom uz par dialokih preica. Tipini naini ubrzavanja rada ukljuuju skradenice, imanje funkcionalnih dirki ili komandnih kljueva koji pakuju itavu komandu u jedan pritisak dugmeta, dupli klik na objekat da bi se obavila najuobiajnija operacija na istom, imanje dugmida preko kojih je mogude pristupiti vanim funkcijama direktno iz onog dela dijaloga gde su najede potrebne. Pen kompjuteri, virtuelne realnosti I odreeni interfejsi mia mogu takode koristiti gestove I ubrzanja. Korisnici bi trebalo da mogu da koriste svoju interakcijsku istoriju ( Greenberg 1993). Studija komandno-linearnog sistema je pokazala da je 35% svih komanda indentino sa onih pet predhodnih komanda I da je 74% komanda bilo bilo dato barem jednom ranije ( Greenberg I Whitten 1988). 5.8 Poruke o dobrim grekama Situacija se grekama su kritine za upotrebljivost iz dva razloga: Prvo, po definiciji predstavljaju situaciju gde korisnik ima potekoda I potencijalno de biti onemoguden da koristi system na nain koji de ga dovesti do eljenog cilja. Drugo, oni predstavljaju prilike za pomod korisniku da bolje razume system ( Frese et al. 1991) poto je korisnik obino motivisan da obrati panju na sadraj poruke o greci I poto de kompjuter esto imati neko znanje o prirodi problema u kome se naao. Poruke sa grekom bi trebale da prate etri jednostavna pravila ( Shneiderman 1982): Sroene jednostavnim jezikom izbegavajudi opskurne kodove Precizne pre nego generalne I nejasne Trebalo bi da konstruktivno pomognu korisniku da rei problem Trebalo bi da budu pristojne I da ne zastrauju korisnika ili okrivljuju za greku eksplicitno korisnika, poto je korisniku ved dovoljno loe kad napravi greku

Pored imanja dobrih poruka o greci, sistemi bi trebali da imaju I dobar system oporavka od istih. Na primer, korisnici bi trebalo da imaju dozvolu da ponite efekte grekonosnih komandi, takoe bi trebalo da mogu da izmene I ponovo zadaju predhodnu komandu bez potrebe unoenja iste od poetka.

Multiple-Level poruke Najrasprostranjeniji nain implementacije ovog tipa poruka je imanje dva nivoa I zamena kratke inicijalne poruke sa dugmetom koje moe da se klikne za vie informacija. Poruka na vie nivoa moe da ponudi dodatne informacije za arobnjake korisnike I zatiti manje napredne korisnike od istih.

5.9 Spreavanje greaka Jo bolja opcija od one preporuene u predhodnom poglavlju je da se izbegne pojava situacija koja de dovesti do greke. 5.10 Pomod I dokumentacija Iako je preporuljivo da je system dovoljno jednostavan za koridenje bez dalje pomodi ili dokumentacije, ovaj cilj nije uvek mogude postidi. Osim sistema poput automatizovanih govornih maina gde je prava walk-up-and-use upotrebivost neophodna, vedina korisnikih interfejsa ima preveliki broj karakteristika da bi moglo postojati upuctvo ili system za pomod. Sve pie u upuctvu ne bi trebalo nikada da bude izgovor dizajnera sistema kada se korisnici ale da je interfejs suvie teak. Fundamentalna istina o dokumentaciji je da vedina korisnika jednostavno ne proita istu ( Rettig 1991). 5.11 Evaluacija Heuristike Evaluacija heuristike se radi posmatranjem interfejsa I pokuavanjem formiranja miljenja o tome ta je sve dobro I loe u vezi istog. Idealno bi ljudi sporoveli takvo istraivanje prema odreenim pravilima, poput navedenih u tipinim smernicama dokumenata. Neke kolekcija smernica upotrebljivosti imaju pobrojano I do hiljadu pravila I stoga zastrauju developere. Vedina ljudi verovatno izvodi neku vrstu heuristike evaluacije intuitativno I zdravorazumski umesto na nain koji je opisan ovde ( Nielsen I Molich 1990; Nieksen 1992c, 1994b) meutima, u sistematinoj inspekciji korisnikog interfejsa dizajniranog za upotrebivost ( Mack I Nielson 1993; Nielson I Mack 1994). Cilj heuristike evaluacije je pronalaenje problema upotrebivosti u dizajnu korisnikog interfejsa kako bi se pobrinuli za iste u okviru intertativnog procesa dizajniranja. Ostale metode provere upotrebivosti ukljuuju kognitivnno prelaenje ( Lewis et ai. 1990; Wharon et ai. 19829) I analizu tvrdnji ( Carroll 1990b, Carroll et al. 1991; Kellogg 1990). Heuristika evaluacija podrazumeva postojanje malog broja evaluator koji treba da pregledaju system I ocene njegovu saglasnost sa prepoznatim principima upotrebivosti ( heuretike). Tipini set heuretika predstavlja principe koridene kao sekcije hedinga u ovom poglavlju. Figura 16 prikazuje proporcije problema upotrebivosti pronaene kad se sve vie evaluacija doda. Figura jasno pokazuje da se isplati koridenje vie od jednog metoda evaluacije, I deluje da bi bilo razumno preporuiti koridenje do pet evaluacija, a najmanje tri. Evaluacija heuristike se obavlja tako to svaki evaluator proverava interfejs sam. Tek kad su sve evaluacije gotove I evaluatorima je data dozvola da komuniciraju I suoe svoja otkrida. ( proveri da li je uvek pominjan evaluator stvarno nedu to da traim). Ova metoda je neophodna kako bi se obezbedilo nezavisno I objaktivno vienje svakog evaluatora. Rezultati evaluacije mogu biti snimljeni kao izvetaji od svakog evaluatora ili imanjem posmatraa prisutnog na evaluaciji gde bi evaluator oralno izraavali svoje miljenje u momentu dok prolaze kroz interfejs. Pisani izvetaji imaju prednost poto predstavljaju formalin zapis evaluacije, ali zahtevaju dodatni napor od strane evaluatora I takoe moraju biti proitani I procesuirani od strane upravljaa evaluacije. Koridenje posmatraa smanjuje posao evaluacije I prua mogudnost brzog dobijanja rezultata evaluacije poto posmatra treba da razume I organizuje samo svoje beleke I ne mora da ita I tumai beleke ostalih uesnika. Posmatra moe takoe da pomogne oko celog procesa evaluacije time to de upravljati interfejsom u sluaju problema I pomodi evaluatorima sa ogranienim znanjima tako to de im pojasniti odreene aspekte interfejsa. Situacija slina onoj diskutovanoj u Poglavlju 6, sa testiranjem korisnika, posmatra ( obino se

zove vrilac eksperimenta) ima odgovornosz interpretacije korisnikovih akcija kako bi saznao kako su ove akcije povezane sa problemima upotrebivosti u dizajnu interfejsa. Ovo omogudava sprovoenje testiranja korisnika ak Iako korisnici ne znaju nita o korisnikom interfejsu dizajna. Sa druge strane odgovornost analiziranja korisnikog interfejsa je na evaluator u heuristikoj sesiji evaluacije, tako da potencijalni posmatra samo treba da snimi evaluatoreve komentare o interfejsu I ne mora interpretirati evaluatoreve postupke. Kako bi napravili dalju diferencijaciju heuristike evaluacije I tradicionalnog testiranja korisnika pomenudemo elju posmatraa da odgovor na pitanja evaluatora za vreme sesije I granice do kojih evaloatori smeju dobijati pomod oko sesije. Kod tradicionalnog testiranja korisnika cilj je obino da se otkriju greke koje korisnici prave kada koriste interfejs, stoga osoba koja void eksperiment obino ne eli da pomae ispitanicima vie nego to je naophodno. Od korisnika se zahteva da otkriju odgovore na pitanja koristedi system,a ne traedi pomod od izvoaa eksperimenta. Kod heuristike evaluacije domain-specifine aplikacije bilo bi nerazumno ne odgovoriti na pitanje evaluatora, posebno ako non-domain eksperti slue kao evaluatori. Odgovaranjem na evaluatoreva pitanja omogudavamo im da bolje procene upotrebivost korisnikog interfejsa u vezi sa koridenjem domena. Slino kada evaluatori imaju problem sa koridenjem interfejsa, mogu im davati savete na koj nain da nastave sa evaluacijom I ne troe dragoceno vreme zbog problema koje imaju sa mehanikom interfejsa. Dosue, bitno je primetiti da evaluatorima ne treba pruiti pomod sve do momenta kada je jasno da su u problemu I dok ne zavre komentarisanje problema upotrebivosti. Tipino, heuristike sesije evaluacije za individualnog evaluatora traju jedan do dva sata. Due evaluacije su potrebne za vede ili veoma komplikovane interfejse sa znaajnim brojem dijalokih elemenata, ali je verovatnije da de biti neophodno ovakve sesije podeliti u vie delova od kojih de se svaki deo koncentrisati na jedan deo interfejsa. Kako evaluacije ne koriste system radi izvravanja realnih zadatakamogude je izvriti heuristiku evaluaciju korisnikih interfejsa koji postoje samo na papiru I koji jo nisu implementirani ( Nielsen 1990d). Ovo ini heuristiku evaluaciju prikladnom za upotrebu u ranoj fazi inenjeringa upotrebnog ivotnog ciklusa. Pogledati Vebu 8 na strain 273 za primer heuristike avaluacije papirnog prototipa interfejsa. Output dobijen koridenjem heuristike evaluacije je lista problema upotrebivosti interfejsa, , annotated with references to those usability principles that were violated by the design in each case in the opinion of the evaluator . Heuristika evaluacije ne prua sistematski nain generisanja reenja za problem upotrebivosti, niti nain na koji treba pridi redizajnu istog. Jo jedan nain utilizacija razliitih vrsta ekspertiza je prularistika upotrebna walkthrough tehnika ( Bias 1991), po kojoj je heruistika evaluacija izvoena od strane reprezentativnih korisnika, product developera I specijalista za upotrebivost. Heuristic evaluation does not provide a systematic way to generate fixes to the usability problems or a way to assess the probable quality of any redesigns. Users bring their subject matter

expertise to bear on the evaluation, so this variant of heuristic evaluation is especially appropriate when only "single expert" usability specialists without knowledge of the application domain are available. One benefit of the pluralistic walkthrough method is that the dual presence of users and designers allow for preliminary collection of user input early in the stages of a design. At this stage, manuals, help systems, and other documentation may not yet be available, and users might not be able to use the system unaided. In a pluralistic walkthrough session, the system designers can serve as "living manuals," allowing the users to ask the questions they would normally seek answered in the manual.