Förväntningar. TNM040 Kommunika4on och användargränssni= HT2015, FÖ

Transkript

1 TNM040 Kommunika4on och användargränssni= HT2015, FÖ2 Förväntningar Hoppas man lär sig något a= ha ny=a av Vidga mina vyer inom användargränssni= Se på användargränssni= från e= mer professionellt perspek4v Användbarhet i hemsidor/appar och kanske skapa något själva A= det ska vara en del programmering men även mycket kogni4v psykologi Mycket programmering för olika plaqormar Har hört a= det är en intressant samt lärorik kurs och därmed förväntar jag mig a= det kommer a= bli så A= få en grund som man sedan kan utveckla Kunskaper som man kan använda sig av i fram4den Bli en sådan som klagar på alla appar och hemsidor som inte är korrekt designade 1

2 Farhågor Flummig? A= det kommer vara alldeles för basic och därmed väldigt tråkigt A= det bara handlar teore4skt om hur allt ska uuormas Svårt a= bemästra A= det blir en för stor press A= inte klara programmeringen Idétorka Farhågor Förutbestämda projektgrupper Svårt a= jobba så många i grupp A= vissa inte 4llför något A= alla i gruppen inte tar lika mycket ansvar Hamna i en grupp med för många olika starka viljor A= det ska vara svårt för gruppen a= jobba mot samma mål så a= alla blir nöjda utan a= det blir dålig stämning i gruppen Taskiga instruk4oner A= man kör fast inte kommer någonstans A= jag inte är bra nog A= inte kunna programmeringen Många kanske redan har mycket kunskap så det blir svårt a= hänga med Tidspress Det blir för stressigt i sluuasen Redovisning inför stor publik A= redovisa men det är bra a= jag får öva på det 2

3 Önskemål Gra4s mat vid labb Idag Användbarhet Användarcentrerad design och utveckling Begrepp Ak4viteter Metoder 3

4 Design Presenta4onen påverkar tolkning, förståelse och användande Huvudsy^et med varje skärmbild ska vara uppenbar, likaså vad nästa steg är. Målet med design är a=: Skapa fokus Förhindra tvetydighet Guida användaren 4ll a= uuöra och sluuöra en uppgi^ 4

5 5

6 Jag är inte säker på vad jag ska göra här Jag undrar vad som händer om jag gör så här Jag tror inte a8 jag kan göra det jag vill Bra och dåliga gränssni= Vad gör e= gränssni= bra eller dåligt? Det finns bokstavligen hundratals eller tusentals saker som kan göra e= gränssni= bra eller dåligt. Exempel? Det är svårt a= hi=a en design som inte har problem Vad gör skillnaden mellan bra och dåligt? Varför fungerar vissa gränssni= bra för användare och inte andra? Varför fungerar vissa gränssni= bra för vissa användare men inte för andra användare? Hur kan vi uppnå en bra användbarhet (och användarupplevelse?) 6

7 Hemsidor 7

8 Modeller Design modell Användares modell Mental modell Designer Användare System Systembild Norman D (2013). The design of Everyday Things. Modeller Vi skapar mentala modeller för hur något ska användas genom 4digare erfarenheter, träning, handledning etc. En mental modell för något (ny=) skapas i stort se= genom a= vi utvärderar dess utseende och möjliga "handlingar. Norman D (2013). The design of Everyday Things. 8

9 Modeller Förväntningar Jag förväntar mig a= jag ska bli mer medveten om hur användarvänlighet ska fungera, vad folk tycker är användarvänligt. Jag vet endast vad jag tycker. 9

10 Modeller Norman ser det hela som kommunika4on/interak4on mellan två parter: Användare och designer. Kommunika4onen sker genom systembilden. Man kan säga a= designerns jobb delas upp i två problem enligt denna modell: A= förstå användarens mentala modell och skapa en bra designmodell u4från denna kunskap. A= bygga en systembild som är konsekvent och klart och tydligt förmedlar denna modell 4ll användaren. Användbarhet If something is usable it means that: A person of average (or even below average) ability and experience can figure out how to use things to accomplish something without it being more trouble than it s worth. Krug Steve (2014). Don t make me think. A common sense approach to web and mobile usability. 10

11 Användbarhet Användbarhet Interna4onell standard, ISO ger riktlinjer för användbarhet och definierar det som: "Den grad i vilken användare i e= givet sammanhang kan bruka en produkt för a= uppnå specifika mål på e= ändamålsenligt, effek4vt och för användaren 4llfredsställande sä=." 11

12 Användbarhet vik4ga faktorer Användbarhet handlar följaktligen om: Ändamålsenlighet - kan användarna uppnå det de behöver genom a= använda produkten? Effek=vitet - vilken är resursåtgången (t.ex. i 4d, kogni4v belastning)? Tillfredsställelse - vad tycker de om sin interak4on med produkten? Men dessa faktorer påverkas av: Användarna - vilka använder produkten? t.ex. är de erfarna användare eller nybörjare? Deras mål - vad försöker användarna göra med produkten - stödjer den det de vill göra? Användningssitua=onen (sammanhanget/kontext) - var och hur används produkten? Användbarhet vik4ga faktorer Ändamålsenlighet Effek4vitet Tillfredställelse Faktorer som kan mätas Påverkas av Vem användaren är Vad användaren vill göra Situa4onen (miljön/sammanhanget) Faktorer som kan specificeras 12

13 Bra och dåliga gränssni= Bra användbarhet (och användarupplevelse) kan o^ast uppnås enbart genom en användarcentrerad design Hur gör man då? Användarcentrerad design och utveckling Begrepp Ak4viteter Metoder 13

14 Tradi4onell systemutveckling visualiserad Va=enfallsmodeller Va8enfallsmodellen är en sekven4ell systemutvecklingsprocess där man ser framstegen som e= flöde (som e= va=enfall) nedåt genom olika faser: förberedelse, etablering, analys, design, konstruk4on, test, produk4onssä=ning och underhåll. Tanken är a= varje steg ska vara helt klart och bedömas innan man går vidare 4ll nästa steg. 14

15 Va=enfallsmodeller Modellen har sina rö=er i 4llverknings- och byggindustrin där det är mycket kostsamt a= införa ändringar sent i processen - om inte omöjligt. E= exempel som o^a används på va=enfallsmodellen brukar vara a= bygga e= hus. Först analyseras behoven. En arkitekt anlitas som gör en ritning. Denna ritning används för a= ta fram specifika4oner i form av olika dokument för a= få söka bygglov. Däre^er byggs huset enligt specifika4onen. Då byggna4onen påbörjats är arkitekten frikopplad och inga ändringar görs. E^er byggna4onen sker infly=ning och dri^ och underhåll av fas4gheten påbörjas. Va=enfallsmodeller Kri=k Va=enfallsmodellen har få= mycket kri4k och de flesta hävdar idag a= det är bevisat via undersökningar a= det inte fungerar för a= utveckla it- system. Exempel? 15

16 Exempel? Som många erfarit är det problem med a= ladda upp filer i Lisam. Det är olyckligt och det finns en bug i systemet som jag inte var medveten om om nu ngn har varit det. Det har fa=ats e= beslut om a= sjösä=a e= storskaligt system som inte är i närheten av a= vara väl testat. Det krävdes inte mkt exper4s från lärare och studenter för a= hi=a flera allvarliga buggar. Fri= översa= från anonym lärare, Hur ska vi nå hit? Ta reda på behov, presentera förslag, KOMMUNICERA, visualisera, testa, gör om och gör rä=. 16

17 Användarcentrerad systemdesign E= sä= a= förhålla sig 4ll utveckling och 4llse a= resultatet blir användbart. Användarcentrerad systemdesign Användare De som kommer a= använda systemet Inte de som beställer systemet Det finns inget subs4tut för rik4ga användare Centrerad Användarna involveras ak4vt under hela processen Användarna ska inte vara passiva och bara tycka 4ll om färdiga lösningar, de ska vara med och ta fram dem Design Design är främst en process Design kan också vara en representa4on av en produkt under processen 17

18 Gulliksen Jan och Göransson Bengt (2002). Användarcentrerad systemdesign : en process med fokus på användare och användbarhet. Analysera Användare Användningsammanhang Behov, användbarhetskrav Uppgi^er, scenarier, användarhistorier Designmål, använbarhetsmål (ska vara meningsfulla, mätbara på något sä=) 18

19 Användare En analys av olika typer av användare och deras användande sa= i rela4on 4ll sy^et med gränssni=et. För varje kategori användare behöver man veta: Vem (egenskaper) Var (miljö för användandet) Vad (uppgi^er och mål) Användare Vilka är användarna? Kunskap, färdigheter, förmågor Erfarenhet Utbildning Fysiska a=ribut, funk4onsnedsä=ningar Autyder, preferenser, vanor Kategorisera och prioritera 19

20 Kontext, miljö Miljö (kontor, fabrik, i fält, hemma, mobilt, café etc.) Typ av enhet/prestanda Arbetsyta Skärmstorlek/upplösning Bandbredd Etc Uppgi^er och mål Sy^e Frekvens av användande Varak4ghet Arbets- /uppgi^sflöde Förutsä=ningar Förväntningar Mo4va4on 20

21 Metoder Mer 4dskrävande ak4viteter observa4oner, kontextuella intervjuer, fältstudier Hur ser användningssitua4onen ut i verkligheten? Hur uuör användare sina uppgi^er i verkligheten/idag? O4llfredsställda krav/behov? Utmaningar? Restrik4oner? Vad kan man göra för a= stödja användarna bä=re? Naturlig användningssitua4on, pålitlig data, 4llåter insamling av tyst kunskap Metoder Granskning av existerande produkter konkurrenter Vad är implementerat och hur (idéer a= använda, saker a= undvika) 21

22 Metoder Kortare ak4viteter enkla 5 minuters intervjuer ( Haffa någon vid fikat ) Typiska anledningar för a= använda hemsidan, appen, spelet etc. Vad saknas, är problema4skt med nuvarande lösning om sådan finns? Vad vill man ha snabb 4llgång 4ll? Ändrat? Tillagt? Etc. Vad vill man ha? Tillräckligt många användare 4llfrågade dela in i målgrupp, användarroll, annan bakgrundsinforma4on. Persona En persona är en imaginär bild av en användarroll. En fik4v men realis4sk person. Personas sä=er fokus på specifika användare snarare än vem som helst Skapa personor kräver mer än a= bara ger e= namn 4ll en användarroll. O^a använder man också e= foto. En persona bör beskrivas 4llräckligt väl så a= alla i teamet känner a= de vet det mesta om den personen/kan föreställa sig den. Personor är e= verktyg för a= skapa/öka designempa4 Personor kan hjälpa alla i projektet a= förstå behov och användarmål. Vad vill just den här personan göra här? De är en bra hjälp när man prioriterar funk4oner och innehåll. Om den föreslagna funk4onen inte är användbar för någon av produktens personor så bör den troligtvis inte utvecklas. 22

23 h=p:// material- och- guider/mall- for- a=- skapa- personas Appendix 2. Persona Mike Mike Mike is an middle aged man who is very interested! in technology!!! Mike is a middle aged man who lives together with his spouse Therese in the central of the Linköping. He and Therese don t own a car because they live so close to where they work and owning a car is therefore more hassle than using public transportation and walking. Since he was a small child mike has been interested in technology. He early got to use the family computer and got introduced to the pc gaming world at a young age. This continued through his entire life. He updates himself frequently what is new and on the horizon on the fields of computer parts, pads, TVs, gaming platforms and mobile devices. When he buys something he always checks the Internet for reviews and comments on the thing he is planning to buy. This way he knows what the pros and cons of the product are. Because of his interest in computers and random things he often is interested in new and fun technology. Even though mike has a technology interest, his interest for technology that is home related, such as appliances, boiler or floor heating, is lacking. The reason is that he doesn t know as much about that area compared to other areas of technology. This results in Therese having a better understanding when it comes to this area of the house. Mike would be more interested if that technology would appeal to him more with a better GUI, interesting features and compatibility with other devices such as Smartphones.!! <;48#!.)*;!:*)+!*'=! '$*->/;48#!+4$4&4'#! Age: 33 years Occupation: Programmer Income: kr! Goals "#$!$%#!&#'$!()*+,-$!.*)!$%#!&#'$!()/-#! 0../-/#1$! 2**3!.#4$,)#'! 2*11#-$/5/$6!&#$7##1! +/..#)#1$!$%/18'!! Traits 9/8!/1$#)#'$!/1! $#-%1*3*86! :#33!/1.*);#+! "**+!7/$%! $#-%1*3*86!43$%*,8%! 1*$!7/$%!%*;#! )#34$#+! 23

24 Appendix 1. Persona Lauren Lauren Lauren is a middle age woman who likes new technological! things, but she also is very economical! in her decisions Lauren is a middle age woman who lives together with her husband Fred and their daughter Kim at the outskirts of Linköping. She drives every day to work. On her way to work she usually drives Kim to school. The distance to Fred s workplace is not as far from home as Lauren, so he usually takes the bus. She owns an Iphone that she uses in her line of work and in her private life. The Iphone s design really charms Lauren as she likes the sleek and stylized look of apple products. She owns several apple products and when it comes to technology and apple she is often the first to buy it. Although she might not be that good at using all the product s features, she likes new things in general. She doesn t however own an Ipad. Though she has a sweet spot for apple products, which are in general more expensive, she has an economical side. She often weighs the pros and cons between products before considering buying them. But when gadgets or things that she is considering buying are going to be displayed publicly in her house, she often let s the design-aspect of the product weigh heavily. "#$%&'#!()!*#+!#$(,(-.$%/!'.0#!'*#!()1#,!2/%,'!%,0! %,%/34#'!%'2#$1'!()!1*#!*(-#!#$(,(-35!1(!'%6#!!!! Age: 48 years Occupation: Consult Income: kr! Goals! H-%:#!)+(-!@(+0!('I! '1($9.-%:#!0%1%;%'#!?((0!6%/&#! 6%+.%;/#'! A%'3!1(!-%.,1%.,! "#!.,!$(,1+(/! B(1!1((!$&-;#+'(-#!!! Scenarier E= scenario är en (uuörlig) beskrivning av en människas interak4on med e= system. När en persona sä=s in i e= scenario (en berä=else) kommer den 4ll liv. Scenarier beskriver och sammanfa=ar det som kommit fram i studier/analyser. Scenarier kan användas under design för a= säkerställa a= alla deltagare förstår och samtycker 4ll dem, samt för a= specificera exakt vilken interak4onen systemet måste stödja. Översä= (och bryt ned) scenarier i uppgi^er för a= genomföra utveckling/design, granskningar och användartester. 24

25 Användarhistorier - user stories En användarhistoria är en kort beskrivning i vardagligt språk av vad en användare vill uppnå. E= bra sä= för a= beskriva behov, önskemål, krav. Skrivs med fördel så a= den dokumenterar behov, önskemål, krav ur en slutanvändarens perspek4v. Användarhistorier - user stories Som en roll Vill jag göra något Så a= jag uppnår något 25

26 Användbarhetsmål Det ska vara användarvänligt? Det ska ha e= gränssni= som är lä= a= använda? Det ska vara lä= a= lära? Det ska följa xxx designprinciper/styleguide? Dessa är inte mätbara! Användbarhetsmål Användbarhetsmål hjälper en a= hålla fokus på det som är vik4gt! De hjälper 4ll a= prioritera! Användbarhetsmål hjälper en a= skapa förväntade mål och man har något a= mäta 4lls målet är uppnå=. Var överens om vad som krävs för a= e= mål ska vara uppnå=! Vad är er defini4on av klart? 26

27 Användbarhetsmål Exempel på mål: 95% av användarna ska kunna registrera sig på första försöket 90% av användarna ska kunna genomföra en bokning, max4d 2 minuter En oerfaren användare (en viss användarroll) ska kunna hi=a informa4on om X under en viss 4d Y eller med e= visst antal klick Användare ska vara 4llfredsställda med medelbetyg X eller högre e^er a= ha spelat spelet Max 3% av användarna ska behöva hjälp (från hjälp/support, informa4on) Standarder och guidelines ska följas Designkraven möts Användare och krav (behov) Vanliga metoder för datainsamling och analys: Enkäter Intervju Fokusgrupp Fältstudier Observa4on Utvärdering av existerande produkter Personas och användarscenarier, användarhistorier Uppgi^sanalys Formulering av användbarhetsmål och övergripande designkriterier h=p:// 27

28 Bra överblick h=p:// anvandbarhet/metoder Bra överblick h=p:// 28

29 Bra överblick Gulliksen Jan och Göransson Bengt (2002). Användarcentrerad systemdesign : en process med fokus på användare och användbarhet. 29

30 Referenser Gulliksen Jan och Göransson Bengt, Användarcentrerad systemdesign : en process med fokus på användare och användbarhet. Norman Donald, The design of everyday things. Nielsen Jacob, Usability Engineering. Krug Steve Don t make me think. 30