INF1500 - Introduksjon til design, bruk, interaksjon Brukeropplevelser og designprinsipper

INF1500 - Introduksjon til design, bruk, interaksjon Brukeropplevelser og designprinsipper Institutt for Informatikk, 3. oktober 2011 joshi@ifi.uio.no

Oversikt It is easy to make things hard. It is hard to make things easy. Brukeropplevelser Hva er brukeropplevelser? Hva påvirker brukeropplevelser? Hvilke mål har vi på brukeropplevelser? Designprinsipper Seks prinsipper i fokus Andre prinsipper Obligatorisk oppgave 2 Formål Hva skal gjøres? Hva skal leveres? Før prototypen Om prototypen Tips og huskeliste

Brukeropplevelser User experience (UX) En brukers helhetsopplevelse ved bruken av et system eller et produkt Man kan ikke designe en brukeropplevelse, man kan kun designe for brukeropplevelser Ulike brukere med ulike preferanser, mål og forventninger Ulike brukskontekster og brukssituasjoner Ulike nivåer av kompetanse og ferdighet hos brukere Vi kan bare designe for brukeropplevelser

Brukeropplevelser Vi kan ikke bruke tradisjonelle måleenheter eller skalaer Brukervennlighet handler om grensesnittets brukervennlighet og hvor raskt eller bra man kan løse oppgaver (efficiency) Vi må ta innover oss alle faktorer som påvirker brukeropplevelsen når vi designer Hva mer enn brukervennlighet påvirker brukeropplevelser?

Hva påvirker brukeropplevelser? Brukbarhet Menneskelige faktorer Design Utstyr HCI Brukeropplevelse Tilgjengelighet Markedsføring Ergonomi Systemets ytelse

Brukerens ferdighetsnivå Hvordan påvirker en brukers ferdighetsnivå brukeropplevelsen av systemet? Vanskelig å design for flere ferdighetsnivåer samtidig Eksperter krever rask kontroll og feedback Systemet avbrytes oftere av eksperter Nybegynnere krever stødig og begripelig kontroll og feedback Nybegynnere avbrytes oftere av systemet Novice Intermediate Expert Ferdighetsn ivå Ferdighetsn ivå Ferdighetsn ivå Tid Tid Tid

Mål på brukeropplevelser Brukeropplevelsesmål omhandler hvordan en bruker opplever bruken av et system fra deres perspektiv, mens brukerbarhetsmål angir hvor produktivt et system er i et eget perspektivp Er det en konflikt mellom disse to settene med mål? Brukbarhetsmål Brukeropplevelsesmål Effektivitet (effectiveness) Ønskelige aspekter: Flittighet (efficiency) Trygghet Tilfredshet Nyttighet Underholdende Lærbarhet Engasjement Memorerbarhet Behaglighet Fornøyelighet Spennende Utfordrende Hjelpsomhet Se resten av tabellen på s. 23 i boka (3. utgave) Motiverende Uønskelige aspekter: Kjedsomhet Barnslighet Forvirrende Irriterende Frustrerende Fornærmende Nedlatende

Elementer av brukeropplevelser Konkret Fullførelse Visuell design: Grafisk utforming av av elementer i grensesnittet. The look in look-and-feel. Visuell design Grensesnittdesign: Som i tradisjonell HCI: design av grensesnitt for å tilrettelegge for brukerinteraksjon med systemets funksjonalitet. Informasjonsdesign: Design og utforming av presentasjonen av informasjon for å tilrettelegge for forståelse. Informasjonsdesign Grensesnittdesign Navigasjonsdesign Navigasjonsdesign: Design av elementer i grensesnittet for å tilrettelegge for enkel bevegelse gjennom informasjonsarkitekturen. Interaksjonsdesign: Utvikling av applikasjonsflyt for å tilrettelegge brukeroppgaver. Definisjon av hvordan bruker interagerer med systemets funksjonalitet. Interaksjonsdesign Informasjonsarkitektur tid Informasjonsarkitektur: Strukturelt design av informasjon for å tilrettelegge for intuitiv tilgang til innhold. Funksjonelle spesifikasjoner: Detaljerte beskrivelser av funksjonalitet systemet må ha for å imøtekomme brukerens behov. Funksjonelle spesifikasjoner Innholdskrav Innholdskrav: Definisjon av innhold som er nødvendig for å imøtekomme brukerens behov. Brukers behov: Eksternt deriverte mål for systemet: identifisert gjennom brukerundersøkelser, etnografi etc. Brukers behov Systemets formål Systemets formål: Business, kreativitet or andre internt deriverte mål for systemet. Oppgaveorientert Abstrakt Oppfattelse Informasjonsorientert

Hvorfor ser trafikklys ut som de gjør? Hvorfor har trafikklys en egen posisjon for hver farge? Hvorfor bruker trafikklys rødt for stopp og grønt for klart? Hvorfor er det bilde av en mann som går i den grønne lampen og en mann som står stille i den rød lampen? Hvorfor piper det når vi trykker på knappen? Hvorfor er trafikklys like uansett hvor i verden vi befinner oss? Hvorfor lyser det rødt og gult samtidig, men aldri grønt og gult?

Prinsipper, retningslinjer og standarder Prinsipper Abstrakte designregler Retningslinjer Råd om hvordan man kan oppnå prinsipper Standarder d Konkrete regler (målbare) Komplementerer modellering og evaluering Sammenfatter forståelse og best praksis Hjelper med å maksimere brukbarhet Økende allmen nngyldighet Retningslinjer Økende autoritet Standarder

Designprinsipper Gir oss en idé om hva som bør og ikke bør gjøres Hjelper med å se løsningen fra ulike perspektiverp Bidrar til å øke brukervennlighet Derivert fra en kombinasjon av teori kunnskap, erfaring og sunn fornuft Seks prinsipper står i fokus i dette kurset: Visibility Feedback Constraints Consistency Affordance Mapping

Visibility kan jeg se det? If the users can't find it, the function isn't there. Bruker kan se status og alle mulige valg videre Bruker blir ikke overveldet eller distrahert av informasjon Bruker forstår bedre hvordan funksjoner fungerer desto mer synlige de er Bruker kan bli forvirret av usynlige og automatiserte funksjoner Eksempler: Lysbryter Knapper i heisen Sensorstyrt håndvask

Feedback hva gjør det nå? Bruker opplyses om hva som er blitt gjort og oppnådd hittil slik at han kan fortsette Bruker forstår at input hadde en effekt på systemet Bruker får umiddelbar og synkronisert tilbakemelding Bruker ser progresjon eller status hvis funksjoner er utilgjengelig l eller begrenset Eksempler: Heisknapper piper (og lyser) Datamaskiner animerer timeglass mens den tenker Microsoft Word highlighter alle ord som er feilstavet Gjøres typisk med lyd, lys, animasjon, highlightinghli hti eller en kombinasjon av flere

Constraints hva kan jeg ikke gjøre? Bruker får valgmulighetene sine avgrenset Bruker hindres i å gjøre feil Bruker kan konsentrere seg om det som er (mest) relevant Eksempler: Fysisk: Saks, puslespill, USB-kabel Logisk: høyreklikk-meny, knapper som blir grå/deaktivert Kulturelt: rød trekant for varsel, scrollefelt til høyre

Consistency hvor har jeg sett det før? Bruker ser og anvender like operasjoner og elementer når like oppgaver skal løses Bruker forstår, anvender og lærer lettere dersom like konsepter representeres likt Bruker kan enkelt overføre gammel kunnskap til ny kontekst Eksempler: Estetisk: Biler (Mercedes Benz) Funksjonelt: Trafikklys Internt: Turskilt i Marka Eksternt: Menyknapper i Mac OS X

Affordance hvordan bruker jeg det? Bruker forstår hvordan noe fungerer ved hjelp av objektets attributter Bruker får indirekte hint om hvordan noe brukes Eksempler: Knapper kan trykkes og et volumhjul kan vris Ikoner kan klikkes Hull i en saks til fingre eller knagger for å henge opp noe

Mapping hvor er jeg og hvor kan jeg gå? Bruker forstår sammenhengen mellom en funksjon og effekten den har på noe/verden Bruker slipper å memorere hvilken effekt en funksjon har Bruker unngår unødvendig frustrasjon Eksempler: Komfyrens plassering av knapper og hjul Dokumentet scroller oppover når vi trykker på tastaturet

Retningslinjer Donald Norman: 7 principles of design The Psychology Of Everyday Things Basic Books, 1998. ISBN 978-0465067091 Ben Shneiderman: 8 golen rules of usability design Designing the User Interface: Strategies for Effective Human-Computer Interaction, 5/E Addison-Wesley, 2009. ISBN 978-0321537355 JkbNil Jakob Nielsen: 10 usability heuristics Ten Usability Heuristics useit.com, 2005. ISSN 1548-55525552

Donald Normans syv prinsipper: Seven principles for transforming difficult tasks into simple ones 1. Use both knowledge in the world and knowledge in the head 2. Simplify the structure of tasks 3. Make things visible 4. Get the mappings right 5. Exploit the power of constraints, both natural and artificial 6. Design for error 7. When all else fails, standardize

Ben Shneidermans åtte gylne regler: 1. Strive for consistency 2. Enable frequent users to use shortcuts 3. Offer error prevention and simple error handling 4. Design dialogs to yield closure 5. Offer error prevention and simple error handling 6. Permit easy reversal of actions 7. Support internal locus of control 8. Reduce short-term term memory load

Jakob Nielsens ti heuristikker: 1. Visibility of system status 2. Match between system and the real world 3. User control and freedom 4. Consistency and standards 5. Error prevention 6. Recognition rather than recall 7. Flexibility and efficiency of use 8. Aesthetic and minimalist design 9. Help users recognize, diagnose, and recover from errors 10. Help and documentation

70 ting å tenke på: (B. A. Myers, 1999) 1) Things that look different should act different. 2) If it is not needed, it's not needed. 3) The information for the decision needs to be there when the decision is needed. 4) The user should control the system. The system shouldn't control the user. The user is the boss, and the system should show it. 5) The idea is to empower the user, not speed up the system. 6) Don't overload the user's buffers. 7) Keep it simple. 8) Things that look the same should act the same. 9) The user should be able to do what the user wants to do. 10) Every action should have a reaction. 11) Everything in its place, and a place for everything. 12) Let people shape the system to themselves, and paint it with their own personality. 13) Error messages should actually mean something to the user, and tell the user how to fix the problem. 14) The best journey is the one with the fewest steps. Shorten the distance between the user and their goal. 15) Everyone makes mistakes, so every mistake should be fixable. 16) The more you do something, the easier it should be to do. 17) Cute is not a good adjective for systems. 18) Keep it neat. Keep it organized. 19) Consistency, consistency, consistency. 20) The user should always know what is happening. 21) Minimize the need for a mighty memory. 22) Know they user, and YOU are not thy user. 23) If I made an error, at least let me finish my thought before I have to fix it. 24) Design for regular people and the real world. 25) Eliminate unnecessary decisions, and illuminate the rest. 26) You should always know how to find out what to do next. 27) If I made an error, let me know about it before I get into REAL trouble. 28) Even experts are novices at some point. Provide help. 29) Provide a way to bail out and start over. 30) Don't let people accidentally shoot themselves. 31) Color is information. 32) The user should be in a good mood when done. 33) The fault is not in thyself, but in thy system. 34) To know the system is to love it. 35) Deliver a model and stick to it.

70 ting å tenke på: (B. A. Myers, 1999) 36) Follow platform conventions. 37) Make it hard for people to make errors. 38) The system status (i.e., what's going on should always be visible. 39) Accommodate individual differences among users through automatic adaptation or user tailoring of the interface. 40) Make it easy for a beginner to become an expert. 41) No you can't just explain it in the manual. 42) Provide user documentation that is easy to search, focused on the user's task, lists concrete steps to be carried out, and is not too large. 43) The system should speak the users' language, g following real-world conventions. 44) Instructions for use of a system should be visible or easily retrievable. 45) What does marketing think it wants? Ok, now how do we show them they're wrong? 46) What does management think it wants? Ok, now how do we show them they're wrong? 47) Allow users to tailor frequent actions. 48) Users don't know what they want, and users can't always say what they know. 49) Roll the videotape. 50) Common sense is an uncommon commodity. 51) Make objects, actions, and options visible. 52) Data drives good design. 53) Help users develop a conceptual representation of the structure of the system. 54) Minimize the amount of information a user must maintain in short-term memory. 55) It's a jungle. Be careful out there. 56) People should not have to remember information across a dialogue. 57) Make it impossible to make errors that will get the user into REAL trouble. 58) Dialogues should not contain information that is irrelevant or rarely needed. 59) Testing, testing, testing. 60) Keep the user mental workload within acceptable limits. 61) Minimize the amount of information recoding that is necessary. 62) Minimize the difference in dialogue both within and across interfaces. 63) An ounce of good design is worth a pound of technical support. 64) Provide the user with feedback and error-correction capabilities. 65) So how is this better than what the competition is doing? 66) Provide good error messages that are expressed in plain language, precisely indicate the probem, and constructively suggest a solution. 67) Whadya mean, they're not all computer scientists? 68) Support undo and redo. 69) Different words, situations, or actions should result in different things happening. 70) The best user interface is one the user doesn't notice.

Oppsummering: En brukers helhetsopplevelse ved bruken av et system eller et produkt Vi kan bare designe for brukeropplevelser Mange faktorer påvirker brukeropplevelsen, deriblant ferdighetsnivå Vi har egne mål på brukeropplevelse som skiller seg fra mål på brukbarhet Designprinsipper hjelper oss med utformingen av et system Ulike designprinsipper tar for seg ulike aspekter ved brukeropplevelsen elsen Det finnes populære retningslinjer som også kan brukes for veiledning

Obligatorisk oppgave 2 Formålet er å gi studentene trening i prototyping Fristen er 21. oktober innen kl. 16.30 Innlevering i Devilry som med obligatoriske oppgave 1 Hva skal gjøres? Hva skal leveres? Før prototypen Om prototypen Tips og huskeliste

Hva skal gjøres? Obligatorisk oppgave 1 Formål Scenario Krav Designalternativ 1 Designalternativ 2 Obligatorisk oppgave 3

Hva skal leveres? (Bakgrunnsinformasjon og persona fra obligatorisk oppgave 1) Beskrivelse av formålet med prototypen Scenarioet som er brukt som utgangspunkt Bilder (eller link til video etc.) av de to prototypene Beskrivelse av funksjonalitet og interaksjon for de to prototypene Beskrivelse og begrunnelse for valg av metode

Før prototypen Formålet med prototypen hvilken problemstilling skal løses? I forhold til målsetning bør denne problemstillingen løse målsetningen din Persona hvem er bruker (holdning, bakgrunn, bruksfrekvens, erfaring etc.)? I forhold til målsetningen bør personen reflektere en påtenkt bruker Behov og krav hvilke behov hos brukeren stiller krav til systemet? t? (oblig 1) I forhold til målsetningen bør kravene gjenspeile behovene Scenario hvilken oppgave skal utføres og i hvilken setting? I forhold til målsetningen bør scenarioet fortelle om en mulig løsning (Oppgaveanalyse) hvilke oppgaver fokuseres på?

Om prototypen Konseptuell modell beskrivelse av det foreslåtte systemet Funksjoner, funksjoners relasjon, presentasjon av informasjon Metodikk valg av utviklingsmodell, oppløsning og kompromisser Low eller high fidelity? Horisontal eller vertikal prototype? Utforming beskrivelse av prototypens interaksjon og grensesnitt Interaksjonstype? Grensesnittype? Grensesnittmetaforer? Designprinsipper beskrivelse av de viktigste prinsippene Hvorfor var de valgte prinsippene viktig? Hvordan har de blitt brukt i utformingen av prototypen? Alle valg må begrunnes!

Tips Dersom utgangspunktet fra obligatorisk oppgave 1 er dårlig, begynn på nytt Sørg for at du har brukers behov i fokus hele veien Bruk teori til å begrunne og utforme designvalg hele veien Lag gjerne prototyper av andre ting enn papir (kan leveres som bilde, video etc.) Spør din gruppelærer dersom du er usikker på noe (inf1500-x@ifi.uio.no) Orakel? Hør med din gruppelærer!

Husk! Ikke skriv og forklar oppå selve prototypen deres, men heller før eller etter Alt skal leveres som ett PDF-dokument (alt annet må omleveres) Inkluder brukernavn i dokumentet Få med sidetall, overskrifter, referanser, innholdsfortegnelse