Prosjektarbeid: Hjult
Hjult er en applikasjon laget i et skoleprosjekt i faget IN2000 hvor jeg og en gruppe medstudenter fikk i oppgave å bruke data fra Meteorologisk institutt til å lage en applikasjon i Android Studio. Gjennom prosjektet fikk jeg erfaring med flere sentrale verktøy og metoder for design, og innsikt i hvordan det er å jobbe med en større prosess i et tverrfaglig team. Prosjektet gikk over 12 uker våren 2022.
Sentrale metoder og verktøy
INNSIKT
Datainnsamling, evaluering, observasjon, intervju, brukertesting
KONSEPT
Analyser, kravhåndtering idégenerering og konseptutvikling
VERKTØY
Smidig, Trello, Figma, Android studio, Material, Universell utforming
Prosess
Prosjektet startet med å velge mellom fem caser, der vi landet på et sykkelcase. Selv om man i Norge for det meste unnslipper smog, er svevestøv fra vedfyring og biltrafikk et omfattende problem også her til lands. I prosjektet designet vi en sykkelapp som viser luftkvalitet for sykkelruter. Valg av målgruppe falt på personer som bor og jobber i Oslo, og som minimum halve året sykler til og fra jobb 3 eller flere dager i uken.
I prosjektarbeidet benyttet vi elementer fra smidige prosessverktøy, Kanban og Scrum, blant annet retrospektive møter, standups og sprinter. Å få arbeide iterativt og inkrementelt med prosessverktøy som Scrum og Kanban har tydeliggjort for meg hvordan en smidig prosess kan hjelpe med å kartlegge fremdrift og faglige utfordringer. Overordnede aktiviteter som ble gjennomført i hver iterasjon er vist i tidslinjen nedenfor.
Brukerundersøkelser
Innledningsvis ønsket vi å bli kjent med målgruppen vår og konkretisere problemområdet. Vi gjennomførte derfor intervjuer med brukere som sykler til og fra jobb for å få en dypere forståelse av underliggende krav og behov. Hver av oss rekrutterte en person hver i nær omgangskrets som passet målgruppa som ble rekurettert til pilotintervjuer. I tillegg til at gruppa rekrutterte to brukere fra målgruppen som også ble intervjuet i tillegg.
Vi lagde ved oppstart to personaer for å kartlegge kjennetegn og mønstre hos brukerne. Proto-personaene ble gjennomført som en teamøvelse der vi gjorde antakelser om brukerne med utgangspunkt i dataen vi hadde samlet inn.
Vi lagde også to scenarier som fremstilte hvordan personaene kan interagere med løsningen vår. Personas og scenarier ble brukt til å inspirere oss i arbeidet med funksjonaliten, skildre mulige problemstillinger og hjalp oss med å personliggjøre brukssituasjonen.
Analyse
I neste iterasjon analyserte vi brukerundersøkelsene ved å gruppere funnene i klynge for å kartlegge behov hos brukerne. Vi satte oss også inn i eksisterende reise-apper for å undersøke hva slags designmetaforer, oppgaveallokering og funksjonalitet som allerede finnes. På denne måten kunne vi oppdage og utforske alternativer for aktiviteter og navigasjon i vår egen designløsning.
Hovedfunn fra analysen
Kravhåndtering
Basert på dataene vi nå hadde for hånden, utarbeidet vi konkrete konsepter som appen skulle romme og spesifisere krav til applikasjonen. For å spare brukeren for gjentatt input, bestemte vi f.eks. at appen skulle la brukeren lagre faste reise-tidspunkt i løpet av uken.
.png)
Utforming av kravspesifikasjoner ble gjort sammen, på tavle og skjerm.
I hver iterasjon ble kravene vurdert, validert og endret i tråd med designvalg gjennom hele prosessen. Tabellene under viser kravspesifikasjonene slik de så ut avslutningsvis i prosjektet. De ikke-funksjonelle kravene tok utgangspunkt i vårt ønske om å lage en app som samsvarer med WCAG.
Funksjonelle krav
Ikke-funksjonelle krav
Lavoppløselige prototyper
Fokus i de lavoppløselige prototypene lå på hva brukerne våre skal kunne oppnå med produktet, og hvilke konsepter som er nødvendig for å forstå interaksjonen. Ved bruk og kast-prototyper laget på tavla visualiserte og diskuterte vi i fellesskap tallrike alternativer for konsepter og samspill.
Bruk og kast-prototyper
Høyoppløselige prototyper
Jeg og de andre designstudentene på gruppen som prototyper i Figma
Før jobbing med høyoppløselige prototyper hadde vi en gjennomgang av Google sin Material design-manual sammen på gruppa, hvor vi utforsket f.eks. hvilke virkemidler og symboler som kan tydeliggjøre funksjoner. Jeg og to andre på gruppen fikk så hovedansvar for å videreutviklet prototypen til interaktive wireframes i Figma.
Evaluering
For å få tilbakemelding på prototypen fra to ulike perspektiver inkluderte vi en bruker som var med i datainnsamlingen i 2. iterasjon, og en som var ukjent med løsningen i evalueringeen. Disse brukerne hjalp oss med å avdekke overflødige elementer og konflikter innad i funksjonaliteten. Evalueringene ble gjennomført ved observasjon i kontrollerte omgivelser med think aloud som teknikk, etterfulgt av et åpent intervju.
Skisser på tavla etter evaluering med bruker
Basert på tilbakemeldingene fra brukerne endte vi med to godt synlige bokser for henholdsvis reisen til og fra jobb så bruker enkelt kan se hva slags vær det er meldt på spesifikke pendlertidspunkt. Kartet med sykkelrute var uinteressant for brukerne ettersom de allerede kjenner veien til jobb. Derfor ble luftkvalitet-informasjonen flyttet over til kart-siden i appen. Dette styrket kartets verdi og snevret appen mer inn på svevestøv. I arbeidet med MVP viste det seg at lokale variasjoner i svevestøvforekomster gjorde generelle varsler lite effektive. Vi inkluderte isteden et heatmap for å gi oversikt over lokale forhold slik at brukeren kan avgjøre hvorvidt man ønsker å sykle en omvei for å unngå svevestøv.
Nye wireframes basert på evaluering med bruker
De viktigste funksjonene ble implementert i Android Studio først, mens vi i Figma gjorde vi forbedringer i samspillet mellom de ulike delene av applikasjonen virket. Siste runde med wireframes i Figma ble slik:
Ferdigstilling av applikasjon
Ved ferdigstilling jobbet vi med visualisering av værdata, og oppdaterte flyt og utseende i applikasjonen til å bedre samsvare med prototypen. Luftkvalitet i kartet og en onboarding-sekvens ble også implementert, samtidig med at vi arbeidet med å gjøre grensesnittet kompatibelt med WCAG, så langt vi rakk. Fargekontrastene mellom tekst og bakgrunn minst 4,5:1, alle bilder kan leses av en skjermleser og navigasjonslenker har konsekvent rekkefølge og utforming.
Fargevalg medutgangspunkt i WCAG-kravene, for å sikre kontrast og lesbarhet.
Mot slutten gjennomførte vi en summativ evaluering av Hjult med en ny bruker i målgruppen, også denne gangen ved bruk think aloud og observasjon, samt et ustrukturert intervju i etterkant av interaksjonen. Selv om ingen grove feil ble oppdaget, rakk vi kun å gjennomføre evalueringen med én bruker, noe som svekket validiteten og reliabliteten ved evalueringen.
Bildet nedenfor viser skjermbilder av "Hjult"-appen vår, som kjøres på Android.
Refleksjon
Det at vi la en betraktelig mengde arbeid i å utforme høyoppløselige, interaktive prototyper gjorde at vi hadde en god forståelse av hva som skulle implementeres. Men å komme sent i gang med implementasjon kan også medføre betydelige kostnader, for eksempel hvis tekniske begrensninger hindrer ideer som var enkelt å sette opp i design-prototypene. Vi var derfor klar over at det kunne dukke opp utfordringer som ville påvirke tiden vi hadde til rådighet og applikasjonen i seg selv, ettersom vi brukte en del tid på prototyping først. I prosjektet lærte jeg at dette er en balansegang. Å validere hypoteser tidlig, og ikke hoppe rett på implementasjon, kan også føre til positive effekter ved at man kan iterere på ideer uten å bruke mye tid på implementasjon. I vårt tilfelle førte rapportskriving og små utfordringer med den tekniske implementasjonen til at vi på slutten måtte prioritere noen av kravene over andre.