Menneske-maskin interaksjon

Get Started. It's Free
or sign up with your email address
Rocket clouds
Menneske-maskin interaksjon by Mind Map: Menneske-maskin interaksjon

1. Kvantitaive mål, tid/krefter som brukes vs faktisk oppgave

2. Konseptuell modell

2.1. Metaforer

2.1.1. Direkte knyttet til hvordan vi oppfatter verden

2.1.1.1. Tid: Spares, brukes Vann: renner ut, fyser, fordufter

2.1.2. Funksjonen er å overføre likheter mellom kjente og nye situasjoner

2.1.3. Initialiserer dannelsen av en mental modell

2.1.4. Passer sjeldent perfekt til den konseptuelle modellen

2.1.5. Brukere bruker ofte romlige metaforer for å beskrive informasjon, derfor burde det også brukes i menyer

2.1.6. Downsides

2.1.6.1. Kan gå ut på dato, f.eks. diskettsymbol for lagring

2.1.6.2. Kan skjule/vise feil sider av metafor

2.1.6.2.1. "må jeg tørke skrivebord for støv"

2.1.6.3. Begrensninger kan føles

2.1.6.4. Lett å dra for langt

2.1.6.4.1. Postrom->Skuff->nytt brev>penn......

2.1.6.5. Noen metaforer skalerer dårlig, f.eks. skrivebordsmetafor for skrivebord

2.2. Konsepter

2.2.1. Hva brukeren ser, generelt klasser

2.2.2. Hvert "konsept" har attributter og operasjoner

2.2.3. Hvis modellen består av mange konsepter kan det være forvirrende, men ofte kan de grupperes sammen eller være spesialiseringer av hverandre

2.2.4. En bruker kan tenke seg at alle konseptene kan interagere med hverandre, så kompleksiteten øker eksponensielt i forhold til antall konsepter man prøver å introdusere til brukeren

2.2.5. Noen konsepter er viktigere enn andre

2.3. Relasjon

2.3.1. Sammenheng i objekter i konsepten

2.3.2. Feks. Billett <=> Mobillett konto <=> Profil. It's all connected

2.4. Overførbarhet

2.4.1. Hvordan det virtuelle relaterer til noe i virkeligheten

2.4.2. Feks: Virtuelle bankkort = ekte bankkkort

2.5. Div

2.5.1. Ikke begynn m. layout, lag heller konseptuell modell

2.5.2. Design UI til slutt

2.5.3. Er ikke: usecase, programmering objekter

2.5.4. En konseptuell modell bør være så simpel og nær det faktiske systemet som mulig, så det blir enkelt for brukeren å forstå den

2.5.4.1. Hvis et system ikke er basert på en simpel modell kan det være at systemet blir for komplisert for brukeren

2.5.4.2. Hvis en modell ikke er nær virkeligheten kan den få brukeren til å misforstå hvordan systemet skal brukes

2.6. Designerens visjon om brukerens interaksjon

2.7. Oppgavebasert vs ikke-oppgavebasert

2.7.1. oppgave: "log hours"

2.7.2. ikke: "create record"

2.8. Lexicon

2.8.1. Man kan gi navn til atributter, konsepter, osv. Det kalles et leksikon, og gjør det lettere å passe på at navnebruken er konsistent i systemet.

2.8.2. Hjelper også så man ikke legger til flere begreper når man kunne brukt et begrep man allerede har introdusert til brukeren

3. Designretningslinjer

3.1. Universell utforming

3.1.1. Syv prinsipper for universell utforming

3.1.1.1. Like muligheter for bruk

3.1.1.1.1. Skal være like anvendbar og tilgjengelig for forskjellige personer

3.1.1.1.2. Kan løses ved å gjøre utformingen tiltalende for alle brukere.

3.1.1.2. Fleksibel i bruk

3.1.1.2.1. Gjøre det mulig å gjøre ulike valg i bruken

3.1.1.3. Enkel og intuitiv i bruk

3.1.1.3.1. Eliminere unødvendig kompleksitet

3.1.1.3.2. Forventningene til tingen stemmer med det den gjør.

3.1.1.4. Forståelig informasjon

3.1.1.4.1. Få så mye informasjon til brukeren på en så enkel måte som mulig

3.1.1.5. Toleranse for feil

3.1.1.5.1. Lage advarsler

3.1.1.5.2. Utformingen skal minske faren for feil.

3.1.1.6. Lav fysisk anstrengelse

3.1.1.6.1. Skal brukes effektivt på en enkel måte

3.1.1.7. Størrelse i plass for tilgang og bruk

3.1.1.7.1. Mulig å bruke for brukere med ulike forutsetninger

3.1.1.7.2. Feks: Tomler

3.1.2. Bygger på en relasjonell forståelse av funksjonshemning

3.1.2.1. Funksjonshemning oppstår når det ikke er samsvar mellom en persons funksjonsevner og kravene omgivelsene og oppgavene stiller.

3.1.3. Kan brukes av folk uavhengig av bakgrunn, (fysisk, kognitive, kulturelt) uten at det ser ut som om man tar hensyn.

3.1.4. Ved å designe for mangfold blir det lettere for alle å bruke

3.2. Jacob Nielsens heuristikker

3.2.1. Visibility of system status

3.2.1.1. DN visibility + feedback

3.2.1.2. Systemet burde vise status, f.eks. gjennom en progress bar

3.2.2. Match between system and the real world

3.2.2.1. Ord, begreper, ikoner: Må snakke brukerens spåk

3.2.2.2. Feks: Ikoner i Photoshop

3.2.2.3. Må beskrive ting på en måte brukeren forstår

3.2.3. User control and freedom

3.2.3.1. La brukeren være i kontroll

3.2.3.2. Med en angre-knapp føler brukeren at han har kontroll, selv om man har satt systemet i en uønsket tilstand.

3.2.4. Consistency and standards

3.2.4.1. Følg platform standarder

3.2.5. Error prevention

3.2.5.1. Fleksibilitet. "Låse" ugyldige valg. Tidsfelt: kan ikke skrive bokstav i alder

3.2.5.2. Gjøre systemet "idiotsikkert". Hvis det er vanskeligere for brukeren å gjøre feil, er det lettere å gjøre riktig.

3.2.6. Recognition rather than recall

3.2.6.1. Instruksjoner/flyt må være naturlig

3.2.6.2. Skal ikke pugge bruk

3.2.6.3. Gjør ting synlig

3.2.6.4. F.eks. hurtigtaster er recall, men hvis man er i office og trykker på "alt" (i windows hvertfall), får man opp hurtigtastene for knapper. Da har man recognition.

3.2.6.5. Forhåndsvisning av font

3.2.7. Flexibility and efficiency of use

3.2.7.1. Ha måter som en erfaren bruker kan bruke systemet mer effektivt, f.eks. shortcuts eller lignende

3.2.8. Aesthetic and minimalistic design

3.2.8.1. Det er vanskelig for en bruker å finne viktig informasjon hvis det er veldig mye informasjon på skjermen.

3.2.8.2. Hvis informasjon er irrelevant eller sjeldent nødvendig burde den skjules.

3.2.9. Error recovery

3.2.9.1. Hjelper brukeren med å unngå feil.

3.2.9.2. Hjelper brukeren med å håndtere feil.

3.2.9.3. Tilbakemeldinger burde hjelpe brukeren, ikke gi en feilkode eller dårlig beskrivende feilmelding.

3.2.10. Help and dokumentasjon

3.2.10.1. Det er best å ikke bruke dokumentasjon, men hvis man må ha så skal den være bra.

3.3. Don Norman

3.3.1. Mapping

3.3.1.1. Sammenheng mellom interaksjon og effekt

3.3.1.2. Kalles poor mapping eller natural mapping

3.3.1.3. f.eks., hvis volumet skal opp trykker man på den øverste knappen

3.3.2. Visibility

3.3.2.1. Funksjoner som er ute av syne kan være vanskelig å forstå

3.3.2.2. Kan jeg se det? Worst case: Usynlige funksjoner (vannkran, forvirring)

3.3.2.3. Hjelper brukeren med å skjønne hva han skal gjøre

3.3.2.3.1. Hvordan kan jeg bruke det? Inviterer til bruk på bestemt måte

3.3.3. Consistensy

3.3.3.1. Elementer som ser like ut bør gjøre det samme

3.3.3.2. Brukeren burde slippe å huske på unntak

3.3.4. Constraints

3.3.4.1. Det motsatte av affordance

3.3.4.2. Hvorfor kan jeg ikke gjøre slik?

3.3.4.3. Signaliserer begrensninger "Greyed out"

3.3.4.4. PLACEHOLDER for datofelt

3.3.4.5. Betinges av:

3.3.4.5.1. Fysisk

3.3.4.5.2. Kulturelt

3.3.4.5.3. Omgivelser (polvott + smartphone)

3.3.5. Affordance + constraints

3.3.5.1. Viser hvordan noe skal brukes

3.3.5.2. Felt som skal fylles ut + knapp (next)

3.3.6. Affordance

3.3.6.1. Dårlig affordance = false affordance, luremus

3.3.6.2. En gjenstand kan signalisere ulike handlinger

3.3.6.2.1. Fysisk form

3.3.6.2.2. Kulturell. Konvensjoner som læres. Grønn: GO RØD: STOP

3.3.6.3. Hvis produktet kan utføre en handling det ser ut som om den ikke kan, kalles det hidden affordance

3.3.6.4. Beskriver en handlingsrelasjon mellom tingen og brukeren

3.3.6.5. Avhengig av bruksområde/plassering

3.3.7. Feedback

3.3.7.1. Visuell, auditiv, taktil, eller en kombinasjon

3.3.7.2. Info om hva som har skjedd

3.3.7.3. Affordance sier hva som kan gjøres og feedback sier at det har skjedd

3.3.7.4. Alle handlinger skal gi feedback

3.3.7.4.1. Mangel = kjipt. No progressbar..

4. Gestalt

4.1. Teorier for hvordan sanser fungerer

4.2. Baserer seg på at vi organiserer sanseinntrykk inn i helheter

4.3. Fem prinsipper

4.3.1. Likhet

4.3.1.1. Like former og farger sees sammen

4.3.2. Nærhet

4.3.2.1. Elementer som står nærme hverandre, oppfattes som tilhørende

4.3.3. Mental komplettering

4.3.3.1. Vi oppfatter helst lukkede former

4.3.4. Kontinuitet

4.3.4.1. En linje som har en retning oppfattes som om den skal fortsette i den retningen

4.3.5. Forgrunn/bakgrunn

4.3.5.1. Finnes aspekter som påvirker hva vi oppfatter som forgrunn og bakgrunn, f.eks. farge, kontrast, rammer, størrelse på objekter, perspektiver.

5. Brukbarhetstesting

5.1. Brukbarhet er relativt og kontekstavhengig

5.1.1. Kontekst uavhengig: Vekt/størrelse/farge/GHz

5.2. Tre punkter man vil måle i en test

5.2.1. Effectiveness (anvendbarhet)

5.2.1.1. Hvilken grad oppgavene lar seg gjøre?

5.2.1.2. Dekker systemet funksjonene? Klarer brukern å bruke disse?

5.2.2. Efficiency (effektivitet)

5.2.3. Satisfaction (tilfredstillelse)

5.2.3.1. "opplevde" brukskvalitet

5.2.3.2. Krever tester for å fastslå opplevelser. Viktig for aksept.

5.3. Forskjellige måter å måle på

5.3.1. Brukbarhetstesting i lab

5.3.2. Fokusgrupper for feedback

5.3.3. Felt-tester

5.4. Arbeidssteg

5.4.1. Utvikle målsetninger og hypotese, lag en testplan

5.4.1.1. Finn ut hvem, hva, og når

5.4.2. Skaff brukere

5.4.2.1. De burde ha riktig bakgrunn (jobb, erfaring, utdanning, kjønn, alder, holdninger etc)

5.4.2.2. Ofte holder det med 5-8 forskjellige brukere. Mer enn det blir bare de samme problemene rapportert om igjen

5.4.3. Forbered materiale

5.4.3.1. Detaljer, hvor, type av test (papir eller working)

5.4.3.2. Scenarier

5.4.3.2.1. best mulig scenarie rekkefølge oppgaver = real world riktig skillnivå

5.4.4. Pilottest

5.4.4.1. Gjøres for å teste opplegget

5.4.4.2. God mulighet for å oppdage svakheter og øve seg på scenarioene. Et scenario er en situasjon og oppgaver.

5.4.5. Velg forsøksleder

5.4.5.1. Kan også ansette eksterne konsulenter

5.4.6. Utfør testen

5.4.6.1. Ti punkter for å utføre en test

5.4.6.1.1. Introduser seg selv

5.4.6.1.2. Beskriv hensikten ved testen

5.4.6.1.3. Fortell deltakerene at de kan avbryte når de vil

5.4.6.1.4. Beskriv utstyret i rommet og begrensningene til prototypen

5.4.6.1.5. Lær bort hvordan man tenker høyt

5.4.6.1.6. Forklar at man ikke kan tilby hjelp under testen

5.4.6.1.7. Beskriv oppgaven og introduser produktet

5.4.6.1.8. Spør om det er noe de lurer på, kjør testen

5.4.6.1.9. Avslutt testen og la brukeren uttale seg før man samler løse tråder

5.4.6.1.10. Bruk resultatene

5.4.6.2. Gi lette oppgaver først så brukeren får en suksessfølelse

5.4.6.3. Gi en oppgave om gangen

5.4.6.4. Ha en avslappet atmosfære, gjerne server enten kaffe eller vann

5.4.6.5. Unngå forstyrrelser, f.eks. lukk dør og skru av mobil

5.4.6.6. Ikke hint om at han jobber sakte

5.4.6.7. Ha få observatører i rommet

5.4.6.8. Ikke ha sjefen til brukeren i rommet mens han utfører testen

5.4.6.9. Kan avslutte forsøket hvis det virker belastende for brukeren

5.4.6.10. Ikke la brukeren få inntrykk av testerens personlige preferanse

5.4.6.11. Identifiserer problemer ved å loggføre breakdowns

5.4.6.12. Vær oppmerksom på måten brukeren sier ting og kroppspråket til brukeren

5.4.6.13. Behandle alle brukere som individ

5.4.6.14. Ikke gå videre før man er sikker på at brukeren er ferdig

5.4.6.15. Ikke se overrasket ut

5.4.6.16. Fokuser på hva brukeren forventer

5.4.6.17. Hold deg så mye som mulig i bakgrunnen

5.4.6.18. Tillat brukeren å komme med innspill

5.4.6.19. Forklar hvordan resultatene kan bli brukt

5.4.7. Omform data

5.4.7.1. Prioriter funnene, utvikler løsningsforslag, og lager rapport

5.5. Fordel/ulempe av å isolere context of use (COU) ved brukbarhetstesting

5.6. Formativ / summativ

5.6.1. Formativ

5.6.1.1. TIdlig faser

5.6.1.2. Innsikt for forbedrelser

5.6.1.3. Identifisere feil

5.6.2. Summativ

5.6.2.1. Senere faser

5.6.2.2. Godkjenne/måle brukskvalitet (akseptansetest)

5.6.2.3. Målbare kriterier Feilrate, tidsbruk, subjektiv tilfredsstillelse

5.7. Horisontal / Vertikal

5.7.1. Horisontal

5.7.1.1. Går i bredden, men ikke dybde

5.7.2. Vertikal

5.7.2.1. Smalt, men går i dybden

6. Brukergrensesnitt

6.1. Kontrollelementer

6.2. Input

6.2.1. Buttons

6.2.1.1. Fyrer aksjon

6.2.1.2. Tydelig symbol, tekst. Åpenbart. DONT FUCK IT UP

6.2.2. Toggles

6.2.2.1. Tilstandsendring

6.2.2.2. Umiddelbar

6.2.2.3. Liten skade ved feilklikk

6.2.2.4. Gjenkjennbar, intuitiv

6.2.3. Dropdowns

6.2.3.1. Ett av mange valg

6.2.3.2. Kan scrolle

6.2.3.3. Autocomplete ++

6.2.3.4. Kan nøstes (drawback: lett å feile)

6.2.4. Radiobutton

6.2.4.1. Ett valg (av flere alternativer)

6.2.4.2. Vertikal

6.2.4.3. Dekk mulighetsrom

6.2.4.4. Led noobs med default valg (Men ikke ved presidentvalg o.l.)

6.2.5. Checkbox

6.2.5.1. ETT eller MANGE valg

6.2.5.2. Helst vertikal (horisontal = space aids)

6.2.5.3. OK med kolonner

6.2.5.4. Lable: SKAL være enkel og positivt ladd! "Disabled" IKKE LOV

6.3. Navigasjon

6.3.1. Sliders

6.3.1.1. Verdi innenfor numerisk intervall.

6.3.1.2. ca ca, touch er ikke presist

6.3.2. Pagination, scroll bars

6.4. Informasjon

6.4.1. Label: Statisk

6.4.2. Textfields: Dynamisk (Liten grå rute rundt text, som disabled txtinput)

6.4.3. Popups

6.4.3.1. Tilbakemeldinger

6.4.4. Tool tips, icons, progress bars, notifications, message boxes, modal windows

6.5. Containers

6.5.1. Tab controls

6.5.1.1. Faner. Lett å bytte view

6.5.1.2. Innhold må være logisk / gi mening å dele inn

6.5.1.3. PC: på toppen, mobil: på siden

6.5.2. Panels, accordion

6.6. TLDR: Konvensjoner Konvensjoner Less is more! Forenkling! TEST GUI!!!!!!

7. Brukersentrert design

7.1. Det kalles codesign når man slår sammen de to siste stegene i den iterative prosessen Workshop: hver gruppe lager sin løsning. Lavnivå. Design-in-action. Felles presentasjon

7.2. Brukskvalitet tar hensyn til bestemte brukere i bestemte omgivelser med bestemte mål. Personas definerer brukere, mens scenarioer definerer mål og omgivelser

7.3. Den iterative designprosessen

7.3.1. Plan the human centered design process

7.3.2. Understand and specify context of use

7.3.2.1. Brukssammenheng (COU)

7.3.2.1.1. Involver brukerne

7.3.2.1.2. Iterativ prosess

7.3.2.1.3. Krever forståelse av brukere, oppgaver og omgivelser

7.3.2.1.4. Tverrfaglig

7.3.2.1.5. Forståelse

7.3.2.1.6. Formidle

7.3.3. Specify user req.

7.3.3.1. Spesifisere krav

7.3.3.1.1. Intervju, fokusgruppe, rollespill

7.3.3.1.2. Formidles med: Kravlister (user req spec) Ikke-funksjonelle krav Scenarier/personas som viser bruken

7.3.4. Produce design solutions that meets user req.

7.3.4.1. Utvikling

7.3.4.1.1. Prototyping (papir vs working) Scenarier m personas for løsning i bruk retningslinjer (norman, nielsen)

7.3.5. Evaluate design vs req.

7.3.5.1. Brukbarhetstesting (se under)

7.3.5.1.1. Lab, fokusgruppe, felt test, SUS skjema

7.3.5.1.2. Testrapport, oppsumering, analyser av data

7.3.5.2. Iterate

7.3.6. Finished

7.3.7. divergens og konvergens skape valg / ta valg ide - produkt

7.4. Teknikker

7.4.1. Prototyping

7.4.1.1. Forenklet representasjon av designløsning

7.4.1.2. Brukes for testing

7.4.1.3. Prosjekters liv er gjerne en prosess hvor man skaper valg i starten, og må ta valg mot slutten

7.4.1.4. "Just enough prototyping"

7.4.1.5. Hvem er brukeren? Hva brukes det til? Hvor/hvilken sammenheng skal det brukes?

7.4.1.6. Prototyper vurederes ut ifra tre kriterier

7.4.1.6.1. Implementasjon

7.4.1.6.2. Funksjon/rolle

7.4.1.6.3. Look and feel

7.4.1.7. Lo-fi; low fidelity

7.4.1.7.1. Enkle prototyper uten detaljer

7.4.1.7.2. Gjerne i papir

7.4.1.7.3. Brukes tidlig i prosjektet

7.4.1.7.4. Enkle og billige å lage, trenger ikke å kunne progge

7.4.1.7.5. Ulemper: kan ikke simulere bevegelser, animasjoner etc. Må ha rollespill / innlevelse Ufullstendig

7.4.1.7.6. "tilbakemelding på egnetheten/brukervennligheten av konkrete løsninger

7.4.1.8. Hi-fi; high fidelity

7.4.1.8.1. Komplekse prototyper med detaljer

7.4.1.8.2. Ligner mer på det ferdige produktet, trenger ikke fullstendig program

7.4.1.9. Wizard-of-oz prototype

7.4.1.9.1. Det er et menneske som endrer tilstanden til systemet og reagerer på input fra brukeren

7.4.1.9.2. Kan være realistisk, men mest egnet til å simulere et begrenset sett med funksjonalitet

7.4.1.10. Papirprototype

7.4.1.10.1. Lager skisser av skjermbilder

7.4.1.10.2. Må simuleres av et menneske, wizard-of-oz style

7.4.1.10.3. Tilstandsdiagram brukes for å vise sammenhengen mellom skjermbilder

7.4.1.11. Skiller mellom bruk-og-kast og evolusjonær utvikling

7.4.1.11.1. Med evolusjonær kan man bygge seg videre mot et ferdig produkt

7.4.2. Personas

7.4.2.1. Er ikke en virkelig person, men en representant for en brukergruppe

7.4.2.2. Kan evaluere en funksjon med utgangspunkt i en persona

7.4.3. Scenarioer

7.4.3.1. Beskriver oppgaver eller situasjoner

7.4.4. Storyboards: ofte løsningen på et scenario Ideskisse, forslag

7.4.5. Intervju

7.4.5.1. +Dybdekunnskap - få brukere

7.4.5.2. Må plukke representative brukere

7.4.5.3. "Hva de gjør i dag", "hvilke omg.". Anvendbarhet: identifisere sentrale funksjoner

7.4.6. Fokusgruppe

7.4.6.1. Tilbakemelding på konkrete forslag Mange stemmer, lett å overse detaljer

7.4.6.2. Scenarier? Omg? Er funksjonaliteten riktig? Hva må gå fort? Hva skal brukeropplevelsen være?

8. Deltakende design

8.1. Kvalitetskriterier

8.1.1. Utilitas; Skal fylle et behov

8.1.2. Firmitas; Skal være teknisk godt

8.1.3. Venustas; Skal være vakkert

8.2. - Tar ikke hensyn til at forskjellige personer har forskjellige meninger

8.3. - Teknologi kan ha innebygde politiske, sosiale, og etiske konsekvenser

8.3.1. Ikke god eller ond, men heller ikke verdinøytral

8.4. Tar utgansgpunkt i brukerens "tause" kunnskap; The tool perspective

8.4.1. Erfaringsbasert kunnskap

8.4.2. Kan være vanskelig å formalisere, og dermed vanskelig for datamaskiner å erstatte

8.5. Startet i skandinavia pga frykt for at industrialisering og automatisering skulle ta arbeidsplassene til folk

8.6. Ideen er at deltakende design skal forbedre praksisen istedenfor å erstatte den

8.7. Arbeiderne er med på å bygge verktøyene

8.8. Brukersentrert design startet i USA. Da involverte de brukere i brukbarhetstester

8.9. Utfordringer

8.9.1. Må ha demokrati

8.9.2. mikset roller

8.9.3. Hvem vektes mest?

8.9.4. Ikke representativt

8.9.5. Vanskelig å lage radikale løsninger

9. Ubiquitous computing

9.1. Den tredje interaksjonsparadigmen

9.1.1. Den første var mainframes i 1960-1985. En datamaskin, mange brukere

9.1.2. Den andre var PCer i 1985-2000. En bruker, en datamaskin

9.1.3. Er nå i den tredje, hvor vi har en bruker, mange datamaskiner

9.2. Forkortet til UbiComp

9.3. Visjonen ble beskrevet av Mark Weiser fra Xerox PARC i 1991

9.3.1. Skulle kunne interagere med maskinen hvor som helst, når som helst

9.3.2. Skulle være en forlengelse av kroppen

9.4. Kan gjøre det vanskelig å gjenskape brukskonteksten; ting blir brukt mer "on-the-move" enn bare foran en pc

10. Interaksjonsteknikker

10.1. Handler om hvordan inn- og ut-data fungerer, både på software- og hardware-nivå

10.2. Bakgrunnsinteraksjon

10.3. Forgrunnsinteraksjon

10.4. Mobil interaksjon

10.5. Stasjonær interaksjon

10.6. God kvalitet av interaksjonsteknikker krever forståelse av brukeren, omgivelsen, og oppgaven

11. Konseptuelle- og mentale modeller

11.1. Mental

11.1.1. Er en persons ide om virkemåten og strukturen til et system

11.1.2. Styrer hvordan brukeren bruker systemet

11.1.3. Formes av erfaring fra lignende systemer, samtaler med brukere, prøving og feiling, og brukermanualer

11.1.4. subjektiv, ufullstendig, inkonsitent, dynamisk

11.1.5. Kan få tilgang til den ved brukbarhetstesting, oppgaveanalyse, og intervjuer

11.1.6. To typer

11.1.6.1. Funksjonell

11.1.6.1.1. Vite hvordan "Hva må jeg gjøre for å få til dette?"

11.1.6.2. Strukturell

11.1.6.2.1. Hva som fører til hva Strukturen til produktet

11.1.7. Kartlegg brukerens mentale modell

11.1.8. Dårlig modell fører til

11.1.8.1. Redusert brukeropplevelse

11.1.8.2. Systematisk feilbruk av system fordi deres mentale modell er crap

11.1.9. Dårlig modell løses med

11.1.9.1. Forbedre brukerens mentale modell Eller tilpasse systemet til mental modell

11.1.9.2. Tydeliggjør design

11.1.9.3. Kursing, tooltips, kort tutorial

11.2. System image

11.2.1. Kommuniserer den konseptuelle modellen

11.2.2. UI + manualer

12. Context of use

12.1. Hvem

12.1.1. Krever tilgang: teens, oldies, studenta etc

12.1.2. Flere akser: datakunnskaper, kjennskap til bruksområde, motivasjon, motorikk

12.2. Hva

12.2.1. Detaljert kartlegging av arbeidspraksis og infoflyt

12.3. Hvor

12.3.1. Kunnskap om fysiske omg., observere, teste, ekte eller simulert

13. Brukersentrert vs Deltagende

13.1. Brukersentrert

13.1.1. 1. Deigneren tar valg, "diktator"

13.1.2. 2. Brukerene er testsubjekter (konsulenter)

13.1.3. 3. Løsningen designes for brukerne

13.1.4. 4. Fokus på brukskvalitet

13.2. Deltagende

13.2.1. 1. Brukerne er med på designvalgene (designern er fasilitator)

13.2.2. 2. Brukerne er partnere gjennom hele prosessen

13.2.3. 3. Løsningen designes for, med og av brukerne

13.2.4. 4. Fokus på "user empowerment"