Förväntningar. Farhågor. Förväntningar projekt. Farhågor projekt. Idag 8/31/16. TNM040 Kommunikation och användargränssnitt HT2016, FÖ2.

Transkript

1 TNM040 Kommunikation och användargränssnitt HT2016, FÖ2 Förväntningar Inga Lära mig utveckla användargränssnitt Lära mig hur design kan påverka användares upplevelse Lära mig hur man på bästa sätt tar hänsyn till användarna Att få lära sig nya kunskaper som man kan använda i kommande kurser och projekt. (Metoder etc.) Psykologidelen låter superspännande Lära mig mer om de psykologiska faktorerna användargränssnitt kan ha Att vi kommer får arbeta kreativt Att få göra appar (förhoppningsvis så är det lättj ) Bra omväxling till att läsa matte Att redovisningsformen passar mig alltså inga tentor Behaglig men förhoppningsvis intressant Inte för tidskrävande Inte för enkel, inte för lätt, lagom Farhågor Förväntningar projekt Spretigt innehåll som är svårt att följa Ointressant eller tråkig Att kursen inte kommer att ge mig något Bara lära sig saker som endast är nödvändiga för denna kurs och inte senare användas i yrkeslivet Att det blir en flummig kurs där det är svårt att veta vad man egentligen ska lära sig Att läsa långa texter med mycket information Mycket att skriva Att andra kurser - tung matte/fysik kommer att ta tid- att kursen kommer att komma i kläm, svårt att balansera med övriga studier Att ha glömt saker från tidigare kurser som behövs för denna Programmeringen (begränsar kreativiteten) Att hamna efter, att inte få hjälp när man behöver Inte tillräckligt med material och information. Det fanns ingen planering eller dylikt att hitta innan kursstart. Skapa något kul tillsammans Välja grupp själv Organisera arbetet själv Ser fram mot att jobba i större grupper, utmanande och förberedande, mycket planering Lära oss mycket Användarvänligt tänkande Att fokus ligger på design och användarvänlighet och inte att programmeringen måste vara perfekt Att lära sig något vettigt Mindre fokus på kod tekniska detaljer Evaluera design mycket Problem som skissas ner, mycket rita design Att det finns tillräckligt med tid för projektet Bra handledning Bra feedback Mycket egentid för arbete briljera utan gränser. Och bra lärarledning som inspirerar och motiverar Givande och något man kan använda på cv:t Make a killer GUI Få en slutprodukt som känns klar på riktigt och inte känna att det blev halvdant Farhågor projekt Att ej få avsluta påbörjat projekt. Har hört talas om att detta är vanligt av gamla koma- kursare Att idén är jättebra och att allt är väl genomtänkt men att inget fungerar ordentligt Att det inte finns tid för projektet att de andra kurserna äter upp all tid För svårt. Att det innehåller delar som vi förväntas kunna (lära oss på egen hand) Hamna i dålig grupp som inte siktar mot samma mål andra som glider med olika önskemål samarbetsproblem Frihet i det man vill skapa men också tydliga riktlinjer för vad som behöver göras Att uppgifterna är diffusa och man fokuserar på fel saker Svårt att välja något intressant att göra Komma på idén helt själv, svårt komma på idé till GUI Tråkigt ämne (typ mat- app eller annat vardagligt syfte) Idag Användbarhet Användarcentrerad design och utveckling Begrepp Metoder/ramverk Aktiviteter Att rapportbeskrivningen är oklar Lång presentation Pepparkakor 1

2 Reflektion rundtur Modeller Fungerade gränssnitten på ett tillfredsställandesätt? Var det lätt att lista ut /förstå hur de borde fungera? Stämde de överens med era erfarenheter, förväntningar? Vi skapar mentala modeller för hur något ska användas genom tidigare erfarenheter, träning, handledning etc. En mental modell för något (nytt) skapas i stort sett genom att vi utvärderar dess utseende, och möjliga handlingar. Norman D. (2013). The Design of Everyday Things. Modeller Modeller Norman beskriver det hela som kommunikation/interaktion mellan två parter: Användaren och Designern. Kommunikationen sker genom systembilden (användargränssnittet). Design modell Användares modell Mental modell Designer Användare System Systembild Norman D (2013). The design of Everyday Things. Norman D. (2013). The Design of Everyday Things. Modeller Norman ser det hela som kommunikation/interaktion mellan två parter: Användaren och Designern. Kommunikationen sker genom systembilden (användargränssnittet). Man kan säga att designerns jobb delas upp i två problem enligt denna modell: Att förstå användarens mentala modell och skapa en bra designmodell utifrån denna kunskap. Att bygga en systembild (användargränssnitt) somär konsekvent och klart och tydligt förmedlar denna modell till användaren. The user interface is the system for a user the rest is just a black box. If the user interface dosesn t work, it doesn t matter what kinds of algorithms there are in the box. Computer World, March 2nd, Norman D. (2013). The Design of Everyday Things. 2

3 Reflektion rundtur Hur bör utvecklare/designers arbeta? Vad felar? Resultat Ofta: För lite fokus på användbarhet Ingen eller undermålig användarcentrerad utvecklingsprocess. Användbarhet Internationell standard, ISO ger riktlinjer för användbarhet och definierar det som: "Den grad i vilken användare i ett givet sammanhang kan bruka en produkt för att uppnå specifika mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt." Användbarhet Användbarhet handlar följaktligen om: Ändamålsenlighet - kan användarna uppnå det de vill genom att använda produkten? Uppnå givna mål? Effektivitet - vilken är resursåtgången (t.ex. i tid, kognitiv belastning)? Tillfredsställelse - vad tycker de om produkten? Och 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 vad användarna vill göra? Användningssituationen (sammanhanget/kontext) - var och hur används produkten? Användbarhet Användbarhet Nyare ansatser fokuserar på: känslor upplevelser handlingsbarhet spelbarhet (tillfredsställelse, effektivitet, immersion, känsla, socialisering, motivation) Oavsett definition så är det viktigaste är att definiera och tydligt beskriva vad som avses 3

4 Uppgift Användning och användbarhet Rita en gunga Arbeta enskilt 5-7 min Det finns inte två människor som gör lika. Det finns inga dumma användare bara oförutsedd användning. Människor gör fel. Det är oftast inte deras fel. Användning och användbarhet Användning och användbarhet Användning och användbarhet Hur gör man då? Det finns inte två människor som gör lika. Det finns inga dumma användare bara oförutsedd användning. Människor gör fel. Bra användbarhet (och användarupplevelse) kan oftast uppnås enbart genom ett användarcentrerat arbete Användarcentrerad design och utveckling Begrepp Metoder/ramverk Aktiviteter Det är oftast inte deras fel. 4

5 Hur gör man då? Traditionell systemutveckling visualiserad I ett systemutvecklingsprojekt ska man i ett antal steg: ta fram behov/önskningar/krav etc. på systemet designa konstruera införa- implementera testa utvärdera och följa upp kontinuerligt underhålla och utveckla Vattenfallsmodeller Vattenfallsmodeller Vattenfallsmodellen är en sekventiell systemutvecklingsprocess där man ser framstegen som ett flöde (som ett vattenfall) nedåt genom olika faser: förberedelse, etablering, analys, design, konstruktion, test, produktionssättning och underhåll. Tanken är att varje steg ska vara helt klart och bedömas innan man går vidare till nästa steg. Modellen har sina rötter i tillverknings- och byggindustrin där det är mycket kostsamt att införa ändringar sent i processen - om inte omöjligt. Ett exempel som ofta används på vattenfallsmodellen brukar vara att bygga ett hus: Först analyseras behoven. En arkitekt anlitas som gör en ritning. Denna ritning används för att ta fram specifikationer i form av olika dokument för att få söka bygglov. Därefter byggs huset enligt specifikationen. Då byggnationen påbörjats är arkitekten frikopplad och inga ändringar görs. Efter byggnationen sker inflyttning och drift och underhåll av fastigheten påbörjas. Fungerar bra i projekt som är väldefinierade, förutsägbara och där det är osannolikt att det blir större förändringar. Vattenfallsmodeller Hur ska vi nå hit? Kritik Vattenfallsmodellen har fått mycket kritik och många hävdar idag att det det inte fungerar för att utveckla it- system (ofta mer komplexa än hus). Ta reda på behov, presentera förslag, KOMMUNICERA, visualisera, testa, gör om och gör rätt. 5

6 Agil systemutveckling Exempel: Scrum Agil systemutveckling är ett samlingsnamn för ett antal programutvecklingsmetodiker som kan användas vid programvaruutveckling, även kallade lättrörliga metoder. Arbeta med processer/metoder/ramverk/processer som tillåter och hanterar förändring i projekt. Jämfört med tidigare metoder/modeller representerar de agila mer flexibla sätt att arbeta och de hanterar förändring. Metoderna följer i stort sett samma värderingar, principer och synsätt Vattenfall- vs. agila metoder Exempel? Som många erfarit är det problem med att ladda upp filer i Lisam. Det är olyckligt och det finns en bug i systemet som jag inte var medveten om om nu någon har varit det. Det har fattats ett beslut om att sjösätta ett storskaligt system som inte är i närheten av att vara väl testat. Det krävdes inte mkt expertis från lärare och studenter för att hitta flera allvarliga buggar. (Delvis misslyckade) Fritt översatt från anonym lärare, Användarcentrerad systemdesign Ett sätt att förhålla sig till utveckling och tillse att resultatet blir användbart. Användarcentrerad systemdesign Användare De som kommer att interagera med systemet Inte de som beställer systemet Det finns inget substitut för riktiga användare Centrerad Användarna involveras aktivt under hela processen Användarna ska inte vara passiva och bara tycka till 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 representation av en produkt under processen 6

7 Användarcentrerad systemdesign Användarcentrerad design i mjukvaru- eller produktutveckling fokuserar speciellt på att göra produkter användbara. Vanligtvis involveras slutanvändare genomhela utvecklingscykeln. Deras feedback på tidiga designidéer och prototyper tas tillvara för att iterera framur användbarhetssynpunkt bättre idé/prototyper och slutligen ett färdigt koncept. Att följa denna process i utvecklingen av en IT- produkt resulterar i ett antal viktiga fördelar för utvecklaren, genomatt skapa produkter som: Är lättare att förstå och att använda, vilket reducerar kostnader för utbildning och support. Förbättrar livskvaliteten för användarna genom att reducera stress och öka tillfredsställelsen. Tydligt förbättrar ändamålsenligheten och effektiviteten för individuella användare och för hela organisationen. anvandbarhet/metoder.php Gulliksen Jan och Göransson Bengt (2002). Användarcentrerad systemdesign : en process med fokus på användare och användbarhet. Användare/målgrupper Att analysera och kartlägga användare/målgrupper ska svara på frågor om vilka användarna är och vilka egenskaper hos användarna som är viktiga för det aktuella systemet. Gulliksen Jan och Göransson Bengt (2002). Användarcentrerad systemdesign : en process med fokus på användare och användbarhet. Användare/målgrupper Viktigt att kartlägga attityder, preferenser, vanor kunskap, färdigheter, förmågor erfarenhet utbildning fysiska attribut, funktionsnedsättningar Beskriv, kategorisera och prioritera (om nödvändigt) Persona En persona är en imaginär bild av en användarroll. En fiktiv men realistisk person. Personas sätter fokus på specifika användare snarare än vem som helst En persona bör beskrivas tillräckligt väl så att alla i teamet känner att de vet det mesta om den personen/kan föreställa sig den. Skapa personor kräver mer än att bara ger ett namn till en användarroll. Ofta använder man också ett foto. Personor är ett verktyg för att skapa/öka designempati Personor kan hjälpa alla i projektet att 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 funktioner och innehåll. Om den föreslagna funktionen inte är användbar för någon av produktens personor så bör den förmodligen inte utvecklas. 7

8 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. H-%:#)+(-@(+0('I '1($9.-%:#0%1%;%'# Age: 48 years Occupation: Consult Income: kr Goals?((06%/&# 6%+.%;/#' A%'31(-%.,1%., "#.,$(,1+(/ B(11(($&-;#+'(-# material- och- guider/mall- for- att- skapa- personas "#$%&'#()*#+#$(,(-.$%/'.0#'*#()1#,2/%,'%,0 %,%/34#'%'2#$1'()1*#*(-##$(,(-351('%6# Situation/kontext/sammanhang Behov/krav Att analysera användningssituationen (kallas också kontextuell analys, sammanhangsanalys) fokuserar på den omgivning som användaren verkar eller kommer att verka i. Det inkluderar aspekter på den fysiska miljön likväl som som den sociala. Fysisk: ljust, mörkt, bullrigt, skakigt, stående, liggande Social: individuellt, i par/grupp, tillsammans, på avstånd Skärmstorlek, prestanda, uppkoppling etc. Att identifiera användares behov/krav innebär att hitta svar på vad de vill ha, vad de önskar, kräver av det aktuella systemet. Funktionella vad systemet ska göra Icke funktionella responstid antal klick, swipes etc. Scenarier och uppgifter Behov och krav kan beskrivas med scenarier, uppgifter och användarhistorier. Scenarier Scenarier beskriver och sammanfattar det som kommit fram i olika studier/analyser eller så identifieras tänkta scenarier (vid ren nydesign). Ett scenario är en (utförlig) beskrivning av en människas interaktion med ett system. vilka händelser inträffar, kan inträffa? När en persona sätts in i ett scenario (en berättelse) kommer den till liv. Scenarier kan användas under design för att säkerställa att alla deltagare (utvecklare och användare) förstår och samtycker till dem, samt för att specificera exakt vilken interaktionen systemet måste stödja. Översätt (och bryt ned) scenarier i (någon form) av uppgifter för att genomföra utveckling/design, granskningar och användartester. 8

9 Användarhistorier - user stories En användarhistoria är en kort beskrivning i vardagligt språk av vad en användare vill uppnå. Ett bra sätt för att beskriva behov, önskemål, krav. skrivs med fördel så att den dokumenterar behov, önskemål, krav ur en slutanvändarens perspektiv. Användarhistorier - user stories Som en roll Vill jag göra något Så att jag uppnår något Uppgifter Användbarhetskrav/mål Vilka specifika uppgifter ska användarna utföra (för att göra något och uppnå något) och hur ska dessa genomföras. Definierar uppgifter i termer av handlingar och/eller kognitiva processer. När uppgifterna är definierade, kan funktionaliteten som krävs för att stödja dessa specificeras. Definitionerna av användbarhet Det ska vara användarvänligt? Det ska ha ett gränssnitt som är lätt att använda? Det ska vara lätt att lära? Det ska följa xxx designprinciper/styleguide? Dessa är inte direkt mätbara 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 X, maxtid 2 minuter En oerfaren användare (en viss användarroll) ska kunna hitta önskad information om X under en viss tid Y eller med ett visst antal klick Användare ska vara tillfredsställda med medelbetyg X eller högre efter att ha spelat spelet Minst 75% av användarna ska svara JA på fråga X Max 3% av användarna ska behöva hjälp (från hjälp/support, information) Standarder och guidelines ska följas Designkrav ska nås/mötas Användbarhetsmål Användbarhetsmål hjälper en att hålla fokus på det som är viktigt De hjälper till att prioritera Användbarhetsmål hjälper en att skapa förväntade mål och man har något att mäta för att se att målet är uppnått. Var överens om vad som krävs för att ett mål ska vara uppnått Vad är er definition av klart? 9

10 Metoder Metoder Kortare aktiviteter enkla 5 minuters intervjuer ( Haffa någon vid fikat ) Vad vill man ha? Typiska anledningar/motiv för att använda hemsidan, appen, spelet etc. Vad saknas, är problematiskt med nuvarande lösning om sådan finns? Hur vill man att något ska fungera? Vad vill man ha snabb tillgång till? Ändrat? Tillagt? Etc. Tillräckligt många användare tillfrågade dela in i användare, målgrupp, annan viktig bakgrundsinformation. Skriv scenarier, användarhistorier etc. Mer tidskrävande aktiviteter observationer, kontextuella intervjuer, fältstudier hur ser användningssituationen ut i verkligheten? hur utför användare sina uppgifter i verkligheten/idag? otillfredsställda krav/behov? Utmaningar? Restriktioner? vad kan man göra för att stödja användarna och deras upplevelse bättre? Utförda i en naturlig användningssituation är bra: pålitlig data, tillåter insamling av tyst kunskap. Metoder Att minnas Vanliga metoder Fältstudier Observation Enkäter Intervju Fokusgrupp Granskning av existerande produkter Vikten av att förstå användares mentala modeller Användbarhet Definition Exempel/ Poäng Användarcentrerad systemdesign definition aktiviteter metoder, tekniker Kursens relevans för MT nu och i framtiden (kurser, exjobb, arbete) anvandbarhet/metoder.php Tack Vi ses på måndag 5e. Marcus Nygren Developing a Mobile Learning Application for Entrepreneurship Education in Uganda and Zambia. Utveckling - Användarcentrerat angreppsätt. 10