Repetisjonsspørsmål for BID180 Interaksjonsdesign

En gjennomgang/evaluering, veiledet av et sett med heuristikker (heuristikk = læren om de metoder som brukes til å oppnå nye vitenskapelige resultater), hvor man kan vurdere UI fra et ekspertperspektiv. Heuristisk evaluering er en av de mest uformelle metodene innen usability-inspeksjon.

Ulempene:
- Ikke sikkert viktige feil blir oppdaget
Ekspertene er ikke representative brukere av systemet.
Eksempel: BankID-leseren til bankene som kan holdes to veier

- Mange trivielle feil/småfeil er ofte oppdaget
Ekspertene leter etter feil og finner derfor mange. Mange er kanskje uviktige.

- Ekspertene har mye forutinntatt
Meninger om hvordan noe bør være

Mindre ulemper:
- Kan være vanskelig og dyrt å finne eksperter
- At man kommer frem til ulike problemer og at løsningene er svært ulike fra firma til firma. Kunnskapen til den som utførerer evalueringen har veldig mye å si for resultatet samt at resultatet vil variere fra gang til gang.

Kan godt brukes i tidligere faser for å avdekke og forhindre større feil. Dette gjør at man får rettet dette før man går til brukertesting.

Eksempel – mange firma, mange løsninger:
«Eksemplevis ble hotmail testet av åtte firmaer. 300 problemer ble identifisert, ett problem ble identifisert av alle firmaer, 76% av problemene ble bare identifisert av ett firma, og alle firmaer kom med forskjellige rapporter i etterkant.»
Sakset fra:

http://vaj.no/2003/11/om-heuristisk-metode/

Empiriske bevis foreslår at gjennomsnittelig 5 evaluatorer identifiserer 75-80% av usability-problemene. Hvis man kjører på med flere, så vil man få mindre og mindre igjen hvor hver evaluator man bruker ekstra.

«I de fleste tilfeller av negative brukeropplevelser, finner vi brudd på grunnleggende regler for utforming av programvare»

Fiks programmet heller!

Eksempel: SAS, ansvarlig for internettbooking:
«… årsaken til noe av problemene har vært at kundene har misforstått informasjonen på nettsiden, og har avbrutt bestillingen før den har vært gjennomført …»

Kilde/Fra: ID10 intro a.pdf

Det bør likevel støttes opp med observasjoner og svarene man får bør vurderes.

Eksempelvis kan et nytt datasystem se veldig flott ut for brukeren («bedre enn det gamle», «stillig», etc), men observasjonene kan vi notere oss at de jobber mer tungvint, stresser mye og gjorde mange feil.

Eksempel på observasjon i brukertest av Sandnes kommunes nettsted:
- Mange klikk for å komme til rett sted (Forside->Renovasjon->Tømmekalender->PDF).
- Lange lenke-samlinger og informasjonssider
Hvis dette var en oppgave som ofte bør antall klikk reduseres. Lange lister og informasjonssider gir stress hos brukeren. Førte i testen til at mange gikk forbi sider hvor lenke til svaret var.

Ofte et grafisk brukergrensesnitt det er snakk om.

Usablility/brukskvalitet kan dermed objektivt måles i motsetning til user experience.

Kilde for Wikipedia (punktlisten): Usability Engineering, Addison-Wesley 1993
Også sjekket mot bok.

Eksempel:
- At varen man ønsket å opprette er opprettet

Fra Wikipedia:
«The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.»

Eksempel:
-

Fra Wikipedia:
«The system should speak the user’s language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.»

Eksempel:
- Undo/redo (angre/gjør omigjen) er en måte brukeren har kontroll over systemet og kan komme tilbake på. Hvis man ikke har andreknapp, så vil brukeren selv måtte pønske ut hvordan man skal gjøre om en handling. Gjør også at arbeid går senere fordi brukeren må være sikker på at det som blir gjort er rett. Programeksemepel: Gemini Oppmåling
- Skjema uten tilbakeknapp kan f.eks. gjøre brukeren stresset ved at han mister kontroll over systemet.

Fra Wikipedia:
«Users often choose system functions by mistake and will need a clearly marked «emergency exit» to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.»

Eksempel:
- Hvis man bruker ordet «Lagre» om en handling, så skal ikke dette hete «Spar til senere» en annen plass i systemet. Hvis ikon for lagring er en diskett, så bør ikke ikonet for lagring senere være et kjøleskap.
- Vare heter vare overalt og ikke også produkt
- Alltid bruke «Ny» om å lage et nytt objekt («Ny vare», «Ny bruker», osv) og ikke også «Opprett»

Fra Wikipedia:
«Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.»

Eksempel:
-
- Mulig eksempel: I forbindelse med nettsider, så kan validering av data skjer på klientsiden mens brukeren skriver i stede for å presentere en feilmelding for dataene som ikke er gyldige etter at brukeren har sendt skjema til server.

Fra Wikipedia:
«Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.»

Eksempel:
-

Fra Wikipedia:
«Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.»

Eksempel:
-

Fra Wikipedia:
«Accelerators—unseen by the novice user—may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.»

Eksempel:
- Sandnens kommune har mye informasjon som ikke er nødvendigvis relevant i de aller fleste tilfellene.

Fra Wikipedia:
«Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.»

Eksempel:
- Ikke skriv «Oh oh oh!» som feilmelding.
- Bluescreen i Windows

Fra Wikipedia:
«Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.»

Eksempel:
-

Fra Wikipedia:
«Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.»

Når man lager en konseptuell modell for et system, så må man se på hvordan det vil oppleves av brukerne. Hvordan de vil forstå det.

«a high-level description of how a system is organized and operates» (Johnson and Henderson, 2002, p 26)

Hovedkomponenter:
- Viktige metaforer og analogier som blir brukt til å forsto hva et produkt er til og hvordan det blir brukt for en aktivitet.
- Konsepter som brukeren blir utsatt for gjennom bruken av produktet
- Relasjoner mellom konsepter
- Sammenhengene mellom konseptene og brukeropplevelsen som produktet er designet for å håndtere.

LEGG INN VIDERE FRA NOTES KAP 2

Eksempel:

Eksempel på dårlig:
- «Ojojoj» er hele teksten. Gir ikke noe forklaring som brukeren kan forstå. Peker ikke på løsning.

Eksmepel på god:
-

Eksempel på dårlig bruk er lister med alle verdens land. Hvis man i tillegg har noen land på toppen, så blir ikke listen alfabetisk heller.

User experience goals er subjektive målsetninger som går på hvordan brukerene føler om et system. «Jeg synes det var litt kipt». Fun, rewarding, boring, helpful, exciting, engaging, osv. Mange slike —— kan brukes for å vurdere user experience goals.

Eksempler:
Usability goals: Ved IT-anskaffelser så kan det settes et mål om at 90% av brukerne skal nå et mål om å gjøre en handling innen en gitt tid (effektivitet). Kan også være tid det tar å lære en oppgave (lett å lære) eller antall feil gjort hvis man utførerer en oppgave over tid (lett å huske)

User experience goals: Et program skal være gøy å bruke eller at det ikke skal være irriterende.

Har man f.eks. 10 personer, så kan man dele de i 2 omtrent like representative grupper for å teste de to prototypene.

De samme personene kan brukes til å teste prototyper på vidt forskjellige funksjonsområder.

Eksempel:
- Hvis systemet ikke gir melding tilbake om at produksjon blir registrert, så kan det hende brukeren registrerer på ny.
- Kaffe-kanne med status åpen eller lukket for helling. Første man åpner den og lar den stå åpen etter å ha helt kaffe. Neste man lukker, forsøker å tømme og ingenting kommer. Han gjør handlingen en gang til.
- Kaffe-kanne hvor man ikke ser innholdet og man forsøker å helle uten at det er noe igjen.

Eksempel:
-

Ved manglende tilbake-muligheter vil det bli tungvint for brukeren. Han må kanskje trykke gjennom hele skjemaet som kanskje registrerer noen data i systemet. Da vil feil oppstå også.

Ved manglende angre-muligheter vil han være mye mer forsiktig siden andremuligheten ikke er tilstede.

Eksempel
-

Eksempel:
- Bruker «produkt» en plass i systemet og bruker «vare» en annen plass. Vil da produkt og vare være det samme?

Eksempel:
-

Eksempel:
- Manglende tastatursvarveier er noe som ofte oppstår. For en n00b-bruker, så vil den ikke merke noe. Ekspertbrukere (1337-bruker) vil savne dette.

Eksempel:
- Kommunale nettsteder har ofte for mye informasjon på en og samme side. Netstedet har da ofte mye informasjon som brukeren ikke er på jakt etter og man bruker lengre tid på å scanne gjennom informasjonen.

Eksempel:
- Oj oj oj.
- Blue screen i Windows.

High fidelity = veldig likt det ferdige produktet. F.eks. omtrent samme materialer som i det ferdig produktet. Eller for software, så er dette oppsett av skjermbilder digitalt og som kan tilsynelatende fungerer.

Low fidelity = papirmodell, skisser på papir. Kan også være en trekloss av mobilen som skal lages.

Throwaway = Prototypen blir laget, men ender ikke opp i det endelige produktet. Er ikke en funksjonell prototype. Prototypen blir kastet for hver gang, men vi tar med kunnskapen videre.

Eksempel – Throwaway: paper prototyping, low fidelity
Eksempel – Throwaway: GUI Builder, high fidelity, men ikke funksjonell. «Click dummy».

Vertikal = Viser detaljert om en enkeltfunksjon.

Eksempel:
Nettside med forside, galleri, kontaktskjema, artikkelside, søkemotor

Horisontal:
Viser grunnleggende hvordan de ulike delene ser ut, men har ikke detaljer på hver side.

Vertikal:
Har prototype med detaljert hvordan kontaktskjemaet skal fungere, men ingenting på de andre.

Se under for mer utfyllende

Advantages of prototyping
Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software.[8]

Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications.[7] The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they said. Since users know the problem domain better than anyone on the development team does, increased interaction can result in final product that has greater tangible and intangible quality. The final product is more likely to satisfy the users desire for look, feel and performance.

Disadvantages of prototyping

Insufficient analysis: The focus on a limited prototype can distract developers from properly analyzing the complete project. This can lead to overlooking better solutions, preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain. Further, since a prototype is limited in functionality it may not scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if developers are too focused on building a prototype as a model.

User confusion of prototype and finished system: Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished. (They are, for example, often unaware of the effort needed to add error-checking and security features which a prototype may not have.) This can lead them to expect the prototype to accurately model the performance of the final system when this is not the intent of the developers. Users can also become attached to features that were included in a prototype for consideration and then removed from the specification for a final system. If users are able to require all proposed features be included in the final system this can lead to conflict.

Developer misunderstanding of user objectives: Developers may assume that users share their objectives (e.g. to deliver core functionality on time and within budget), without understanding wider commercial issues. For example, user representatives attending Enterprise software (e.g. PeopleSoft) events may have seen demonstrations of «transaction auditing» (where changes are logged and displayed in a difference grid view) without being told that this feature demands additional coding and often requires more hardware to handle extra database accesses. Users might believe they can demand auditing on every field, whereas developers might think this is feature creep because they have made assumptions about the extent of user requirements. If the developer has committed delivery before the user requirements were reviewed, developers are between a rock and a hard place, particularly if user management derives some advantage from their failure to implement requirements.

Developer attachment to prototype: Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture. (This may suggest that throwaway prototyping, rather than evolutionary prototyping, should be used.)

Excessive development time of the prototype: A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex. When the prototype is thrown away the precisely developed requirements that it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype. Users can become stuck in debates over details of the prototype, holding up the development team and delaying the final product.

Expense of implementing prototyping: the start up costs for building a development team focused on prototyping may be high. Many companies have development methodologies in place, and changing them can mean retraining, retooling, or both. Many companies tend to just jump into the prototyping without bothering to retrain their workers as much as they should.

Kilde: http://en.wikipedia.org/wiki/Software_prototyping#Advantages_of_prototyping

Konsekvenser:
- Testpersonen kan føle seg utilpass med kameraet tilstede.
Muligens testpersonens oppførsel endres pga. kameraet.
- Økt kompleksitet.
Mer teknisk utstyr. Må skaffes, kobles opp, fungere, kobles ned. Ikke så gale hvis man har permanent oppsett (ala Finn Labs).

Fordeler:
- Enklere og kjappere å gjennomføre
- Får luket ut mange feil
- Gode eksperter (kan domenet og problemområdet godt) vil lage gode vurderinger

Ulemper
- Eksperter er ikke representative og klarer ikke alltid å se noen store problemer.
- De finner ofte små og trivielle feil som ikke nødvendigvis er noe som bør bli brukt tid på. Lager forstyrrelse. De ønsker å finne mange feil for å «fortjene» lønnen sin.

Brukeren trykker flere ganger/gjør ting på ny.

Eksemepl på brudd: System som registrerer varer og det ikke blir gitt tilbakemelding. Da kan det være de registrerer flere ganger eller at varer ikke er registrert.

Tiltak: gi tilbakemelding om det bakenforliggende systemet har registrert handlingen.

PC:
- Kan ha en trykkbar versjon av prototypen.
- Bruker skjerm som fremvisningsmedium. Får frem mer om testpersonen «scanner» gjennom teksten i grensesnittet.
- Begresning: brukeren tror fort det er touchbasert

Utfordringer:
- Noen snakker mer enn andre.
- Noen kan bli stresset av situasjonen.

Begrensninger:
- Brukerens ståsted påvirker det som blir sagt. F.eks. at det nye systemet var knallbra, men brukeren vet ikke bedre.

Ulemper:
- Får ikke meg seg den non-verbale kommunikasjonen. Får ikke observert annet enn det som blir sagt høyt (ikke hvordan han beveger musa, hvor blikket er osv.).
- Vanskeligelig å følge brukeren for hvert klikk.
- Varierende testutstyr hos testpersonen. Forskjellig oppløsning, nettleser, osv. Men igjen så kan dette bli sett på som representativt for brukermassen.