10 ting en utvikler må kunne om brukervennlighet anna
•
1 j'aime•642 vues
En veldig basic introduksjon til hva utviklere må kunne om design og brukervennlighet. Holdt sammen med Ole Andreas Alsos
Recommandé
Recommandé
Contenu connexe
Similaire à 10 ting en utvikler må kunne om brukervennlighet anna
Similaire à 10 ting en utvikler må kunne om brukervennlighet anna (20)
10 ting en utvikler må kunne om brukervennlighet anna
- 1. 10 TING EN UTVIKLER MÅ KUNNE OM BRUKERVENNLIGHET OG DESIGN Som utvikler må du kunne … Trondheim, NNUG Meetup Ole Alsos og Anna Karine Lunna 25/04/13
- 2. Du må kunne snakke med brukerne
- 3. SNAKK MED BRUKERNE 3 You are n t the user
- 7. 7
- 9. 9 Du må kunne lage og bruke personas
- 10. PERSONAS 10 Hvem er det egentlig vi lager denne løsningen for?
- 12. [BRUKERSEGMENT] 12 [Navn] [Alder] [Sivilstatus] [Arbeid] ”[Sitat]” [Valgfri kategori]: [Beskrivelse av kategori] Bakgrunn: [Beskrivelse av bakgrunn] Forhold til strøm: [Beskrivelse av deres forhold til strøm] Økonomi: [Beskrivelse av personlig økonomi] Holdninger: [Beskrivelse av holdninger] Datakunnskap: [Beskrivelse av databakgrunn og ferdigheter] Mål: [Beskrivelse av bakgrunn] Behov: [Beskrivelse av behov til løsningen] Typiske oppgaver: [Oppgaver som brukeren trenger å løse]
- 13. DEN FØRSTEGANSETABLERTE 13 Tom 22 år Ugift NTNU-student ”Jeg vil gjøre alt online” Bakgrunn: Tom bor i en liten kjellerleilighet på Byåsen. Han flyttet fra foreldrene i Selbu da han begynte å studere Ind-øk på NTNU for 3 år siden. Han flytter ganske ofte og er igjen snart på flyttefot. Forhold til strøm: Skjønner seg egentlig ikke på strøm. Har enda ikke lest av strømmåleren siden han flyttet hit for 8 måneder siden. Kunne godt ha trengt en ”Strøm for dummies”-bok. Økonomi: Har dårlig kontroll over personlig økonomi. Får ofte inkassovarsel i posten og har flere betalingsanmerkninger. Foreldrene betaler strømregningen. Faren ringer ofte kundeservice på vegne av sønnen. Holdninger: Er miljøengasjert og har konkurranseinstinktet i orden. Er teknisk interessert. Datakunnskap: Har svært god kjennskap til data og internett. Bruker sosiale medier som Facebook og Twitter. Mål: Vil redde miljøet og gjøre strømforbruket til en lek. Behov: Trenger hjelp til å huske måleravlesning. Trenger flyttehjelp. Typiske oppgaver: Registrere måleravlesning, gi faren fullmakt
- 14. Du må kunne lage brukerhistorier og prioritere
- 15. BRUKERHISTORIER OG PRIORITERING 15 Det er brukernes behov, ikke hvilke muligheter vi har til å legge til kul funksjonalitet, som skal styre hva vi lager
- 16. BRUKERHISTORIER OG PRIORITERING 16 Brukerbehov Hva? Løsning Det er totaltprisen som er viktig for sluttbrukeren. Dersom han kan få en bra pris på hotel ved å bestille dette samtidig som flybillett er det supert
- 18. BRUKERHISTORIER OG PRIORITERING 18 Nødvendig eller kjekt å ha?
- 19. Du må kunne visualisere ideene dine
- 20. TEGNE OG VISUALISERE 20 Lorem Ipsum er rett og slett dummytekst fra og for trykkeindustrien. Lorem Ipsum har vært bransjens standard for dummytekst helt siden 1500-tallet, da en ukjent boktrykker stokket en mengde bokstaver for å lage et prøveeksemplar av en bok. Lorem Ipsum har tålt tidens tann usedvanlig godt, og har i tillegg til å bestå gjennom fem århundrer ogwså tålt spranget over til elektronisk typografi uten vesentlige endringer. Lorem Ipsum ble gjort allment kjent i 1960-årene ved lanseringen av Letraset-ark med avsnitt fra Lorem Ipsum, og senere med sideombrekkingsprogrammet Aldus PageMaker som tok i bruk nettopp Lorem Ipsum for dummytekst. Det er et velkjent faktum at lesere distraheres av lesbart innhold på en side når man ser på dens layout. Poenget med å bruke Lorem Ipsum er at det har VS
- 21. TEGNE OG VISUALISERE 21
- 22. TEGNE OG VISUALISERE 22 SNAKKER FORBI HVERANDRE
- 23. TEGNE OG VISUALISERE 23
- 24. TEGNE OG VISUALISERE 24
- 25. TEGNE OG VISUALISERE 25
- 26. TEGNE OG VISUALISERE 26
- 27. Du må kunne skissere skjermbilder
- 32. Foto: Lars K Flem
- 34. Foto: Ole Andreas Alsos
- 35. Foto: Ole Andreas Alsos
- 36. Foto: Kai T. Dragland
- 37. Foto: Kai T. Dragland
- 38. “Finner teknikken virkelige problemer?” “Hva vil de tro om oss?” “Har vi virkelig tid til dette?”
- 39. Unngår detaljpirk Oppmuntrer til kreativitet Zero coding effort Reduserer backloggen
- 41. GRUNNLEGGENDE BRUKERVENNLIGHET 41 1. Ikke la meg måtte tenke 2. Finner vi tilfredsstillende valg klikker vi og prøver oss frem 3. Design sider for scanning, ikke lesing 4. Riktig informasjon til riktig tid. 5. Kutt halvparten av teksten – så kutter du halvparten av det som er igjen.
- 42. Homo logicus Ønsker kontroll Aksepterer kompleksitet som kompromiss Homo sapiens Ønsker enkelhet Aksepterer mindre kontroll som kompromiss
- 46. Du må kunne lage gode feilmeldinger
- 47. FEILMELDINGER 47
- 50. PRESIS
- 54. IKKE SKYLD PÅ BRUKEREN
- 56. SLIK LAGER DU GODE FEILMELDINGER Ikke skyld på brukeren Vær presis Vær synlig Gi konstruktiv hjelp Snakk brukeren språk Vær høflig Spar brukeren for arbeid
- 59. Du må kunne kopiere design
- 66. EVALUERING 66 Lat som du er en bruker Observer brukere Ekspertevaluering BrukertestingDemo Vis frem til brukerne
- 67. “Vi har ikke tid!” “Det er for dyrt!” “Vi kjenner allerede brukerne” “Det er ingen vits, vi har ikke tid å gjøre noen endringer”
- 70. en uke en time tradisjonell brukertesting (8 testbrukere) Lavbudsjettsbrukertesting (5 testbrukere)
- 71. Du må kunne sette krav til din interaksjonsdesigner
Notes de l'éditeur
- Førstogfremst: Du erikkebrukeren! For åkunnelage en løsningsomertilnytte for den somskalbruke den må du førstkjennetilhvembrukerne dine eroghva de trenger.
- Webstatistikkkansinoeomhvordansidenebrukes
- Du kangjennomførespørreundersøkelsersomgirdegnoenindikasjonerpåhvorproblemenefinnes
- Men for åfåtak I informasjonensomkansinoeomhvabehovenetilbrukerenfaktiskermå du snakke med ogobserverebrukerne
- Og for åskjønnehvembrukerne dine ermå du snakke med de!ObserverebrukereibrukssituasjonSnakke med brukere – gjennomføreintervjuerogsnakke med deHusk – åpnespørsmålgirdegmerinformasjonSpørreundersøkelserogstatistikkgirdegmerkonkrete “tall” men erofteufullstendigogbørbrukessom et supplement tilobservasjonogintervju.Spørhvorfor? Deterikkealltid at du erinteressert I hvasomerproblemet men hvorfordeter et problem. Klarer du åfinneut den bakenforliggendegrunnentil at brukerenikkeforstårnoe, ikkeønskeråbrukenoeosvkan du begynneåløse de virkeligeproblemene.
- Vi trenger en blogg!> Hvorfortrengerdere en blogg?> Fordi vi m. kunnepublisereinnholdtilbrukernev.reraskere.> Hvorfor m. innholdtilbrukernepubliseresraskere?> Fordidetg.r s. sakten.r vi publisererartikleri content management systemetv.rt.> Hvorforg.rdet s. sakte . publisereartikleri CMS-et da?> Huff , jegsynesdeter s. komplisertogvanskelig . bruke.> Hvorforerdet s. vanskelig . bruke?> Uff , deterheltulogiskiforholdtildetjegskalgj.re...
- Viktigåhuskepå at det sitter en person somskalbrukeløsningen vi utviker I den “andreenden”. Viktigåhuskepådettenår vi utvikler!
- Hvemskalkunnegjørenoe, hvaskal de gjøreoghvorforskal de gjøredet?
- Brukerhistorienemåprioriteres.Hvaskaltil for at vi skallage en brukbarløsning? Hvaerdetbrukerenegentligtrengeroghvaer “kjektå ha”?
- Hvorfortegne?
- Kan du ikketegne? Null stress! Det handler ikkeomåkunnetegne med omåforstå. Viskalikkelagekunst vi skalkunnekommuniseretankeneogideenevåre. 5 enkleregler:TegnKontrastForenkleForsterkeOverbevise
- Mange funksjonersom skal utvikles og det kan ofte være en utfordring å holde oversikt. Papirprototyper holder fokus på det konseptuelleUlik forståelse av funksjonene, papirprototyper kan bidra til kommunikasjon mellom stakeholders og skape en felles forståelse av hva som skal lages Papirprototyper kan fungere som deler av en kravspesifikasjonPapirprototyper kan forsikre deg om at brukere virkelig klarer å bruke systemet
- Eksempel på printermenyen i word. Den kan du vise til produkteier eller sluttbruker og de vet umiddlebart hva de skal gjøre. Og utviklerne vet også hva de skal programmere.
- Hva trenger man til å lage papirprototyper?Blyant og papir, men man kan godt spe på med litt mer avanserte skyggeleggingstusjer, post-it-lapper i forskjellig farge.
- papirprototyper kan brukes til å lage ganske avanserte ting. Skjermdump fra en nettside som viser såkalt Lightbox funksjonalitet.
- Lightbox ved hjelp av papp, postit-lapper og bakepapir.
- Scrolling på iPhone
- pappPhone – en iPhone laget i papp og papir
- Utviklerne går rundt å lager løsningene på papir først – FØR de lager kjørende prototyper
- Men det er sikkert noen som er skeptiske her. - Finner det virkelige problemer? JA forskning viser at de avdekker så å si de samme problemene som kjørende prototyper gjør. Noen unntak kommer tilbake til dem!-Hva vil de tro om oss? Tanken på å vise frem noe uferdig kan være vanskelig for mange perfeksjonister der ute. Men dere vil oppleve at brukere og kolleger reagerer positivt fordi det halvferdige utseendet sier at det kan forandres og at tilbakemeldingene deres nytter. Tar opp pennen og skisser endringer.--Har vi virkelig tid til dette? Det er jo ekstra arbeid! Langt kortere tid enn å lage en kjørende prototyp – bruker en hel sprint på å si hello world, kan lage hele systemet I papir på en dag. Ofte vil papirprototyper avdekke at funksjonalitet ikke trenger å implementeres – tid spart.
- Zero coding effort. du designer systemet uten å programmere en eneste kodelinje!Selv om du er en kodeproff er det vanskelig å programmere raskere enn du lager papirprototyper – Reduserer backloggen - Planlagt funksjonalitet droppes fordi papirprototypen viser at det ikke trengs.Unngår detailpirk - Flott fancy prototyp risikerer feil feedback som “Hei, feltene er ikke på linje!” “Jeg liker ikke fargen” Papirprototyper unngår slike kommentarer – brukerne ser at det ikke er ferdig spesifisert. Oppmuntrer dem til å fokusere på overordnet konsept og funksjonalitetOppmuntrer til kreativitet. Vi blir mer kreative når vi ser noe uferdig. Får lyst til å komme med forberdingsforslag.
- Steve Krug gir en lettintroduksjontilbrukervennlighet. Hans 5 første bud er …Skalsnakkelittomdet at brukereikke liker åmåttetenke over valgoghvordan vi skalkommuniseretilbrukerne
- Liker ikkeåmåttetenke over valg,ellertenke over hva vi ser. Detteblirikkenoebedrenår vi blir stilt over for valghvor vi tror at konsekvensenavågjørenoefeilerkritisk.
- ok, detteskjønner viHmm, ok, detbetyrvelkanskje jobber. Men erdet en knapp? Ja, jegfårprøveHmm, detteskjlnnerjegikke. HvaerJobb-o-rama? Dethøresjoutsom jobber, men dethøresogsåutsomnoe mer. Ogerdeteegentligklikkbart? Jegtrorjegleterviderejeg…Regel: folk liker ikkeåmåttetenke over hvordan de skalgjørenoe. Vi leteretter den enklesteutveien – noesomsieross at vi erpårettvei. Gjørtankearbeidetminstmuligkrevende. Deterbedre med flereklikkhvor man slipper åtenke over klikkeneennfærreklikkhvor man måtenke mer.
- Fåinformasjon I mindre biter – vi klarerikkeå ta inn alt på en gangFørbrukerengjennomfleresteg med riktiginformasjon I hvertstegGi info påriktigtidspunktogbrukeksemplerogbilder for åforklareFolk forstårog husker bedrehistorierFolk lærer best fraeksemplerDetervanskelig for folk åhuske. Ikkegi all informasjon I forkantav en oppgaveoghåp at brukerskalhuske alt gjennomheleflytenVi sonerut I 30 % avtiden – fjernforstyrrendeelementerogkomtilsaken, ellers mister du oss.Kortoggodt. Gi den informasjonenbrukerentrenger, ikke “alt du kanomtemaet” oggibrukerenveiervidere
- Godefeilmeldingergirbrukeren en følelseav at detikkeer de somhargjort en feil, detgir de en løsningpåproblemetog de forklarerproblemetpåbrukerensspråk. (ikke error 404)
- Raskt å billig å rette opp feil tidligEn god måte å lære brukerne å kjenne.Man MÅ ta seg tid til brukertesting.
- Vis siden til første og beste. Fokuser på førsteinntrykket Observer, ikke si noeFolk gjør mye for en SMIL
- Gå bort til en kollega (gjerne vaskedamen eller kontordamen)Gi henne en neve twist (Utrolig hva folk gjør for en twist eller to)Vis henne prototypen din og be henne løse en oppgave som tester funksjonalitet fra backloggenHold kjeft og observer. Gå når brukeren begynner å mene noe
- Så raskt og billig at dere har ikke råd til å la være!