Prosjektarbeid: Hjult
Hjult er en app laget i et skoleprosjekt hvor jeg og en gruppe medstudenter fikk i oppgave å bruke data fra Meteorologisk institutt til å lage en app 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 på et tverrfaglig team. Prosjektet gikk over 12 uker våren 2022.
Sentrale erfaringer
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
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.
Vi benyttet flere elementer fra smidige prosessverktøy, 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 løse faglige utfordringer. Overordnede aktiviteter i hver iterasjon er vist i tidslinjen nedenfor.
Brukerundersøkelser
For å bli kjent med målgruppen og konkretisere problemområdet gjennomførte vi intervjuer med brukere som sykler til og fra jobb. Hver av oss rekrutterte en person hver i nær omgangskrets som passet målgruppa som vi intervjuet, i tillegg til at gruppa rekrutterte ytterligere to brukere fra målgruppen som ble intervjuet i tillegg.
Ved oppstart lagde vi to personaer for å kartlegge kjennetegn og mønstre hos brukerne. Disse 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. Begge deler ble brukt til å inspirere oss i videre arbeid med funksjonaliten, for å skildre mulige problemstillinger og personliggjøre brukssituasjonen.
Analyse
I neste iterasjon analyserte vi brukerundersøkelsene ved å gruppere funnene i klynger, og kartlegge mulige produktspesifikasjoner og brukerbehov. Vi satte oss også inn i eksisterende reiseapper for å undersøke hva slags designmetaforer, oppgaveallokering og funksjonalitet som allerede finnes.
Hovedfunn fra analysen
Kravhåndtering
Basert på dataene vi nå hadde for hånden, utarbeidet vi konkrete konsepter som appen skulle romme og spesifiserte krav til appen.
.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. De ikke-funksjonelle kravene tok utgangspunkt i vårt ønske om å lage en app som samsvarer med Web Content Accessibility Guidelines (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 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 arbeidet med høyoppløselige prototyper hadde vi en gjennomgang av Googles Material design-manual sammen på gruppa, hvor vi utforsket f.eks. hvilke virkemidler og symboler som kan tydeliggjøre funksjoner. Skissene ble så videreutviklet til interaktive wireframes i Figma.
Evaluering
I evalueringen inkluderte vi én bruker som var med i datainnsamlingen i andre iterasjon, og én som var ukjent med løsningen. 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. 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.
Skisser på tavla etter evaluering med bruker
Kartet med sykkelrute opplevdes uvesentlig for brukerne ettersom de allerede kjenner veien til jobb. Derfor ble luftkvalitet-informasjonen flyttet over til kartfanen i appen. Dette styrket kartets verdi og snevret appen inn på svevestøv. Lokale variasjoner i svevestøvforekomster gjorde generelle varsler lite effektive, så vi inkluderte heller 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 fobedret samspillet mellom de ulike delene av appen i Figma. Siste runde med wireframes ble slik:
Ferdigstilling av applikasjon
Mot slutten oppdaterte vi flyt og utseende i appen og la inn luftkvalitet i kartet, samt onboardingsekvens. Vi arbeidet også med å gjøre grensesnittet kompatibelt med WCAG.
Fargevalg medutgangspunkt i WCAG-kravene, for å sikre kontrast og lesbarhet.
Sluttveis gjennomførte vi og en summativ evaluering av Hjult med en ny bruker i målgruppen, ved bruk think aloud og observasjon, etterfulgt av et ustrukturert intervju. 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 betraktelig 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 appen 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.