Krav
- Krav beskriver funksjoner eller egenskaper til et system, en tjeneste, eller en løsning
- Innen HCI er krav altså noe vi stiller til systemer
- Krav lider ofte av utydelighet, tvetydighet eller mangelfullhet
Funksjonelle krav
- Krav som sier noe om hva systemet skal kunne gjøre med klare oppgaver og funksjoner, ofte formulert som “kan”
- Absolutt formulert: «ja/nei»
- Hvilke funksjonaliteter (og atferd) skal systemet ha?
- EKS: «Mobiltelefonen skal kunne lades trådløst» / «Mobiltelefonen skal kunne avspille musikk»
Ikke- funksjonelle krav
- Krav som sier noe om hvordan systemet skal utføre sine funksjoner (dvs. kvaliteten på utførelsen)
- Målbart formulert: «hvor godt»
- Hvilke kvaliteter og egenskaper skal systemet ha?
- EKS: «Mobiltelefonen skal ha en responstid på under 100ms ved ansiktsgjenkjenningsinnlogging» / «Mobiltelefonen skal ikke veie mer enn 200g»
sosiale krav
- Er det sosiale elementer ved bruken eller brukskonteksten som kan medføre krav?
- EKS: «Mobiltelefonen skal kunne brukes av flere individer» / «Mobiltelefonen skal støtte samtaler med mennesker på andre siden av jorda»
Personas
- Personas beskriver brukerkarakteristikken til en fiktiv bruker som er ment å representere en gruppe brukere
- Som regel holder man seg til 1-4 personaer for å dekke de mest interessante brukergruppene
- Beskriver ikke reelle personer, men personas skapes som regel fra reelle personer
- Bringes til live ved å gi dem navn, mål, karakteristikker, bakgrunn etc.
- Må ikke idealiseres til å anses som 100 % perfekte, nøyaktige eller representative
Domene
- Vi designer ofte for spesifikke brukskontekster hvor god innsikt krever domenekunnskap
- Et felt eller omfang av en bestemt kunnskap eller aktivitet
- For å skape gode brukeropplevelser må vi enten sette oss inn i domenet eller hente inn domeneeksperter
- Ofte er ikke løsninger overførbare mellom domener
ULIKE TYPER:
* Domene: et felt eller omfang av en bestemt kunnskap eller aktivitet
* Domenekunnskap: kunnskap innenfor et bestemt domene
* Domeneekspert: en ekspert innenfor et gitt domene
Scenarior
- Uttrykke foreslåtte eller tenkte situasjoner so beskriver hvordan et problem vanligvis utspiller seg, men uten å foreslå en løsning.
- Blir brukt i designet på ulike måter:
1. Konkrete eksempler på oppgaver som er sentrale for eksisterende utfordringer
2. Pluss- og minusscenarioer bruker vi for å vurdere de mest positive og negative konsekvensene ved en foreslått løsning, og disse er viktige for å hjelpe designeren med å danne et helhetlig bilde av brukssituasjonen.
3. Script som kan brukes (senere) under evaluering av prototyper
4. Vi benytter ofte “ekstreme” scenarioer (f.eks. dommedagsscenario) for å utvide designrommet.
Behov
Avdekkes hos mennesker
- Behov beskriver hva vi som mennesker - helt fundamentalt - trenger i livet - grunnleggende/iboende atferd og motivasjon
- Kontekstualiserer underliggende motivasjon for ønsker, verdier, preferanser etc. og er uavhengig av teknologi og andre mennesker
- Mye av vår forståelse rundt menneskelige behov er lånt fra psykologien (f.eks. Maslows behovspyramide)
- Avdekke behov: the 5 Whys
EKSEMPLER
* Trygghet
* Mestring
* Forflytning
* Kommunikasjon
* Tilbakemelding
* Selvrealisering
Hvordan gå fra behov til krav?
Hva ønsker vi å oppnå?
* Forstå mest mulig om bruk, brukere, brukskontekst og oppgavene som skal løses
* Etablere et stabilt sett med krav
Hvordan kan vi oppnå dette?
* Datainnsamlingsaktiviteter
* Analyse av data
* Formulere uttrykk og beskrivelser som «krav»
* Iterative prosesser med brukere og andre interessenter
Bruk
**Useful: **At noe tillater bruk -> tilfører en funksjonell nyttverdig og er forsmålstjenlig (nyttig)
Usable At noe er lett å bruke -> gjør de riktige tingene, er fornøyelige og tilfører en god opplevelse av bruk (Brukbart)
Used: At noe faktisk tas i bruk -> er attraktivt, tilgjengelig og aksepteres over tid (Brukt)
5 key issues
En måte å forholde seg til datainnsamling:
1. sett mål
2. Identifisere deltakere
3. forholdet til deltakere
4. Triangulering
5. Pilotstudie
