Rest Best - NO
Rest Best Oppskriftsapp for studenter med rester uten peiling 1 Innhold Problembeskrivelse ................................................................................................................................................................................................................ 4 Situasjonen slik vi ser den i dag ...................................................................................................................................................................... 4 Oppgaven ........................................................................................................................................................................................................ 5 Generelle Kravspesifikasjon ................................................................................................................................................................................................... 6 Kvalitetspesifikasjon ....................................................................................................................................................................................... 6 Spørreundersøkelse ........................................................................................................................................................................................ 6 Intervju ............................................................................................................................................................................................................ 7 Resultater av spørreundersøkelse og intervju................................................................................................................................................ 7 Designfilosofi ........................................................................................................................................................................................................................ 10 Papirprototype .............................................................................................................................................................................................. 10 Informasjonsinnhenting............................................................................................................................................................................ 10 Idéer .......................................................................................................................................................................................................... 11 Første designutkast................................................................................................................................................................................... 11 Vårt Mål .................................................................................................................................................................................................... 14 Axure Wireframe .................................................................................................................................................................................................................. 15 Brukertesting: Fra papirprototype til Axure wireframe...................................................................................................................................................... 17 Prototyping: papir kontra software .............................................................................................................................................................. 18 Testprosedyre ............................................................................................................................................................................................... 19 Lokasjon og atmosfære............................................................................................................................................................................. 19 Personas og scenarioer ............................................................................................................................................................................. 20 2 Testere ...................................................................................................................................................................................................... 22 Resultat og analyse ................................................................................................................................................................................... 23 Brukergrupper reagerer forskjellig ........................................................................................................................................................... 24 Konsistens var manglende ........................................................................................................................................................................ 24 Kunnskap i verden..................................................................................................................................................................................... 25 Simplifisér ................................................................................................................................................................................................. 25 SUS skjema ................................................................................................................................................................................................ 27 Oppsummering av analyse ....................................................................................................................................................................... 29 Eyetracking................................................................................................................................................................................................ 29 Oppsummering ..................................................................................................................................................................................................................... 31 Hva lærte vi? ................................................................................................................................................................................................. 31 Videreutvikling .............................................................................................................................................................................................. 32 Nytt prosjekt ................................................................................................................................................................................................. 33 Tverrfaglig Refleksjon ................................................................................................................................................................................... 33 Verktøy ................................................................................................................................................................................................................................. 35 Facebook ....................................................................................................................................................................................................... 35 Google Drive ................................................................................................................................................................................................. 35 Trello ............................................................................................................................................................................................................. 36 Microsoft Word............................................................................................................................................................................................. 36 Kilder ..................................................................................................................................................................................................................................... 37 3 Problembeskrivelse Situasjonen slik vi ser den i dag Ut ifra selvstendige observasjoner ser det ut til at mange av dagens studenter har dårlige matvaner. Faktorer som økonomi, tidsbegrensninger, mangel på livserfaring og stabilitet i hverdagen fører til at studenter ofte favoriserer raske, usunne og generelt dårlige matløsninger. Vi ser det som et problem at mange studenter lager for mye ferdigmat og disse løsningene er ofte ugunstige. Man er enten tvunget til å kjøpe billig- og usunn, eller dyr- og sunn ferdigmat. Gode råvarer, som kjøtt og grønnsaker, er også ofte for dyre for studenten. Studenter er også beryktet for å kaste mye mat. Dårlig rutine, samt liten kjennskap om matvarer fører til at studenter ikke vet hvor lenge mat holder. I tillegg vet ikke den kulinarisk uskolerte studenten hva mat som har gått ut på dato kan brukes til. Det er verdt å nevne at dette gjelder ikke for alle studenter, og mange føler de behersker matvanene sine godt. 4 Oppgaven “Den nye generasjonen Målgruppen er studenter. Dere skal Facebook og Twitter. mobiltelefoner og tablets, med observere og intervjue denne Sentralt i faget er idéen om iPhone/iPad og Androidenheter som målgruppen, finne ut hva de kunne brukersentrert design og iterative eksempler, åpner opp for en rekke ønske seg på en smarttelefon og lage prosesser. Det er derfor viktig å ikke nye bruksområder. Dere skal i denne en prototype av en løsning. Denne bruke unødvendig lang tid på oppgaven utvikle en app/tjeneste for skal så testes med faktiske brukere. konseptutvikling slik at man får tid en slik enhet for bruk i forhold til mat og studenter. til de nødvendige rundene med Vi oppfordrer til å se på mulige brukere.” koblinger mot sosiale medier som Tema Mat Målgruppe Studenter Felt Applikasjon til mobile enheter Alternativ Tilkobling Sosiale medier Agenda Forbedre matvaner til studenter med en ny app. Skjult Agenda Lære seg om brukersentrert design og iterative prosesser. Tabell 1. Oppsummering av oppgaven. 5 Generelle Kravspesifikasjon Kvalitetspesifikasjon – Brukbarhet. - Produktet skal være selvforklarende og intuitivt å bruke. – Visuelt tiltrekkende - Produktet skal virke profesjonelt i sin ytre framtoning. – Produktet skal være selvmotiverende. - Dess mer man bruker det, dess mer får man lyst til å bruke det. – Innholdsmessig korrekt. - I den grad produktet formidler informasjon skal denne være til å stole på. – Inkluderende/Universell design. Selv om produktet bør være flerspråklig, skal det kun lages en norsk versjon i dette prosjektet. Spørreundersøkelse Etter idémyldringen satte vi sammen en så fokuserte vi på å skaffe studenter til spørreundersøkelsen spørreundersøkelse på ca 20 spørsmål som skulle samle inn fra ulike studentmiljøer, som NTNU, UiB, Lyngby VUC i kvantitativ data om situasjonen, både for å teste ut om våre Danmark, og HiST. idéer hadde potensiale, og for å se om vår forståelse av situasjonen samsvarte med realiteten. Fordelene med en spørreundersøkelse er at det koster ikke brukeren mye energi å fylle ut, og derfor var det enklere å samle inn større mengder data. Siden spørreundersøkelsen ble brukt til å teste potensialet for våre idéer, så var det viktig at vi ikke ladet spørsmålet slik at det var større sannsynlighet for at folk svarte i vårt favør, da ville vi ha gjort oss selv en bjørnetjeneste. For å forbedre kvaliteten av informasjonen 6 Intervju Resultater av spørreundersøkelse og intervju For å få en kvalitativ og dypere forståelse av matsituasjonen Ut ifra resultatene fikk vi et bedre overblikk av hvordan til studentene, så gjorde vi noen intervjuer. Intervjuene situasjonen for studenter er i dag. Som beskrevet tidligere brukte vi for å få kjøtt på beina av spørreundersøkelsen. så faller en del studenter innefor rammen av ensformige Hvis studentene hadde svart i spørreundersøkelsen at de matvaner. syntes at de kastet mye mat, så kunne vi gjennom intervjuet finne årsak og under hvilken omstendigheter de kastet mat. I likhet med spørreundersøkelsen, så var fokuset at vi “Mye ferdigmat. Noe grandis og sånt noen. Taco, pølser, ...” Fredrik skaffet studenter fra ulike studentmiljøer for å bedre og sikre kvaliteten av informasjonen. Langt ifra alle falt innenfor denne rammen, vi observerte at studenter som ikke var ensformige med matvaner var positiv for matvaneforbedring. Basert på dette og mer direkte spørsmål, som spørsmål tre i tabell 2, så har ble det oppdrift rundt idéen om å gjøre noe med matrester, og konseptet som ville forme appen Rest Best ble til. “Et redskap som vil hjelpe til å bruke opp rester i stede for å kaste det, er fantastisk.” Merete 7 Perspektivet på deling av matbilder over sosialer medier er at det er populært. Spørreundersøkelsen derimot viste at dette stemmer ikke helt, i hvert fall ikke blant studentmengden vi spurte. Her fant vi ut av at de fleste ikke deler matopplevelsene sine, og at de fleste ikke er interessert i å se andre dele matopplevelsene sine. Dette fremgår av første og andre spørsmål i tabell 2. Derfor valgte vi å gå bort fra idéen om å gjøre sosiale medier som en sentral idé bak appen vi skulle lage. Mange var derimot veldig åpne for idéen om å loggføre matvaner som sett ut ifra det fjerde spørsmålet. Ut ifra intervjuene derimot, fikk vi inntrykk av at hvis de skulle bruke det, burde det være enkelt å utføre. “Hadde du hatt interesse i å være mer oppmerksom på hva du spiser gjennom uka? Jo, men ikke hvis det ble for mye arbeid” Anna 8 Tabell 2. Et utsnitt av noen innlegg fra spørreundersøkelsen. ’Avg’ feltet regner gjennomsnittet av alle resultater, ikke bare de dataene vi har vist i utsnittet. 9 Designfilosofi Papirprototype Informasjonsinnhenting Designbeslutningene startet ved at gruppen satt seg ned og gikk i gjennom problemstillingen, for å bli godt kjent med den. Deretter startet en intensiv idémyldring der fokuset var å finne et mulig behov for studenter med fokus på mat, som kan løses med en applikasjon. Etter hvert som idéene dukket opp, var det satt en diskusjon hvor eventuelle fordeler og ulemper ble diskutert. I tillegg var det et fokus på å undersøke om en slik mobil applikasjon allerede fantes på markedet og om den var god nok. Gruppen var klar over at applikasjonsmarkedet allerede har mange applikasjoner rundt mat, men at ikke alle var nødvendigvis godt nok gjennomført og brukertestet. Idéene tok utgangspunkt i gruppemedlemmenes behov i hverdagen. 10 Idéer Første designutkast Tre idéer kom som spesielt fremtredende; app for å Ettersom idéene var klargjort, satte vi først i gang med å loggføre studentens matvaner, app for å dele studentens skissere første utkast av designet for applikasjonen. favorittoppskrifter og en app som vil generere en oppskrift Vi valgte å gå for et simpelt og rent design, der intuitivt var på et måltid ut ifra de restene studenten har. Ettersom høyt prioritert. Designet skulle dessuten være moderne og disse idéene baserte seg i vårt behov, var det neste steget å enkelt å navigere. Derfor valgte vi å lage menyer og utføre feltarbeid. Feltarbeidet innebar intervjuer med knapper som assosierte med kjente programvarer og apper forskjellige studenter, samt en spørreundersøkelse i som majoriteten av brukerne brukte. forbindelse med idéene. Dette ville gi gruppen kvalitativ informasjon og kvantitativ statistikk på om idéene var For å skissere designet prøvde vi først å bruke et nettbasert etterspurt blant studenter. Analysering av dataene som tegneprogram, Draw.io. Etter hvert oppdaget vi at det ble ble samlet ga et godt grunnlag for å se hvilken idé som var mye tidsbruk på å lage alle sidene. Det var i tillegg lovende å brukerteste og videreutvikle. vanskelig å dele filene innad gruppa for å jobbe på flere oppgaver i sanntid, samt at utskriftene ble ofte vanskelige Brukerne var positive til konseptet om å kunne finne frem og bruke. I og med at vi møtte på problemer med dette, falt oppskrifter basert på hvilke rester man har liggende i det oss inn at en håndtegnet papirprototype ville gi oss kjøleskapet. Det ble også vist interesse for loggføring av fordeler. Det ble med en gang enklere og gjennomføre matvaner. Deling av matoppskrifter over sosiale medier kreative visjoner, samtidig med designprosessen ble mere var derimot ikke oppfattet som ønskelig eller nyttig, og ble dynamisk. derfor droppet. 11 Etter gjentakende forsøk på å lage en Kameraknappen i brukeren muligheten å favorisere hovedmeny, endte vi opp med tre hovedmenyen åpner ingredienser ved å trykke på hovedknapper; “Kamera”, “Rester” mobiltelefonens omrisset av en stjerne (en og “Måltider”. Deretter kom tanken kamera, slik at representasjon for å vise at stjernen om å lage en passende logo. Vi gikk brukeren skal kunne ta bilde av ikke var valgt) eller fjerne etter et simpelt logo design i starten. matoppskriften som ble tilberedt. favorisering ved trykk av en gul Etter at bildet ble tatt, ledet det stjerne. Bruken av stjerne var heller Hamburgermenyen var videre til å kunne legge til navn på ikke tilfeldig valgt. Vi mente dette en klar beslutning blant bildet, samt lagre eller forkaste også er en form for perceived affor gruppemedlemmene. bildet. Det er ansett som god dance, altså en kjent assosiasjon for Denne assosierte mange brukervennlighet og gi brukeren brukeren, siden flertall av apper i testpersoner som en menyknapp mulighet til å angre (referanse 2, s. dag bruker den som en indikasjon på eller en meny for innstillinger. 105-140). å favorisere elementer. Hamburgermenyikonet er gjenkjennelig for brukere fra sider I restebehandlingsmenyen ses som Facebook, Google o.l.. Derfor “kjøleskapet”, som skal tilsvare en har hamburgermenyen den en viss liste av de restene brukeren har perceived affordance, altså en tilgjengelig. Det var mulighet for å forståelse for symbolet som er swipe elementene mot venstre for fremdyrket gjennom kultur. å slette dem (se figur 1), og dette markerte vi med røde piler for å gi bedre affordance. Videre ga vi Figur 1. Restebehandlingsmenyen. 12 Matoppskriftene ble satt opp som en enkel rutemeny, der generelt. Målet med denne delen var at brukeren skulle få brukeren kunne bla seg igjennom oppskriftene. Det var et enkelt, og visuelt fordøyelig inntrykk av matvanene sine også skissert piler på begge sider av rutemenyen for å over tid (se figur 2). indikere at det var mulig å bla (se figur 3). Dette ble gjort fordi interaksjon på papir kan være lite intuitivt, og det er vanskelig for brukeren å se muligheten for å bla. Figur 2. Matvaner over tid I forlengelse av den visuelle fremstillingen la vi til muligheten til å trykke på alle bilder, for å bringe en forstørret versjon, hvorifra meta-informasjon som Figur 3. Rutemeny. oppskrift, samt muligheten til å slette kunne aksesseres. Bildene og det visuelle inntrykket var høyt prioritert, og Her ville vi gi brukeren bevegelsesfrihet, ved å gi adgang var et viktig element i designfilosofien. Derfor var det til all informasjon om matretten ved å trykke på bilde av viktig å ha store, fremtredende bilder der det var mulig. I matretten. presentasjonen av tidslinjen var dette noe vi fokuserte på, og ville ikke vise for mange små bilder i applikasjonen 13 Generelt prøvde vi å holde konsistens i alle knapper, svipefunksjon, og intuitive ikoner gjennom hele appen så godt vi kunne. Konsistens nevnes som en av Don Normans designprinsipper. Noen steder var det mer vanskelig enn andre på grunn av plassbegrensing. Andre steder i applikasjonen var det ikke intuitivt nok. På grunn av dette hadde vi en del diskusjoner på flere av disse punktene. Deretter noterte vi oss disse løsningene slik at vi kunne brukerteste disse. Vårt Mål Ved videre arbeid med analysen av dataene som ble hentet fra inn feltstudiet, ble de problemstillingene vi ville løse mer tydelig for gruppen. Vi ville lage en effektiv og enkel applikasjon som ga studenten evnen til å forbedre matvaner, kaste mindre mat, og samtidig ha muligheten til å loggføre matvaner. 14 Axure Wireframe Resultatet av brukertesten fra papirprototypen resulterte i Ikonene som ble brukt i første versjonen, ble i andre en rekke endringer til den nye prototypen, som skulle versjonen endret til mer gjenkjennelige ikoner. Grunnen lages i programmet Axure. Første sted innbar å redesigne til dette er at på papirprototypen var det vanskelig å tegne papirprototypen som ble testet med de endringene som ikonene tydelig og detaljerte. Vi håpet på at endringen ville var nødvendig. Deretter var det å sette i gang med å lage gjøre at brukeren fikk tydeligere assosiasjoner til hva de Axureprototype ut ifra papirprototypen og resultatene. Vi forskjellige ikonene betydde. fortsatte med designfilosofien fra papirutgaven og prøvde å gjøre designet simpelt og rent. Visualisering derimot, ble gjennomført med betydelig bruk av whitespace for å gjøre menyene og knappene Brukbarhetstestene av det første designet tydeliggjorde at fremtredende, i tillegg ble det gjort forskjellige menyen i appen var for innviklet , og dessuten ble en del struktureringer av bilde og tekst ut ifra hvilken type funksjoner ikke brukt. Av den grunn, bestemte vi oss for å informasjon som skulle presenteres. For eksempel var det gjøre det mye enklere ved å fjerne unødvendige menyer og bruk av tidslinje for loggføring av mat som ble basert på en funksjoner. kalender. Rutemeny ble brukt for presentering av oppskrifter for å gjøre det oversiktelig. 15 Rest Best logoen ble det gjort en del endringer fra første versjon. Først var det en veldig enkel grønn- og brunfarget tekst “Rest Best” som var brukt. Videre gikk den over til en rød-grønn farget logo, men vi var ikke fornøyd med den heller, da dette ga assosiasjoner til tung julemat. Vi ville ha en friskere farge. Derfor gikk vi til slutt over til en veldig enkel, lys gulfarge som skulle prøve å etterligne konseptet vårt. Figur 4. "Mine måltider"-menyen Statusbar, fant vi ut at det kunne være nyttig å ha øverst på alle delene av applikasjone n, bortsett fra kamera, som er fullskjerm, og hovedmenyen. Funksjonen til statusbaren var å holde brukeren orientert “Mine måltider” - menyen var ikke intuitivt nok til å vise at om hvor i applikasjonen han/hun var. Menyknappen vi det var mulig å swipe seg gjennom tidslinjen. Det var brukte på papirprototypen viste seg å være overflødig. heller ikke noen indikasjon på noen start og stopp på Derfor erstattet vi den med en hjem-knapp og la den til på tidslinjen( se figur 4). For å gi brukeren en mer intuitiv statusbaren. Vi lagde denne knappen slik at den ville være følelse om det var mulighet for å swipe, laget vi prikker på ‘reddende’ knapp i tilfelle brukeren hadde forvillet seg hver ende av tidslinjen for å indikerer et start og eller hadde ønske om å komme raskt tilbake sluttpunkt. Prikken skal gi inntrykket av en constraint hovedmenyen. (referanse 2, s. 60-62), altså en måte og vise dette går an og dette går ikke an. 16 Brukertesting: Fra papirprototype til Axure wireframe Testing tok del i to hovedfaser med fem deler i hver fase. Figur 5. Testoppsett og gjennomføring var i hovedtrekk ens under både papirprototype og Axure wireframe, med noen mindre unntak som vil bli behandlet senere i kapitlet. 17 Prototyping: papir kontra software I de tidlige fasene av prosjektet, var funksjonalitet og Straks vi hadde sikret oss funksjonaliteten, og fått en god estetisk design i konstant endring. Da oppdaget vi at det idé for designet vi ville ha, samt hvordan programmet var mye enklere og jobbe med papirprototype. Det var skulle struktureres, byttet vi til Axure. både enkelt og raskt og prøve nye idéer og design, og vi Med Axure fikk vi lagd en visuell approksimasjon som kunne presentere idéer både enklere og raskere. Skulle vi lignet på det endelige produktet. Denne virket mer under testing oppdage en feil i programflyten, eller innse profesjonell og intuitiv enn papirprototypen. En svakhet en mangel, var det en kjapp sak å tegne opp en midlertidig ved papirversjonen var affordance. Det var til tider løsning. Denne løsningen kunne vi se nærmere på og vanskelig å se hvilke deler av programmet som kunne optimalisere i etterkant. En betydelig fordel med manipuleres. Straks prototypen ble digital, ble elementene papirprototyping tidlig i prosessen var at det var en mye som kunne manipuleres mer gjenkjennelige. Mange slet lavere terskel for kreativitet; det var enklere å formidle den med å swipefunksjonaliteten siden den ikke var interaktiv visjonen man hadde i tankene med papir og blyant enn på det nivået man kjenner igjen fra mobil. med software. 18 Testprosedyre Lokasjon og atmosfære Til testingen valgte vi rom på Gløshaugen som ikke var for små, og heller ikke for store. Dette for å skape en koselig stemning uten å være for påtrengende. Vi brukte tid før testing til å behageliggjøre situasjonen, og prøvde å skape en uformell atmosfære. Meningen med dette var å sørge for at testpersonen var mest mulig avslappet, for å få testpersonen til agere så naturlig som mulig med programmet. Testsituasjonen kan nemlig være intimiderende: det sitter tre IT eksperter, to med notatblokker som følger nøye med, samt Trollmannen situasjonen, og at den ikke skulle oppfattes som slik. All (The Wizard of Oz), som forblir taus, og skal helst unngå usikkerhet, ‘feil’, eller nøling var ikke en demonstrasjon av ansiktsmimikk. Denne atmosfæren kan påvirke testeren og testerens mangel på intelligens, men en markering av være skremmende. Dette gjelder både for IT eksperten svakheter i programmet. som kanskje er redd for å “dumme seg ut” foran likemenn, Selv med gode venner som testere slo det ikke alltid helt og for amatøren som kanskje føler seg truet av det ut, og ved mangel på jevn progresjon merket vi at testerne ‘dømmende’ ekspertrådet. kunne bli nervøse, nesten litt febrilske, og begynne å prøve Derfor ble det gjort en iherdig innsats i å sørge for at alle slags ulike funksjoner uten å gi kognitiv feedback på testeren var klar over at vi var klar over den pressende hvorfor valgene ble tatt. 19 Personas og scenarioer I akkurat dette tilfellet brukte vi ikke mye energi på personas, da vi (og nesten hele omgangskresen) er i målgruppen for programmet. Vi følte derfor lite behov til å lage noe utover det overfladiske. Vi mener at vi har en god forståelse for målgruppen vi selv er del av. Vi lagde to personas, baserte på to typiske studenter på NTNU. De to personas reflekterer to forskjellige bruksmønstre, som belyser hele applikasjonen. Figur 6. Eksempel på en personas 20 Scenarier var laget for å teste programmet i sin helhet, alle funksjonene, samt programflyten. Formuleringen på scenariene ble fikset på mellom brukertester, for å være så utvetydige som mulig uten å gi ‘hint’ til hvor i programmet testpersonen skulle bevege seg. Følgende er et eksempel på et scenario, og inkluderer den ‘pitch’ teksten vi antok at brukeren hadde lest før han eller hun lastet ned applikasjonen. Fargelagt i etterkant for å vise hvilken del av programmet som testes. Figur 7. Scenarie eksempel. 21 Testere Kommentar til inndeling av grupper: Dette var ikke Gruppe 2: IT-eksperter planlagt på forhånd, men et mønster vi identifiserte i Variert gruppe innen IT- etterkant. Vi fikk forskjellige reaksjoner ut av alle vi testet, studenter av forskjellige men fellestrekk kan observeres innad i gruppene. spesialiteter, fra kommunikasjonsteknologi til Gruppe 1: Designekspert kunstig intelligens, mange av Eksperttesting med studass Øystein Molnes. Studass var dem med ekspertkunnskaper i programdesign og mye skolert i prototype testing, visste hvordan å tenke høyt, var erfaring. De fleste av disse studenter er på familiær med designkonsepter, familiær med tekniske mastergradsnivå. Ingen av dem spesialisert innen design løsninger og smartphone funksjonalitet, og ga veldig god på samme måte som studass, men alle har god forståelse feedback på alle disse punktene. Studass snakket konstant for programmer og hvilke valg som kan ligge til grunne for om hvilke visuelle og intuitive inntrykk de forskjellige et design. delene av programmene gav, samt kom med god feedback om strukturen og flyten av programmet; overordnede Gruppe 3: IT-amatører kommentarer om programmet i sin helhet. Dekkende Testing med ufaglærte innen design/IT. Hovedsaklig feedback, til den grad at vi føler det fortjener bemerkning i lærerstudenter innen fagene norsk og historie. Disse rapporten. testpersonene bruker apps ofte, men har ikke samme faglærte forståelse for oppbygging og design. Derfor fikk vi belyst noen av de svakhetene som ekspertene hadde oversett, samt de problemene som den ufaglærte ville støte på ved bruk av applikasjonen. Eksperter er veldig erfarne 22 med forskjellige interaksjonsmetoder, og vil derfor kanskje Resultat og analyse ikke streve med deler av programmet som for oss er Vi noterte alle ting vi kunne observere under testen. I alle innlysende. De ufaglærte ga oss idéer om stort potensiale fire testrunder fikk vi feedback omkring de samme for et mer intuitivt forståelig design. Dette var ekstremt områdene, som diskuteres under. En fordel med en veldig verdifullt. simpel applikasjon er at det er mindre som kan gå galt eller forvirre - samtidig er en svakhet at det skal formidle Det viste seg ganske innlysende at alle brukere, også innad relativt mye informasjon gjennom relativt spartanske i subgruppene, brukte programmet forskjellig, og tenkte virkemidler. Vi hadde altså et bestemt sett med problemer seg gjennom scenariene-oppgavene på forskjellig vis. Hver med appen, som vi gjennom redesign og ny testing, enten ny vinkel presenterte oss med en ny svakhet eller fikk forbedret eller ikke forbedret. Det var ikke alltid at vår potensiell forbedring, og var til stor hjelp. idé for en løsning til et problem fungerte. 23 Brukergrupper reagerer forskjellig Noen funksjoner var mer intuitive for noen grupper enn for andre grupper. Visse deler av programmet ville noen ha på en bestemt måte, mens andre hadde motsatte forventninger. Et vedvarende eksempel på dette var tidslinjen, hvor vi hadde en jevn fordeling av fire forskjellige slags meninger om hvordan det skulle gjøres: 1. Eldste element først i tidslinjen, vises først. 2. Eldste element først i tidslinjen, men det siste element er det første som vises. 3. Nyeste element først i tidslinjen, med tidslinjen gående bakover i leseretning. 4. Nyeste element først i tidslinjen, med tidslinjen gående bakover mot leseretning. Konsistens var manglende I de første versjonene var det mer kaos en konsistens; Inkonsistens i design og bilder var også et problem. Det menynavn ble brukt litt om hverandre og på forskjellige var forskjellige måter å presentere lignende views på i steder, og dette førte til forvirring blant testerne. Videre programmet, hvilket førte til usikkerhet. Det ga ble vi gjort obs på hvordan labels på knapper kunne fornemmelsen av at brukeren ikke lenger var sikker på misforstås, og hvordan enkelte ord som var ment for å hvor i programmet han eller hun befant seg. For å løse guide brukeren plutselig kunne være misvisende. dette problemet, la vi til en statusbar øverst, som skulle Eksempel: “Legg til favorittrester” er en funksjon i fylle minimalt med plass, og presentere brukeren med en programmet. Dette kunne forstås som om at det valgte “escape!” mulighet. Dette tok form av en Home knapp, element skulle legges til favoritt-listen, eller at et element samt en lite ikon og tilhørende tekst som fortalte hvor i så allerede lå i favoritt-listen, skulle legges til restelisten. programmet man var. Dette ble også en måte og tilføre litt Dette skapte forvirring. farge inn i programmet, da statusbaren var knallgrønn i kontrast mot alt annet, som var svart og hvitt. 24 Kunnskap i verden I testfasen ble det tydelig hvor viktig det var å påminne brukeren om tidligere utførte handlinger. Et eksempel på dette var tilføyelse av rester til “kjøleskapet”. Vi burde ikke ha krevd at brukeren husket hvilken rester som allerede var tastet inn i appen, men legge dem synlig slik at han/hun kunne se dem når nye rester skulle tilføyes. Dette følger Normans prinsipp om Knowledge in the World (referanse 2, s. 54) Simplifisér En applikasjon som er lagd for trivielle, hverdagslige Figur 8. Observasjonsskjema situasjoner, må være så rask og simpel som mulig. Konseptet om en spartansk simplifisering ble også tatt til Brukeren er ikke interessert i å lese manualen, eller bruke det estetiske designet, da færre elementer på et gitt view er tid på å trene seg opp. Ting skal funke med en gang, og en måte og redusere tenketid og potensiell forvirring. være så utvetydige som mulig. Unødvendigheter ble fjernet, elementene ble plassert i Så mye som mulig erstattet vi tekst med ikoner. oversiktlig avstand fra hverandre, og mantraen var Eksempel: “Innstillinger” endret til tannhjulsikon. whitespace, whitespace, whitespace. 25 Analyse som en egen fase av iterasjonen ble gjort fortløpende. Ofte ble vi sittende og diskutere forslag og endringer etter en gjennomført brukertest, og notatene ble grunnlaget for diskusjonen. Vi kompilerte de viktigste behov for endring ved først å se på de mest gjennomgående problemene for alle testere. Deretter angrep vi problemene view for view i appen. Den feedbacken som kunne føre til forbedringer av appen ble ført opp i et eget notatark (se figur 10). Dette gikk vi deretter gjennom og rettet. Eksempelutsnitt: Figur 9. Improvisert observasjonsskjema. Figur 10. Analyse av feedback. 26 SUS skjema SUS (System Usability Scale) er en måte å få kvantitativ tilbakemelding på viktige elementer av et hvilket som helst system. Vi delte ut SUS skjema som avslutning på brukertestene, og gjorde dette på begge testiterasjonene. Dette gjorde vi så vi kunne sammenligne og se om vi hadde forbedret designet eller ikke, og samtidig få pekepinner på generelle problemområder. Eksemplet er fra den første brukertesten. Kommentar på SUS: Det er to elementer som kan ha hatt innflytelse på resultatene, og som bør nevnes. 1. Mange av de som testet programmet var venner eller medstudenter. Det var ingen ‘fremmede’ som testet programmet, utover studass Øystein Molnes. Dette kan ha lagt grunnlag for bias; kanskje de antok at bra poengsum på SUS ville gi oss bedre karakterer, eller kanskje de var nervøse for en negativ sosial reaksjon fra oss. 2. Vi var til stede under utfyllingen av SUS. Dette kan skape press, og påvirke resultatene av noe som burde ha vært anonymt. Skulle vi gjøre det igjen hadde vi tatt mere høyde for å tilrettelegge for så ærlig en tilbakemelding som mulig. Figur 11. SUS-skjema. 27 Figur 12. Resultater fra papirprototype. Til påminnelse: for spørsmål med oddetall tilsvarer høyere verdi positiv feedback, mens det omvendte gjelder for partall. Figur 13. Resultater fra Axure wireframe. 28 Oppsummering av analyse Konseptet fikk vi positiv tilbakemelding på, og tenkte ikke ble Rest Best gradvis forbedret og fikset til en renere, mye over å forbedre formålet med applikasjonen enklere og mer intuitiv applikasjon. underveis. Hovedutfordringen med applikasjonen var å formidle vår konseptuelle modell (referanse 2, s. 12). Designvirkemidler er verktøy som kan brukes til å formidle mye informasjon på en enkel måte. Forhåpentligvis har vi da klart å gi brukeren en bedre mental modell av applikasjonen (referanse 2, s. 38). Vi var engasjert i å gjøre applikasjonen så enkel og minimalistisk som mulig, og møtte derfor problemer med å si mye med lite. Samtidig var en logisk og intuitiv programflyt viktig for oss. De tre hovedelementene av programmet skulle være forståelige og oversiktlige; brukeren skulle ikke føle seg intimidert av valgmuligheter eller forsvinne bort i komplekse navigasjonsstier. Som resultat av testingen fikk vi øye på hvor problemet lå, samt hvor styrkene lå. Fra sin rotete start som papirprototype Eyetracking En liten digresjon om eyetrackingtesten, som skulle være test to av to med studass. Grunnet mange grupper på for kort tid, fikk vi bare et par minutter med eyetrackeren. Dette var til vår skuffelse, siden vi hadde sett frem til å bli bedre kjent med teknologien. Vi fikk dessverre heller ikke tilbakemeldingen fra studass som vi tidligere har satt pris på. Vi gikk dog ikke fra opplevelsen uten å lære noe, og testprosedyren kan kommenteres på; bruk av telefon til å ta lydopptak av tilbakemelding slik at vi kunne spille tilbakemeldingen over filmen av eyetrackingtesten. Opptak av brukertest er noe vi vil bruke i fremtiden; noe kan gå tapt i notater, spesielt når de blir lest dager i etterkant, og sanntidselementet skal ikke undervurderes. Helst både video og lydopptak. 29 Figur 14. Eyetracker in action. Wireframe testing. 30 Oppsummering Hva lærte vi? Gruppen i sin helhet var godt kjent med den teoretiske Etter hvert som de forskjellige iterasjonene gikk sin gang, prosessen om hvordan man skal designe et ble vi bedre skolert i de forskjellige metodene involvert i brukergrensesnitt. Alle medlemmer av gruppen har tatt prosessen, og deres styrker og svakheter. Vi har gått fra faget Menneske-Maskin Interaksjon fra før, og vi stod prosessen med flere verktøy i kassa. I tillegg tilegnet vi oss derfor ikke helt uten innsikt i - eller kunnskaper om - lærdom om hvordan å løse problemer som dukket opp design-feltet. Hvordan å utføre en designprosses i praksis underveis. derimot, hadde ingen av gruppemedlemmene gjort i lignende detalj før. Likevel var gruppen generelt veldig Videre viste brukertesting seg å være nyttig. Gruppen fikk ivrig og engasjert i å lage et design som andre skulle bruke. nye innsikter i designprosessen. Gjennom brukertesting kom det frem tydelige feil, eller vanskelige punkter i Vi lærte at det å gjøre et feltarbeid med innhenting av data applikasjonen som forstyrret flyten og opplevelsen. Det ble var en god lærdom å starte med. Dette gjorde at gruppen helt klart for oss at vi hadde et lukket syn som utviklere. fikk kunnskap om hvilke funksjoner som var og ikke var et Det å få et perspektiv fra en som ikke var involvert i behov for den generelle brukeren av applikasjonen. prosjektet viste seg å være nyttig. Prosessen tydeliggjorde hvilke områder vi burde fokusere på, som blant annet sparte oss tid. 31 Videreutvikling Gruppen mener at prototypen er verdt å videreutvikle til et prototypen på en mobiltelefon for å gi en mer naturlig produkt, og for å klare dette så har vi lagt opp følgende setting. arbeid; det må en iterasjon til med redesign for å få fikset på Etter denne iterasjonen så er designet godt gjennomført og resultatene av Axure prototypen. Deriblant er det å lage en brukertestet for konseptuelle feil. Det neste steget vil da bedre visualisering av Reste-menyen. Her er idéen å innebære å sette i gang med å finne utviklere eller utvikle formidle den konseptuelle modellen bedre ved å få listen applikasjonen selv. Om videreutviklingen skal utvikles av til å ligne et kjøleskap. Dette vil gjøre at brukeren gruppen selv, er det muligheter å utvikle dette videre på assosierer listen med det brukeren har i sitt kjøleskap. fritiden ved å fortsette å organisere møter og Neste punkt blir å gruppere og visualisere restene med møteagendaer slik det har blitt gjort til nå. Et alternativ er ikoner i stedet for tekst. For eksempel så kan brukeren oppsøke hjelp fra Professorer eller medstudenter som trykke på grupperingen grønnsaker, og deretter trykke på finner applikasjonen interessant til å videreutvikle. en gulrot. En annen mindre endring innebærer å ha Dessuten er det mulig å sende inn en søknad til NTNU sin mulighet til å favorisere rester allerede i søket. Under AppLab om å få hjelp til å videreutvikle applikasjonen. Axure testing vil vi laste opp Axure prototypen som HTML og JavaScript filer til nettet, og latt brukeren teste 32 Nytt prosjekt Om gruppen skulle startet på et nytt designprosjekt så følger, hvilke figurer og symboler som gir den riktige hadde vi vært mye bedre stilt med kunnskap på hvordan hentydninger, hvor øyet trekkes og hvorfor. Skulle vi altså den iterative prosessen fungerer, og hvordan vi skal ha startet prosjektet på nytt med den kunnskapen vi har organisere oss med designarbeid bedre. Prosessen av nå, kunne vi ha designet noe bedre, raskere. idémyldring - testing - analyse - redesign kjennes på kroppen, og vi har et produkt som reflekterer utviklingen. Forskjellen på de første iterasjonene av prosjektet og de Tverrfaglig Refleksjon siste er for oss merkbar. Faget ga enorm innsikt gjennom Som NTNU student arbeider du for å bli ekspert på ditt detaljnivået, og gjennom testing, forelesing og korrigering eget fagområde. Studiet stiller krav om å knekke fikk gruppen øye på hovedtrekk i design, samt en måte og kunnskapskoder og tilegne seg ny viten. I IT3402 møtte vi tenke på, som kan videreføres til alle typer programvare utfordringen med å dele den kunnskapen vi hadde med som skal interageres med. hverandre. Vi brukte både egen og de andres kompetanse Studiet av det presise har altså gitt innsikt i det abstrakte: til å løse oppgaver i fellesskap. Med andre ord, handlet en dypere forståelse for hvordan mennesker interagerer dette om en relasjonskompetanse, evnen til å samarbeide med software; hvilke behov de har, hvilke impulser de bra. 33 Arbeidslivet i dag etterspør nettopp disse ferdighetene. Dette var tydelig gjennom at gruppemedlemmer Samarbeid som er effektiv er en forutsetning for å lykkes reflekterte jevnlig over bidraget til gruppen, og så etter med komplekse oppgaver. Samarbeidskompetanse bidrar forbedringspotensiale. Gruppemedlemmene brukte til at den samlede kunnskapen i gruppen utnyttes fullt ut. konstruktiv kritikk som en god påvirkning til selvinnsikt og videreutvikling av prosjektet. Det er nødvendig at hver Det skal nevnes at gruppen vår var satt sammen av enkelt gruppemedlem får formidlet sin opplevelse av informatikere, noe som gjorde gruppen lite tverrfaglig. samarbeidssituasjoner, og at gruppa reflekterer sammen Likevel hadde hvert gruppemedlem gode kvaliteter innen over situasjonen (Referanse 1, s 5). Dessuten var dette med forskjellige områder. I tillegg viste hver person kvaliteter på å forstå gruppens helhetlige samspill. innenfor praktisk orientering, lederskap, organisering og teoretisk annleggelse. Enkelte grupper hadde Vi føler at Hjertø oppsummerer teamarbeid i samsvar med produktdesignere, og dermed hadde mer kunnskap om vår erfaring. “Teamarbeid handler om leveranse, trivsel og den visuelle delen. Dette er en kunnskap som vi gjerne læring Det blir et dårligere resultat (leveranse) hvis skulle ønske vi hadde mer mulighet til å lære og erfare av. samarbeidet og de interne relasjonene(trivsel) ikke Likevel bidro den enkelte i gruppen til et godt samarbeid. fungerer. Den enkeltes innsikt i hvordan egne handligsmønster og væremåter påvirker samarbeidet (læring).”(Referanse 3, s 2) 34 Verktøy Facebook Første møtet med gruppen startet med å diskutere hvilke kommunikasjonsmidler vi skal bruke. Valget falt på å lage en lukket gruppe på Facebook. Der ble det utdelt jevnlig informasjon om planlegging av møtetidspunkter, inspirasjonsdeling, problemer som dukket opp underveis, agendaer til møter og diskusjoner. Delegasjon av arbeid ble også gjort her om det ikke ble gjort på møtene. Google Drive Gruppen hadde et behov for en felles mappe der alle dokumenter og presentasjoner om vårt arbeid skulle ligge. Her var det en liten diskusjon om å bruke Google Drive eller Dropbox. Alle gruppemedlemmer hadde begge, men det var ulike fordeler med hver av dem. Valget falt på Google drive i og med man kunne lage presentasjoner og dokumenter der alle på gruppen kunne gjøre redigering i sanntid. Deriblant var prosjektrapportens førsteutkast skrevet her. 35 Trello Prosjektarbeid kan inneholde mange forskjellige oppgaver som kan være vanskelig å organisere og delegere til tider. For å gjøre prosjektoppgaven vår enklere brukte vi Trello. Dette er en digital ‘Scrumtavle’ der du fyller ut post-it lapper og plasserer dem ut ifra kategoriene ‘Skal gjøres’, ‘Gjøres’ eller ‘Ferdig’. Microsoft Word Dokumenter som ble laget i Google Drive hadde enkel funksjonalitet, men hadde ikke alle mulighetene som var ønsket for å generere en presentabel prosjektrapport. Dermed ble Microsoft Word brukt til å formatere hele rapporten til et hefteformat slik gruppen ønsket å fremvise arbeidet som ble gjort. 36 Kilder 1. Holen, Are., Eksperter i team- refleksjonsbok, NTNU, Trondheim, 2014 2. Norman, Donald A., Psychology of Everyday Things/Design of Everyday Things, Basic Book, NY, 1988 3. Brandshaug, Sigrid., Eksperter i team- Gjennomføring av landsby, NTNU, Trondheim, 2014 37
© Copyright 2024