Dette er en prosjektrapport i emnet IDG3750 Tangible and Sensorial Interaction Design, som inngår i 2.året på Bachelor i Interaksjonsdesign. Prosjektet er skrevet av Ann Margit Krog og Lisa Sofie Edelman Sæther og prosjektet vi har valgt å jobbe med gjennom det kommende semesteret er å lage en booking-oversikt for Book-it-lab. Ved hjelp av designmetodikk, brukerne, oppdragsgiver og faglærer i faget har vi som mål å lage en intuitiv og enkel løsning for brukerne på IVB-laben som skal ta nytte av denne oversikten.

Uke 2 - Oppstart

Uke 3 - Avklaring med oppdragsgiver, innsikt i prosjektet

Uke 4 - Prosjektplan og koordingering med annen gruppe

Uke 5 - Innsiktsarbeid med observasjon

Uke 6 - Digitale intervjuer

Uke 7 - Isolasjon og karantene livet

Uke 8 - Teknisk aspekt, skisser og intervjuer

Uke 9 - Siste lo-fi brukertest, idésortering og personas

Uke 10 - Veiledning med annen faglærer

Uke 11 - Første utkast av hi-fi prototype

Uke 12 - Brukertest og tanker rundt moral, etikk og lovverk

Uke 13 - Påskeferie

Uke 14 - Endring av prototype basert på brukertest

Uke 15 - Brukertest #2, hi-fi prototype

Uke 16 - Endringer etter brukertest nr. 2

Uke 17 - Oppsummering og link til prototype

Kilder

Uke 2 | Oppstart

---

Denne uken er første uken med forelesning etter juleferie. Under forelesningen fikk vi en intro til hva resten av semesteret skulle bygge på og vi ble introdusert for de forskjellige prosjektene vi kunne velge mellom. Etter forelesningen satte vi (Ann Margit og Lisa) oss sammen for å bli enige om hvilket prosjekt vi skulle velge. Vi hadde lyst til å være tidlig ute så vi var sikre på at vi fikk det prosjektet vi syntes virket mest interessant. Valget falt på Book-it-lab som er et samarbeid med IVB fakultetet. Etter vi hadde blitt enige sendte vi en mail til faglærer om prosjekt-ønske og ønske om tid for første veiledning.

Selv om vi begge hadde faget fysisk prototyping forrige semester, var det ingen av oss som rakk laserkutting kurset. Dette fikk vi dermed ta denne uken og vi besto begge to på første forsøk. Kurset er obligatorisk for dette faget.

Slutten av uken

Neste uke er planen å gjennomføre første veiledning, samt få til et, hvis mulig, fysiskt møte med oppdragsgiver. Vi kommer tilbake til dette, men så fort vi har gjennomført veiledningen vil vi kontakte oppdragsgiver for nærmere informasjon om oppgaven.

Uke 3 | Avklaring med oppdragsgiver, innsikt i prosjektet

---

Forrige uke var oppstart av prosjektet vi skal jobbe med dette semesteret. Vi valgte prosjektet som omhandlet å lage en booking oversikt for IVB sin lab og hadde første veiledning med faglærer. Denne uken er planen å få kontaktet oppdragsgiver og avtale møte med han. Videre får vi se hvordan uken utvikler seg når vi får litt mer informasjon om prosjektet.

Tanker før møtet med oppdragsgiver

Etter å ha valgt prosjektet BookitLab, arrangerte vi et forberedende møte med faglærer for å organisere prosjektet og få videre innsikt og innspill om valgt prosjekt. Etter dette møtet kontaktet vi oppdragsgiver for å få en bredere forståelse og brief angående oppgaven. Det som fremsto av prosjektbeskrivelsen var beskrivende for essensen av oppgaven, men vi hadde behov for videre avklaring og detaljorientering med oppdragsgiver. I forkant av møtet hadde vi særlig fokus på å avklare hvordan dagens løsning er, hvor stort handlingsrom det er i en slik løsning og hvordan software som kunne vært aktuell å benytte seg av. Et annet sentralt fokus vi hadde var hvem som hovedsakelig var brukere og målgruppe av løsningen, ettersom dette vil ha mye å si for videre faser av prosjektet.

Møte med oppdragsgiver

Vi valgte å ha et fysisk møte fordi vi følte vi kunne få større utbytte av dette, slik at det ble lettere å stille spørsmål og å få se en visning av dagens løsning og system. Vi ønsket også å skape en mer personlig kontakt med oppdragsgiver, for å enklere skape en felles forståelse av mål og ønsker.

Møtet startet med at vi fikk en kort innføring i hvordan Bookitlab fungerer på pc’en, dersom man ønsker å booke rom eller utstyr via Feide-brukeren sin. Deretter fikk vi innføring i hvordan oppdragsgiver ønsker et bedre system. I all hovedsak ønsket oppdragsgiver en mer detaljert oversikt over hva som foregår på de ulike labbene og oversikt som viser de kommende aktivitetene. I tillegg ønsket han at man kan se hvem som har booket og eventuelt hvem som er der. Dette reiser igjen spørsmål om personvern, som det er viktig å forholde seg til. Dagens løsning var laget med Raspberry Pi, men denne var ikke sterk nok til å kunne håndtere hele systemet.

Vi stilte flere spørsmål om hvordan han kunne se for seg handlingsrommet i løsningen, men her fikk vi et stort spillerom og han var veldig åpen for at det var noe vi kunne vurdere selv. Dette gjaldt også på de andre spørsmålene vi stilte for å spesifisere hvordan en løsning kunne se ut. Vi fikk dermed veldig stort handlingsrom angående løsningen, og spørsmål som vi så for oss å få svar på ble noe vi måtte vurdere selv. Dette gjaldt også valg av teknologi og software. Vi følte at det var litt utenfor vårt fagfelt å vurdere tekniske aspekter ved en slik løsning, men likevel ser vi på den som en spennende utfordring. I tillegg får vi lært at man ikke kan lage “hva som helst” på papiret, men vi må faktisk undersøke at det lar seg gjøre i virkeligheten. Dette tror vi er god lærdom å ha med seg videre. En annen side ved at vi må undersøke dette selv, er at det tar lengre tid og at vi må ta høyde for å gjøre den innsikten i arbeidet vårt. Dette kan på en måte påvirke sluttresultatet, men igjen så er det lite poeng å lage en løsning som ikke kan settes ut i realiteten, sett kostnader og lignende på skolens vegne.

Refleksjoner og ideer etter møtet

Etter møtet satte vi oss ned for å oppsummere rundt møtet og undersøke videre med software. Vi gjorde et Google-søk ettersom det var den første og enkleste måten vi kom på der og da. Under møtet fikk vi begge en idé om en touchskjerm, så derfor utforsket vi mulighetene til en software knyttet til dette. Vi fant en software kalt “Intuiface” som ga inntrykk av at det var akkurat det vi hadde hatt behov for til en slik løsning. Men prisen på denne tjenesten var høy, slik at det var noe vi la litt til side, før vi hadde drøftet det med faglærer.

Vi kom opp med flere ideer, der vi tenkte rundt det å ha en skjerm med en enkel oversikt over aktiviteter der man kan scanne en QR-kode for å interagere videre med systemet på egen mobil. Dette ville forenklet utfordringene med en egen software og kostnader knyttet til både software og teknisk utstyr. Men igjen ville en slik løsning muligens øke terskelen for å benytte seg av mobilen for å interagere med systemet. Vi snakket også rundt enklere løsninger som ligner nåværende løsning, men å endre plassering, design og eventuelt størrelse på skjermen for å gjøre den mer attraktiv og synlig.

Vi idémyldret også hvordan type innhold løsningen vår kan ha. Løsningen må ha en kalenderoversikt med bookinger, men vi snakket litt rundt å ha korte informative videosnutter med innhold som er relevant for studentene på labben. Vi tenkte også å beholde kartet med oversikt over labben, slik at det er lettere for studenter og andre personer å finne frem. Selv om vi nå har noen ideer, er det viktig at vi får samlet mer innsikt i brukerne før vi spisser oss nærmere inn på konkrete ideer og utvikler disse videre.

Figur 1: Dagens løsning med bookingsystem og kartoversikt over labene

Slutten av uken

Denne uken har vi fått mer innsikt i prosjektet via møte med både faglærer og oppdragsgiver, men også samtidig fått et veldig stort spillerom. Vi har satt igang prosessen kort med noen umiddelbare ideer, men for å ta disse videre trenger vi å samle inn brukerinnsikt. Neste uke vil vi bruke tiden på å utarbeide en prosjektplan for gjennomføring av prosjektet.

Uke 4 | Prosjektplan og koordinering med annen gruppe

---

Forrige uke hadde vi første veiledning med faglærer, for så å møte oppdragsgiver. Under møte med oppdragsgiver fikk vi litt mer innsikt i hva han håpet å få ut av prosjektet vi skulle jobbe med. Denne uken har vi avtalt ny veiledning med faglærer for å snakke litt om hvordan møte med oppdragsgiver gikk. I tillegg må vi denne uken få skrevet en prosjektplan og levere denne for godkjenning.

Veiledning med faglærer

Under veiledningen med faglærer ble vi informert om at det var en annen gruppe som også hadde valgt samme prosjekt som oss. Dermed kunne vi velge om vi ville slå oss sammen med den andre gruppen, om vi ville samkjøre noen av delene i prosjektet med dem, eller om vi ønsket å fortsette prosjektet helt på egenhånd. Vi snakket også litt om hvordan vi skulle angripe det tekniske i oppgaven, siden dette er et lite stressmoment for oss. Vi ble enige om at vi måtte gjøre mer research og snakke med NTNU for å finne ut om det allerede var eksisterende programvarer på skolen vi kunne ta i bruk for å slippe ekstra kostnader. Dersom vi skulle komme til den forståelsen at det tekniske ble en for stor oppgave for oss å gripe over alene, så var det også en mulighet å jobbe videre med dette prosjektet i Web of Things neste semester. Dette vil si at vi må hvertfall få gjennomført brukertestingen og det meste av design aspektet dette semesteret, pluss å lage en prototype som vi da eventuelt kan jobbe videre med senere.

Det kuleste hadde jo selvfølgelig vært å fullføre hele prosjektet på egenhånd og avlsutte med et endelig produkt vi faktisk kunne implementert, men vi har blitt enige om at det er bedre å gjøre en del bra og heller jobbe videre på et senere tidspunkt.

En av de viktigste grunnene for å finne ut hvilken programvare vi skal bruke er for å kunne sette prosjektets avgrensninger. Selv om man kanskje skulle ønske at “the sky is the limit” så er den dessverre ikke alltid det. Avgrensningene for prosjektet står det mer om i prosjektplanen vi jobber med.

Etter veiledningen ble vi enige om å ikke slå oss sammen med den andre gruppen, men et møte med dem for å dele kunnskap så langt kunne ikke skade. Vi avtalte et møte med dem på fredag denne uken.

Prosjektplanen

HVORFOR TRENGER MAN EGENTLIG EN PROSJEKTPLAN OG HVA SKAL VÆRE MED?

Planlegging av et prosjekt gjør ofte forskjellen på om prosjektet blir vellykket eller ikke. Ved å sette opp en prosjektplan ved oppstart av prosjektet hjelper det prosjektteamet å få en bedre forståelse av hva som skal gjøres og hvordan prosjektet skal gjennomføres. I tillegg får man satt visse avgrensninger på for eksempel hvor mye tid som skal brukes på hver del, ca. utgifter og ressurser som skal brukes, og omfanget av hele prosjektet. Dette hjelper både teamet og team lead med å ha en viss forståelse underveis for hvordan man ligger an. I prosjektplanen kan man også legge ved mulige risikoer og farer slik at man kan ta hensyn til disse underveis i prosjektet. ^[1]

Forrige vårsemster hadde vi et fag som het Prosjektstyring i design IDG1007. Boken i dette faget “Prosjektveilederen” bruker vi hyppig som et hjelpemiddel mens vi skriver prosjektplanen.

Prosjektplanen vi har utarbeidet inneholder:

1. Aktiviteter, ansvar og roller i gruppen
2. Planlegging og/eller utvikling rammer
3. Beslutningpunkter, faser og møteplan
4. Risikovurdering, dokumentasjon av arbeid
5. Grupperegler og konflikthåndtering

FASER OG BESLUTNINGSPUNKTENE FOR PROSJEKTET

Figur 2: Fasene og beslutningspunktene (BP) for prosjektet

PROSJEKT OUTLINE

1. Bakgrunn ^[2]

Prosjektoppgaven går ut på å lage et sanntidssystem som viser kommende og påbegynte aktiviteter på IVB labbene. Systemet skal være koblet opp til Bookitlab som brukes for å booke tid på de forskjellige verkstedene/labbene. Dermed kan studenter, ansatte og besøkende lett se hva som er ledig/i bruk.

2. Problembeskrivelse ^[2:1]

Bookitlab har i dag en kalender beregnet for visning på vanlig dataskjermer. Selv om kalenderen er grei, vil vi skape et mer grafisk grensesnitt for brukeren. Dette kan bety en plantegning av labben som viser nåværende og kommende aktivitet eller et fargekoding-system som viser hvilke rom som er tilgjengelig. Det vil først og fremst brukes av studenter og ansatte på IVB, men også tidvis eksterne kunder som er på besøk.

3. Målbeskrivelse (resultatmål og effektmål) ^[2:2]

Resultatmål:
En enkel og oversiktlig løsning som studenter, ansatte og kunder/besøkende kan bruke for å få en oversikt over aktivitet i labben. På denne måten vil brukerne enklere kunne organisere sin hverdag rundt aktiviteter som skal utføres i labben. Løsningen skal også være laget med fokus på universell utforming for at alle skal kunne bruke den. Løsningen skal tilstrebes å være en lavkostnads-løsning.

Effektmålene:
Oppnå flere bookinger som viser at kalenderen blir tatt i bruk av ansatte/studenter, som igjen gir et bilde på om løsningen er oversiktlig og brukervennlig for brukerne.

4. Spørsmål som skal besvares når prosjektet er ferdig ^[2:3]

Har vi laget en enkel og intuitiv løsning for sluttbrukeren?
Er oppdragsgiver tilfreds med løsningen?
Hva ville vi gjort annerledes om vi hadde gjort det en gang til?
Hvilket læringsutbytte har vi fått?
Hvordan skal løsningen implementeres i senere tid og hvem skal involveres?
Hva blir neste steg?

5. Virkemidler og metoder ^[2:4]

Presentasjon Software (ikke avklart enda)
Research catalogue for dokumentasjon
Design thinking som metode for å lage en brukervennlig løsning

Koordinering med gruppe med samme prosjekt

Siden det var en gruppe som hadde valgt samme prosjekt som oss, bestemte vi oss for å ha et møte hvor vi kunne dele erfaringer så langt og forståelsen av oppgaven. Møtet var også satt opp for å diskutere hva hver av gruppene hadde bestemt seg for å fordype seg i, så oppgavene ikke blir helt like. Vi kom frem til at begge gruppene var litt usikre på det tekniske aspektet og at vi dermed kunne samarbeide litt med denne delen. Vi ble enige om å gjøre litt research hver for oss, men samle oss igjen senere for å dele. Fire hoder tenker tross alt bedre enn to. I bunn og grunn fant vi ut at selv om løsningene våre bygger på samme tekniske aspekter, vil fortsatt designet mest sannsynlig ha en del fellestrekk.

Slutten av uken

Denne uken har vi ferdigstilt en prosjektplan, hatt møte med gruppen med samme oppgave som oss og møtt faglærer for veiledning nummer to. Vi føler vi har en litt bedre forståelse for prosjektet på dette punktet, men synes fortsatt den tekniske delen er litt utfordrende. Neste uke vil vi derfor undersøke om NTNU har noen programvarer som allerede er i bruk som vi kan bruke til prosjektet vårt. Dersom dette ikke er tilfellet vil prøve å finne løsninger på nett. Uke 4 var siste uken i forberedelsesfasen, dermed vil vi gå inn i innsiktsfasen neste uke.

Uke 5 | Innsiktsarbeid med observasjon

---

Forrige uke avsluttet vi forberedelsesfasen med å lage en prosjektplan for resten av semesteret. Denne uken begynner innsiktsfasen som er en viktig del av prosjektet vårt. Denne fasen går ut på å samle inn den dataen vi trenger for å lage et best mulig resultat for sluttbrukeren. Ettersom vi ikke hadde noe innsikt i hvordan brukerne bruker booking-oversikten eller om de i det hele tatt bruker den, tenkte vi det var lurt å gjennomføre en observasjon i labben. På den måten kan vi finne ut hvor mye den blir brukt/ sett på i den konteksten brukeren befinner seg i. ^[3] Dette kalles også for en feltobservasjon/skyggeobservasjon innenfor tjenestedesign. ^[4]

I forkant av observasjonen

Vi valgte å ikke planlegge så mye i forkant av observasjonen, ettersom vi så for oss at det ble vanskelig mtp at det er færre studenter på skolen. Vi tenkte det var best å møte opp på labben kl 10, da vi så for oss at det var flest studenter der. Da vi kom dit var det litt vanskelig å vite hvor vi skulle plassere oss, ettersom det ikke var så mange naturlige steder å sitte, mtp at vi måtte se både personene som kom inn døren og skjermen med booking-oversikt. Vi endte opp med å sette oss på en pult som stod plassert med innsyn mot døren.

Vi hadde avtalt med oppdragsgiver at vi skulle gjennomføre en observasjon i labben, og han møtte oss før vi startet observasjonen for å sjekke at alt det tekniske var som det skulle, ettersom skjermen ikke alltid fungerer og viser et default-bilde istedenfor bookings-oversikten. Det viste seg da at nå er det kun kalenderen direkte fra BookitLab som vises fra nettsiden, og ikke den løsningen vi ble presentert for under første møte med oppdragsgiver. Nedenfor ser man hvordan denne ser ut.

Figur 3: Kalender direkte fra BookitLab fra nettleser.

Figur 4: Nærbilde av kalenderen fra BookitLab.

Vi snakket litt mer med oppdragsgiver om hvordan type teknisk løsning som var mulig å bruke. Vi spurte om det var mulig å kode opp en nettside, ettersom direkte-kalenderen fra BookitLab nå var som en nettside. Dette var fullt mulig, noe som gjorde at vi så litt mer “lys i tunnelen” angående det tekniske. En av oss fikk også ideen om å bruke en Powerpoint som mulig løsning, dette var også oppdragsgiver positiv til. Men her blir det igjen spørsmål om hvordan man skal få koblet opp bookinger fra BookitLab opp mot Powerpointen.

Endring av plasseringen til skjermen

Da vi kom til labben stod skjermen plassert i et lite hjørne, litt langt i fra inngangsdøren. Vi tenker at plasseringen av skjermen har mye å si for om det blir lagt merke til eller ikke. Derfor bestemte vi oss for å endre plasseringen slik at det var lettere å se den. Vi satte den bak et bord med antibac og QR-kode for registrering av oppmøte (se bilde nedenfor). Vi plasserte både bordet og skjermen vinklet mot inngangsdøren og litt nærmere døren. De stod ikke i gangbanen slik at de var i veien, men mer slik at det skulle være innenfor synsfeltet når man kom inn døren. Vi så for oss at de fleste studenter vil registrere seg for å bidra til lettere smittesporing. Siden skjermen var plassert bak, så vi for oss at de fleste ville legge merke til den.

Figur 5: Endring av plasseringen til skjermen.

Resultater fra observasjonen

Som man ser ovenfor av resultatene, var det ikke mange som så på skjermen i det hele tatt. 25% av alle personene som kom inn døren på labben så på skjermen, og det var kun i noen sekunder. Disse resultatene overrasket oss, da vi hadde sett for oss at flere så på den. Det kan være flere grunner til at det var så få som så på skjermen. For det første var vi veldig synlige med en gang personene kom inn døren. Det kan ha gjort at vi tok mye av oppmerksomheten og at personene gikk videre uten å se seg mer rundt. Det ser man av tabellen også at det var mange som så oss, men ikke på skjermen etterpå. Vi satt ca 1 meter fra skjermen, så det skulle ikke vært så problematisk å se den, men likevel tror vi at vi var en feilkilde i observasjonen. Vi ble også overrasket over at ikke flere benyttet seg av antibac og oppmøteregistrering, noe som vi trodde skulle øke sannsynligheten for at de så på skjermen. Her kan vi igjen ha vært et forstyrrende element, og det er mulig at studentene i stedenfor lurte på hvorfor vi satt der og hva vi gjorde. En annen grunn kan være at studentene som var der den dagen kan ha vært så vandt til at skjermen er der, slik at de ikke lengre vier oppmerksomheten til den. Det kan også være at det nåværende designet av oversikten ikke tiltrekker seg nok oppmerksomhet, elementene er veldig små og at det ikke brukes farger. På den måten er det vanskeligere å legge merke til oversikten, siden den ikke skiller seg ut fra omgivelsene i stor grad.

Endring av skjerminnhold

Vi gjorde oss noen tanker om hva som kunne skape mer oppmerksomhet rundt skjermen og foretok et lite eksperiment med å endre innholdet på skjermen og i tillegg bruke lyd. Vi satte på en video på Youtube med en rykende kaffekopp med jazzmusikk i bakgrunnen. Vi tenkte her at lyd og bevegelse kanskje kunne trigge oppmerksomheten bedre. Dette forsøket går litt utenfor en løsning med en bookings-oversikt, men kan gi verdifull informasjon om hvordan vi kan fange oppmerksomheten til brukerne på en litt annerledes måte.

Resultat fra observasjonen med endring av skjerminnhold

Som man ser av skjemaet, så alle personene som kom inn døren på skjermen og de så også lengre på den. Det at de fleste også smilte og så nysgjerrige ut var et ganske interessant funn. Om løsningen vår i tillegg til å være informativ kan gi positive assosiasjoner/følelser, ser vi på dette som et pluss. Spørsmålet er videre hvordan tilleggsinformasjon vi kan ha som er relevant for brukerne og som de kan ha nytte av. Et annet interessant aspekt med dette forsøket var at flere tok antibac. Vi tenker at noe av grunnen til dette er at de ville ha mer tid til å undersøke hva som var på skjermen, og derfor tok antibac for å se nærmere på hva som skjedde. Om vi kommer frem til en løsning som også kan få flere til å benytte seg av antibac og oppmøteregistrering ser vi på dette som meget positivt. Men her kommer en avgrensning igjen inn i bildet, og dette kan tas med som et positivt aspekt ved løsningen men ikke som hovedmål.

Vi fikk ikke tid til å observere like mange med det nye skjerminnholdet, men likevel vil vi si at resultatene er representative ettersom alle de 9 personene så nysgjerrig på skjermen. Vi følte at vi fikk mye verdifull innsikt med observasjon som metode, og det ga oss også nye ideer og aspekter å ta i betraktning når det kommer til bookingløsningen. I tillegg får man sett hva brukerne faktisk gjør i sitt miljø og reflektere rundt hva som kan påvirke for eksempel oppmerksomheten. ^[3:1] På den andre siden tok det relativt mye tid å få samlet inn denne informasjonen, ettersom det ikke var like mange på campus.

Slutten av uken

Denne uken har vi gjennomført observasjoner i det fysiske miljøet brukerne befinner seg i. Dette har gitt oss en god innsikt av hvordan brukeren oppfører seg i den rette konteksten som løsningen skal befinne seg i. Vi skulle gjerne ha snakket med brukerne også for å få videre innsikt i behov, hva de gjør når de er på labben og hva de synes om dagens løsning. Derfor vil vi neste uke fortsette med intervjuer for videre innsikt.

Uke 6 | Digitale intervjuer

---

Forrige uke gjennomførte vi en feltobservasjon på IVB laben der vi prøvde å finne ut hvor mange som faktisk la merke til skjermen. Ut fra testene viste det seg at det var få som faktisk observerte den. Dermed må vi nå finne ut hvorfor såpass mange ikke legger merke til den og hva som skal til for at løsningen vår blir mer synlig. Denne uken har vi planer om å snakke med Orakeltjenesten om de har noen allerede eksisterende programmer som vi kan bruke til prosjektet og vi skal intervjue noen brukere for å innhente innsikt.

Tirsdag 09.02.21

Tirsdagen møttes vi på skolen for å jobbe litt med oppgaven og bli enige om arbeidsoppgaver. Litt senere på dagen gikk vi innom orakeltjenesten på campus for å høre angående eksisterende programvarer NTNU bruker. Det var dessverre ikke mye hjelp å få av han som stod der, han hadde lite kunnskap rundt dette feltet og anbefalte oss å kontakte orakeltjenesten i Trondheim. Dermed satte vi oss ned og skrev mail til orakeltjenesten før vi tok kvelden.

Figur 6: Mailen vi skrev til Orakeltjensten i Trondheim

På kvelden på tirsdag fikk jeg (Lisa) en telefon fra en venninne jeg hadde vært med helgen før om at hun hadde testet positivt for Covid-19. Dette ville si at jeg ble satt i karantene med en gang og i løpet av de neste dagene fikk også jeg positivt testsvar. Dette førte til at jeg ble satt i isolasjon og Ann Margit ble satt i karantene frem til hun hadde testet seg siden hun var en av mine nærkontakter.

Selv om vi begge jobber best når vi møtes fysisk prøvde vi å motivere oss til å få få jobbet videre i karantene/isolasjon. Vi fikk avtalt digitalt intervju med tre studenter under IVB fakultetet og gjennomførte disse på torsdag.

Digitale intervju

Vi avtalte intervju med tre forskjellige studenter under IVB fakultetet. Vi snakket med to gutter og en jente. Tanken er å variere med alder og kjønn på studentene for et litt bredere spekter av ideer. Det har ikke så mye å si foreløpig når vi bare har samlet inn innsikt fra tre brukere, men etterhvert som vi får flere testpersoner så vil vi muligens se en forskjell.

Under intervjuene prøvde vi å fokusere på å stille spørsmålene og dermed la brukeren svare for seg. Vis brukeren sto fast informerte vi om at de hadde god tid til å tenke seg om og ikke trengte å stresse frem det første og beste svaret. Vi fokuserte også på å ikke stille veiledende spørsmål eller å putte svar i munnen på dem. Vi brukte tiden vi hadde og stilte oppfølgingspørsmål for å få dem til å utdype et svar vi ville ha mer informasjon om. ^[5][6] Denne brukertesten har også lagt noe grunnlag for den neste brukertesten vi skal gjennomføre.

INTERVJUSPØRSMÅL

• Kjønn:
• Alder:
• Studie, hvilket år:
• Hvor ofte er du på labben?
• Hva er grunnen til at du møter opp på labben? (Hva gjør du når du først er her?)
• Kan du beskrive hva du ser med en gang du kommer inn hoveddøra på labben?
• Hvor ofte ser du på bookings-oversikten? Hvorfor/ hvorfor ikke?
• Hva fanger oppmerksomheten når du kommer inn i rommet?
• Har du ofte dårlig tid når du kommer hit? (finne ut “state of mind” når de er her)
• Hvor ofte booker du via BookitLab? (Er det tungvindt å gjøre det på pcen? Hadde du booket oftere om du kunne gjort det fysisk her?)
• Hvordan synes du det er å finne frem til dit du skal?

Figur 1: Dagens skjermløsning.

• Hva er førsteinntrykket når du ser på skjermen?
• Hva liker du med løsningen?
• Hva misliker du med løsningen?
• Hva hadde gjort at du hadde lagt bedre merke til den og sett på den ofte?

BRUKER NR. 1

Ettertanke bruker nr. 1:

Hun var innom da vi satt og observerte i labben forrige uke noe som gjorde at hun visste hva vi hadde oppgave om. Dette kan ha påvirket svarene på noen av de tidligere spørsmålene, men vi så det ikke som en så stor påvirking at hun ville være “biased”. Hun kom med mye god innsikt og forslag som vi kommer til å ta med videre i prosessen.

BRUKER NR. 2

Ettertanke bruker nr. 2

Denne brukeren fikk vi litt mindre innsikt fra. Det virket som korte og lite gjennomtenkte svar. Om dette var grunnet dårlig formulerte spørsmål eller lite engasjement fra brukeren må vi se litt nærmere på så vi får mer ut av videre testobjekter.

BRUKER NR. 3

Ettertanke bruker nr. 3

Denne brukeren hadde igjen litt mer innsikt å komme med. Det var litt begrenset, men noe vi kan ta med oss videre. Det virket som at brukerne som var lite tilstede på campus også slet med å svare så veldig utfyllende. Dette er muligens fordi disse personene ikke har samme kjennskap til skjermen eller generelt har vært mindre observante på oppsettet rundt labben.

Slutten av uken

Denne uken har vi fått snakket med orakeltjenesten, men venter enda på svar fra orakeltjenesten i Trondheim, vi har intervjuet tre brukere, jeg (Lisa) har fått positiv corona test og vi har kontaktet den andre gruppen som har samme oppgave for å dele den informasjonen vi hadde kommet frem til. De hadde dessverre heller ikke funnet ut noe mer angående programvare. Neste uke er planen å lage noen skisser som vi kan ta med på de neste intervjuene. Vi skal også intervjue noen flere brukere for bedre innsikt, denne gangen med skisser.

Uke 7 | Isolasjon og karantene livet

---

Forrige uke fikk vi sendt mail til orakeltjenesten i Trondheim angående programvare og vi intervjuet tre studenter fra IVB fakultetet. Denne uken var planen egentlig å lage skisser og å intervjue noen flere brukere, men etter å ha sittet isolert i noen dager sank motivasjonen veldig. Dette førte til at resten av uken ble lite produktiv og vi bestemte oss for heller å fokusere på å få finpusset teksten vi allerede har skrevet og å få lagt inn arbeidet i research catalogue. Som nevnt tidligere så jobber vi i docs siden research catalogue funker dårlig som et samarbeidsverktøy. Neste uke vil jeg være ute igjen av isolasjon og vi vil da jobbe videre med det vi egentlig hadde planer om denne uken.

Uke 8 | Tekniske aspekt, skisser og intervjuer

---

Denne uken skal vi utforske videre rundt det tekniske aspektet, lage første skisser og intervjue flere brukere med den samme intervjuguiden som tidligere, med skissene vi har laget. Ettersom det har gått litt tregere rundt det tekniske aspektet enn forventet, velger vi å jobbe parallelt slik at vi utarbeider skisser og kommer videre med disse for å få fremgang i prosessen.

Videre informasjon rundt det tekniske

Helt i starten av uken kontaktet vi den andre gruppen med det samme prosjektet for å høre hvordan de lå an med å undersøke den tekniske delen. De hadde ikke kommet noe lengre og hadde på lik linje med oss vanskeligheter for å forstå ulike begreper. De visste heller ikke helt hvor de skulle henvende seg og hadde bestemt seg for å fokusere mer på designet rundt løsningen. Dermed avsluttet vi kontakten angående den tekniske researchen med den andre gruppen.

Vi måtte belage oss på å vente litt lengre enn forventet på svar fra Orakeltjenesten, men denne uken fikk vi endelig svar (Figur 7).

Figur 7: Svar fra Orakeltjenesten i Trondheim.

Vi forstod ikke så mye av begrepene i svaret, ettersom dette er utenfor vårt fagfelt. Begrepene vi spesielt ikke forstod var API, MySQL og instrumenter. Derfor sendte vi en mail til oppdragsgiver for å spørre videre om vi kunne få en oppklaring og fikk svar (Figur 8).

Figur 8: Svar fra oppdragsgiver (navn sensurert ut i grått med hensyn til personvern).

Dette svaret var heller ikke så forståelig for oss, noe som gjorde oss litt motvillige. Men vi ba om et fysisk møte med oppdragsgiver slik at vi kunne få en nærmere forklaring. Etter møtet forstod vi det viktigste angående API, som vil si at det er noe man trenger for overføring av data fra det som er booket i kalenderen over til et eget brukergrensesnitt. Instrumenter er alle maskiner/utstyr som finnes på laben.

Vi fikk snakket også videre rundt BookitLab. Vi hadde inntrykk av at studenter kunne booke rom/ utstyr i BookitLab, men ut ifra intervjuene var det ingen av studentene som hadde gjort dette. Det viste seg at det kun er en håndfull studenter som har gjort dette foreløpig, men at i fremtiden ser fakultetet for seg at alle studenter skal ha muligheten til dette. Her hadde det rett og slett oppstått en misforståelse der årsaken har vært utydelig kommunikasjon. Vi fikk også informasjon om at i fremtiden ser man for seg at alle maskiner skal ha en QR-kode der man kan få opp relevant informasjon og booke den. Dette var informasjon vi gjerne skulle hatt helt i begynnelsen, ettersom det kan være relevant for oss å ta med oss i en løsning. Vi gikk også nærmere inn på BookitLab-systemet, der oppdragsgiver viste oss at man kan søke opp et instrument og få opp i hvilket bygg det er plassert og finne frem via MazeMap.

Vi snakket også mer rundt om det med å kode opp en nettside som viser bookingsoversikten på skjermen, og hvilke forutsetninger og muligheter man har med en slik løsning. For å lage et nytt brukergrensesnitt med bookingsoversikten, forutsetter det at man har lisens til API’et til BookitLab, noe man foreløpig ikke har, men som er i fremtiden er relevant.

Første skisser

Denne uke har vi også laget 4 ulike skisser med ulike alternativer: en for en interaktiv touch-skjerm (Figur 9), en for rullerende skjerm (Figur 10), en for stastisk skjerm (Figur 11) og en for statsik skjerm med en QR-kode der man kan interagere via mobilen (Figur 12).

Figur 9: Skisseforslag for en interaktiv skjerm.

Figur 10: Skisseforslag for en rullerende skjerm.

Figur 11: Skisseforslag for en statisk skjerm.

Figur 12: Skisseforslag for en statisk skjerm med QR kode.

Intervju med brukere og skisser

Vi intervjuet tre nye brukere med skissene ovenfor og den tidligere intervjuguiden for å samle videre innsikt. Den første var en gutt på IVB-fakultetet og siste intervjuet var et gruppeintervju med to jenter fra Institutt for Design. Vi valgte å inkludere design-studenter ettersom det kan være realistisk at et slikt system også implementeres på Mustad.

Første del av intervjuet bestod av de tidligere intervjuspørsmålene for å se om det kunne danne seg et mønster i svarene. Andre del av intervjuet bestod av spørsmål om skissene, for å samle videre innsikt om hvilken type skjermløsning som er mest aktuell. Vi stilte spørsmål og plassering av skjerm, type skjermløsning og hvilke elementer de mente burde være med/ikke være med.

BRUKER NR. 1:

Ettertanke bruker nr. 1:

Denne brukeren ga oss mye god innsikt og ettersom han er studieassistent får man også et annet ståsted samtidig som han også er student selv. På en annen måte kan det tenkes at han har et litt annet behov når det gjelder bookingløsningen, ettersom han i tillegg er studieassistent og har behov for litt mer utfyllende informasjon, derav se bookinger lenger frem i tid.

BRUKER NR. 2 OG 3:

Ettertanke bruker nr. 2 og 3:

Det kan både være fordeler og ulemper med å intervjue personer sammen. Fordeler kan være at man får mer utfyllende svar ettersom man tenker på flere aspekter og utfyller hverandres svar. Ulemper kan være at man blir påvirket av den andres svar og ikke sier akkurat det man tenker selv. ^[7] Men akkurat i dette tilfellet veiet fordelene opp mot ulempene, i tillegg til at det var mer tidseffektivt. Begge personene var også veldig klare da de var uenige med hverandre og understreket dette godt.

Slutten av uken

Denne uken har vi kommet videre med det tekniske, laget skisser og intervjuet nye brukere med skissene. Vi har opparbeidet oss videre innsikt og kan derfor i de neste ukene arbeide ut i fra denne. Neste uke vil vi gå mer systematisk gjennom innsikten vi har hentet og tolke analysere denne slik at vi får en bedre oversikt å jobbe ut ifra.

Uke 9 | Siste lo-fi brukertest, idésortering og personas

---

Forrige uke gikk hovedsakelig til første brukertest med skisser. Vi fikk litt mer innsikt i hva brukeren ønsker og kom frem til en skjermløsning. Skjermoppløsningen vi har valgt å gå for er en statisk skjerm med QR kode. På denne måten kan vi kombinere de statiske og interaktive skissene våre. Denne uken skal vi lage nye skisser basert på den innsikten vi fikk forrige uke. Vi skal også brukerteste disse skissene før vi skal sortere alle ideene vi har kommet frem til så langt. Deretter er planen å lage to personas utfra innsikten vi har slik at vi får en mer tydelig oversikt over brukerne og deres behov.

Siste lo-fi brukertest

På den tidligere testen forklarte vi brukerne om hvordan løsningen fungerte og ga de litt tilleggsinformasjon. Siden dette er en løsning som skal være selvforklarende, vil vi i denne brukertesten ikke forklare noe i forkant for å se hvor intuitiv den er. På alle brukertestene påminnet vi brukerne om at de skulle tenke høyt slik at vi fikk innblikk i deres tanker og kan ta nytte av det med nye justeringer.

Nye skisser

Figur 13: Ny skisseforslag statisk skjerm med QR kode

Figur 14: Skisseforslag 1 til mobil etter skannet QR kode på statisk skjerm.

Figur 15: Skisseforslag 2 til mobil etter skannet QR kode på statisk skjerm.

BRUKER NR 1:

Ettertanke bruker nr. 1:

Vi fikk god innsikt her om hva vi må justere i forhold til ordbruk på ulike elementer og litt om hvordan flyten må forbedres slik at man lett finner den funksjonen man skal benytte seg av. Vi fikk også en pekepinn på hvor intuitiv løsningen er, da vi så hvor lang tid det tok før man fikk overblikk og hva hun ikke forstod slik at vi måtte forklare nærmere.

BRUKER 2,3,4:

Ettertanke bruker nr. 2, 3, 4:

Disse brukerne skjønte heller ikke hensikten med de stiplede og hele linjene i kartoversikten, slik at her må vi gjøre justeringer slik at formålet med de blir mer tydelig. En annen viktig ting er at det må være mer klart at prikken på kartet er der skjermen står og ikke selve GPS-plasseringen til mobilen. Funksjonen med alle ledige rom er også noe som kan være nødvendig å ha med. Vi velger også å fjerne oppmøteregistreringen ettersom det var noe vi (Lisa og Ann Margit) diskuterte å fjerne før vi startet brukertestingen, og ettersom disse understreket poenget vi også kom frem til, underbygget det ekstra. Disse kommenterte også på flyten frem til bookingen, slik at dette må vi helt klart gjøre noe med.

Justeringer etter første del av brukertesten

Etter de første bruker testene på de nye skissene bestemte vi oss for å gjøre noen små endringer før vi fortsatte brukertesten på flere. Endringene med begrunnelse vises under.

Figur 16: Skisseforslag 1 til mobil etter skannet QR kode med endringer.

Endringen gjort på skisseforslag 1 er hovedsakelig å bare fjerne “registrer oppmøte”. Vi snakket litt sammen før brukertesten om at denne funksjonen kanskje virket litt påtvunget og at personene som skannet QR koden kanskje ikke enda viste hvilket rom de skulle på. De fleste studenter og ansatte har også nå blitt vant med å skanne QR koden i det man går inn på et rom eller ved selv pulten, så det å legge til denne funksjonen ved skjermen kan muligens bli litt forvirrende. Da vi brukertestet på bruker 2, 3 og 4 fikk vi også bekreftet at denne funksjonen kanskje var litt unødvendig, hvis ikke hvertfall feil plassert.

Figur 17: Skisseforslag 2 til mobil etter skannet QR kode med endringer.

På skisseforslag 2 valgte vi å endre en av alternativene du kommer til ved skanning av QR koden fra “finn veien” til “Utstyr”. Dette fordi “finn veien” er allerede en slags funksjon inne på laboversikt. Når du søker på et rom eller utstyr inne på “laboversikt” så vil veien til rommet du har søkt etter eller rommet med utstyret bli vist. Vi valgte å sette inn en “utstyr” knapp istedenfor siden dette ble nevnt ved en tidligere brukertest. Muligheten til å kunne søke opp hva slags utstyr rommet har, i tillegg til litt informasjon om rommet.

BRUKER NR 5:

Ettertanke bruker nr. 5:

Denne brukeren så ikke helt behovet for å kunne booke rom eller utstyr, ettersom han alltid spør personer om slike forespørsler. Han vil ikke bruke tiden sin på å gå inn i et slikt system for å booke. Han synes derimot det kunne vært positivt å se hvor og hvilke ulike verktøy er, men virket ikke helt overbevist. Men likevel var det positivt at han skjønte bookingsoversikten og flyten i det å finne frem til et rom/område inne på laben. Han skjønte heller ikke de stiplede linjene, noe som alle tidligere brukere også misforstod.

BRUKER NR 6:

Ettertanke bruker nr. 6:

Her fikk vi både nye innspill og gode innvendinger som vi kan ta med oss videre. Hun er relativt kjent med området på laben slik at denne funksjonen har hun ikke behov for lengre, da denne blir mer relevant for de som ikke har vært der så ofte. Hun har mer nytte av å booke rom og maskiner som kan være mye opptatt. Dette har også gått igjen på de andre IVB- studentene vi har intervjuet. Det med kontaktinformasjon til person var også et godt innspill dersom man lurer på noe spesifikt. Innspillet med å ha mer informasjon om hvilke maskiner og hva man har mulighet til og hvordan var også et godt innspill. Dette kunne også for eksempel vært relevant for labene på Mustad slik at studenter vet litt mer om hvilke muligheter som er. Spørsmålet blir om vi skal ta det med i vår løsning, eller om det er innsikt som oppdragsgiver og faglærer kan ta med seg videre, med tanke på avgrensing og omfang av løsningen.

Ettertanke brukertest 3

Nå har vi gjennomført vår tredje og siste brukertest på lo-fi prototypen. Vi føler vi har samlet nok innsikt til å kunne bevege oss videre til en digital prototype og det er dette som er planlagt som neste steg. Den siste brukertesten har gitt oss noen spesifikke punkter vi må ta med oss videre. Et viktig aspekt som vi har innsett er at vi har to brukergrupper. IVB studenter som bruker laben hyppig og som kjenner til strukturen til laben. Så har vi for eksempel design studenter/alle andre som ikke er på laben i det hele tatt eller skjeldent. Det vi har fått frem er at de har to forskjellige behov. En gruppe viser til at de kan ha behov for booking, men resten er lite interessant for dem, med tanke på at de allerede skjenner området såpass godt. Den andre gruppen vil ikke nødvendigvis bruke bookingfunksjonen, men heller å finne frem til utstyr eller rom på området. Dermed har vi bestemt oss for å lage to personas, en for hver brukergruppe.

En annen oppdagelse vi hadde var at det var for varierte svar på hva som skulle være på området på skjemen vi har satt av til noe morsomt eller praktisk for å trekke oppmerksomheten til folk til å ta avgjørelsen nå. Vi er nødt til å brukerteste dette litt videre på flere personer for å få et klarer bilde på hva som er mest gunstig å plassere der. Dette vil vi da enten ta i en liten brukerundersøkelse for seg selv eller integrere det i de nesten brukertestene vi skal ha med hi-fi prototypen.

Idea portfolio

En idea portfolio brukes for å kunne sortere/rangere en samling av ideer/løsninger. Det brukes normalt en akse som sett på bildet under, med to variabler (innvirkning og gjennomførbarhet). ^[4:1] Ideene blir rangert så man blant annet kan sile ut de ideene som er veldig vanskelig å få gjennomført, eller ideene som ikke vil ha noe særlig innvirkning på sluttbrukeren. Som vist på bildet under så er det ideene plassert øverst i høyre rute som vil ha høyest innvirkning på brukeren og som har høyest gjennomførbarhet. Det er disse ideene vi vil ta med oss videre for å lage en digital løsning.

Figur 18: Idea portfolio, sortering av ideer.

Affinity diagramming

Etter intervjuene fikk vi en del innsikt som det var vanskelig å ha en god oversikt over, sett helt alene. Derfor valgte vi å bruke affinity diagramming som metode for å sortere og kategorisere innsikten fra brukerne. Denne metoden gjør at man for en bedre oversikt over innsikten og kan danne seg et bilde over problemområdet. ^[8] Som figur 19 viser, har vi samlet positiv og negativ innsikt fra den originale booking-oversikten, som vi kan ta med oss videre når vi skal begynne å skisse forslag til ny løsning.

Figur 19: Samling av innsikt og sitater om original booking-oversikt.

Vi samlet også innsikt og sitater rundt ulike ønsker og innspill brukerne hadde i forhold til løsningen, som figur 20 viser.

Figur 20: Samling av ønsker og innspill fra brukerne.

Flere av brukerne nevnte at det var komplisert å finne frem i starten, derfor samlet vi denne innsikten i en egen kategori, som figur 21 viser. De studentene som gikk andre og tredjeåret, hadde ikke problemer med å orientere seg nå lengre, men at det var et problem i starten kan indikere at dette er noe som må gjøres noe med.

Figur 21: Samling av innsikt rundt orientering i laben.

Personas

Vi har laget to personas basert på innsikten vi har fått fra ID og IVB studentene vi har intervjuet. En personas er en fiktiv person bassert på innsikten du har samlet inn fra brukerundersøkelser. Vi lager personas for å ha en representant for målgruppen vi jobber for. På denne måten har vi som designere også et bilde av brukeren som gjør det lettere å kunne forstå behovene deres. Men det er viktig å huske at dette kun er et hjelpemiddel og ikke en fasit på målgruppen. ^[4:2][9] Vi lagde to personaser siden vi oppdaget at det i teorien er to brukergrupper med ulike behov vi må ta hensyn til. En bruker er de som tilbringer mye tid i labområdet og er kjent med stedet og utstyret som er tilgjengelig, mens den andre brukeren er resten som av en eller annen grunn har et behov å dekke på laben.

Figur 22: Personas, designstudent (ID).

Figur 23: Personas, teknologistudent (IVB).

Slutten av uken

Denne uken har vi laget nye skisser basert på de tidligere tilbakemeldingene, brukertestet disse på totalt 6 personer og laget 2 personas basert på denne innsikten. Vi har hatt fokus på å teste så tidlig som mulig med skissene og dette har gjort at vi ikke lager noe som brukerne ikke har behov for. Med de to personasene får vi frem de ulike behovene blant studenter som er kjent på laben og de som ikke er det, i tillegg til hvilket institutt de tilhører som medfører ulike behov. Neste uke har vi veiledning med annen faglærer for å forklare prosjektet og prosessen så langt for å så få innspill. Det kan være veldig nyttig, slik at vi får innspill fra en person som ser prosjektet vårt utenfra og dermed med et litt annet blikk.

Uke 10 | Veiledning med annen faglærer

---

Forrige uke fikk vi gjennomført siste brukertest av lo-fi prototypene, vi fikk sortert ideene våre og laget personaser for både ID og IVB studenter. Denne uken har vi veiledning med annen faglærer, men utover det vil uken gå til jobbing i andre fag grunnet frister som må overholdes.

Veiledning med annen faglærer

Vi hadde veiledning med annen faglærer der vi forklarte prosjektet vårt og fikk noen innspill til prosessen videre. Vi snakket blant annet litt om den litt kronglete veien med det tekniske aspektet og tilbakemeldingen vi fikk her var at det var lurt å begynne i Figma når tiden for hi-fi prototype er inne. Vi snakket også rundt det med å trekke oppmerksomhet til skjermen og litt rundt det med hva studentene har behov for på en slik oversikt. Plassering av skjerm var også noe vi diskuterte rundt og at det kunne være lurt å teste ut med f.eks. papir, hvor det er mest gunstig å plassere den.

Slutten av uken

Denne uken har vi begge måttet fokusere på andre fag som nærmet seg fristen for innlevering. Dermed er det eneste vi har gjort i faget denne uken å ha veiledning med annen faglærer på tirsdag. Neste uke vil vi ta opp tråden igjen hvor planen er å lage første utkast av en digital hi-fi prototype.

Uke 11 | Første utkast av hi-fi prototype

---

Forrige uke gikk mesteparten av uken til jobbing i andre fag, dermed kom vi ikke noe særlig lengre på oppgaven. Denne uken derimot er planen å lage vår første digitale prototype.

Gjennomgang i lab med oppdragsgiver

Før vi skulle lage den digitale prototypen fant vi ut at vi trengte bedre oversikt over laben. Dermed tok vi turen dit for en liten observasjon av området. Etter å ha sett oss litt rundt fant vi fort ut at det kunne bli vanskelig å vite hvilke navn vi skulle bruke på områdene. Når det viser seg at Book-it-lab, studentene, lappene på dørene og kartet vi hadde fått tilgang på tidligere alle hadde forskjellige måter å referer til rommene på blir det vanskelig å vite hva som er riktig. Skal man gå for det som er mest kjent for de som tilbringer mest tid på stedet, eller skal man bruke de mer formelle navnene som står skrevet? Heldigvis møtte vi på oppdragsgiver som ga oss en omvisning. Dette gjorde at vi fikk et mer oversiktlig bilde av hva som var hvor og bruken av de forskjellige rommene. Han informerte oss også om hvilke navn vi kunne bruke, hvilke av områdene som var bookbare og hva som var planene for videre utvikling av laben.

Oppdraggiver fortalte oss blant annet om selvbjeteningskassene som står i hyllene nede ved PhD området i S113. Dette er et system som skal implementeres veldig snart hvor studenter kan oppbevare arbeider og lånt verktøy i låste kasser (om ønskelig). Han fortalte også om hvordan maskinverkstedet S114 skal bli delt i to (vist på kart), et maskinverksted S114A og en smie S114B.

Første utkast av hi-fi prototype

Hand-reach comfort zones on phones

Et element det kan være greit å tenke over når man designer en interaktiv skjerm er hva som er komfortsonene for brukeren. Dette spesielt med smart telefoner hvor store delere av brukerne navigerer seg rundt med tommelen. Mobiltelefonene blir større, men fingrene endres ikke, da er det viktig å basere oppsettet av applikasjonen på hva som er enklest og mest komfortabelt for brukeren å nå. Det kan være vanskelig til tider å få all informasjonen innefor komfortsonene, men da er det viktig at hvertfall de viktigste delene er innefor rekkevidde. ^[10]

Figur 24: Hand-reach comfort zones on phones.

Hovedskjerm:

Vi valgte å lage to ulike utkast av hovedskjermen, slik at vi kunne få brukerne til å velge ut de elementene som ga best brukeropplevelse. Figur 25 viser disse to utkastene. Vi vurderte om det var nødvendig med NTNU-logo og klokkeslett øverst til høyre, ettersom dette kan skape ekstra stimuli og muligens trekke fokuset vekk fra oversikten og kartet. Vi vurderte også om hvilken overskrift som var mest passende og om det i det hele tatt var behov for en overskrift. Men vi tok en beslutning om å heller brukerteste dette senere for å se hva brukerne hadde behov for.

Vi har også tatt en beslutning om å ha hovedskjermen på engelsk. Dette er for å inkludere internasjonale studenter slik at de også skal få muligheten til å bruke løsningen. Nordmenn er generelt gode i engelsk, derfor ser vi ikke på dette som en stor utfordring for norske studenter, eksterne kunder og ansatte.

Figur 25: To ulike forslag/utkast av hovedskjermen.

Kart

Vi har valgt å beholde kartet og gjøre det mer synlig at områder som er egne rom, er tydelig markert i forhold til de ulike områdene som er på det store rommet i hoveddelen av laben. Mange av brukerne sa at det tidligere kartet ikke viste tydelig hva som var egne rom, slik at kartet kunne feiltolkes. Vi har også valgt å bruke fargekoding på kartet som indikerer om rommet er ledig, opptatt eller snart ledig/opptatt. Her har vi også laget to ulike alternativer som må brukertestes for å se hva som er mest foretrukket blant brukerne, som figur 26 viser. Flere av brukerne mente at de ville få en rask og enkel oversikt over hva som var ledig/opptatt, og med en slik fargekoding håper vi at brukerne opplever dette som oversiktlig og enkelt. For å inkludere personer med fargesvakhet, har vi en ekstra indikasjon med tekst som beskriver om rommet er ledig, opptatt eller snart ledig/opptatt. På denne måten brukes ikke farge som eneste indikator. ^[11] Dette vil også mest sannsynlig gjøre det enklere for alle å forstå hva fargene indikerer. Vi har valgt å ha et hvitt kors med rød bakgrunn for å indikere at det er førstehjelpsutstyr plassert i laben. På det tidligere kartet var dette merket med teksten “HMS”. Vi mener at et slikt universelt symbol er bedre, ettersom man enklere og raskere oppfatter hva det skal indikere. Vi anser dette også som en meget viktig informasjon å få med seg. Rødt fanger i tillegg mye av oppmerksomhet ^[12].

Figur 26: Nærbilde av kart. Alternativ 1; heldekkende farger, Alternativ 2; farger i mindre sirkler

Bookingkalender

Den kalenderen som nå vises direkte fra nettleser til BookitLab viser rommene loddrett nedover. Vi har valgt å endre slik at rommene vises vannrett, som figur 27 viser. Grunnen til dette er at man leser fra venstre til høyre (på norsk og engelsk) og da er det lettere å få en oversikt over alle rommene og hvilke aktiviteter som skjer i de tilsvarende rommene. ^[13] Vi har valgt å ha rom-navnet større enn romnummeret ettersom vi tenker at det er mest naturlig at studenter og ansatte referer til rom-navnet, og da får rom-navnet større fokus. På den måten blir det lettere å kjenne igjen rom-navnet for å få et raskt overblikk. På hver booking har vi varigheten på bookingen i form av klokkeslett helt øverst på den aktuelle bookingen. Ved å ha denne indikatoren i tillegg til størrelsen på elementet, får brukeren et visuelt og tekstlig informasjon på hvor lenge bookingen varer. I tillegg får man supplementet med linjene og tidspunktene med 3-timers indikator (kl 09, kl 12, kl 15). Man får også informasjon om hvordan aktivitet som foregår og hvem som har booket. Ved å ha et ikon ved siden av personen som har booket, blir det lettere å oppfatte at dette handler om en person. Ved å bruke komplementærfarger (blå og oransje) har det den effekten at den oransje linjen kommer mer frem. Dette er et viktig element som viser nåværende tid, og ved å bruke komplementærfarger blir denne visuelt mer synlig. ^[14]

Figur 27: Nærbilde av kalenderoversikten med booking på hovedskjermen

QR-kode med tilhørende tekst

Nederst på hovedskjermen er det en QR-koden med forklarende tekst som viser hvilke funksjoner man kan benytte seg av ved å scanne denne. Ved å bruke en slags snakkeboble som er rettet mot ikon vil man enkelt kunne indikere hva som skjer ved å scanne koden. Vi har valgt å implementere disse funksjonene etter resultatene av innsikten. Noen av brukerne hadde behov for å se flere dager frem i tid, noen hadde problemer med hvor man skulle henvende seg for å kjøpe materialer og nye studenter har problemer med å finne frem på laben. Det at studenter kan booke rom og utstyr er en funksjon som skal bli tilgjengelig i nærmeste fremtid, derfor har vi valgt å ha med denne her.

Figur 28: Nærbilde av QR-kode og tilhørende infotekst

Mobilversjon etter scannet QR-kode

Hovedskjerm

På hovedsiden av mobilversjonen har vi valgt å ha book utstyr/rom øverst ettersom dette er ansett som hovedfunksjonen på mobilen. Deretter har man funksjonene “Laboversikt” og “Kjøp materiale”, som figur 29 viser. Når man scroller nedover vil man se oversikten for dagen. Ved å sveipe bortover vil man se resterende rom. For å gå til neste dag, trykker man på pilene. Vi er litt usikre på hvordan brukerne vil oppfatte dette og om det er intuitivt. Dette er derfor noe vi må teste. Vi anser det som viktig at brukerne har mulighet til både norsk og engelsk språk ettersom NTNU har internasjonale studenter. På den måten blir informasjonen tilgjengelig for alle.

Figur 29: Hovedside på mobilprototype etter scannet QR-kode

Book rom/ utstyr

Når man trykker på “Book rom/utstyr” vil man bli redirigert til feide-innlogging for å kunne få tilgang til å booke via BookitLab, som figur 30 viser. Vi anser det ikke som ideelt at det er såpass mange steg for å kunne booke, men man må uansett logge inn for å kunne booke via BookitLab.

Figur 30: Redirigering til feide-innlogging for tilgang til å booke via BookitLab

Lab oversikt

Når man trykker på Laboversikten vil man få opp kartet over laben. For å lokalisere et rom eller utstyr, søker man i søkefeltet. Figur 31 viser når man har søkt opp 3D-print laben. Da får man opp en pil til rommet og rommet blir markert i egen fargen. På den måten kan nye studenter enkelt finne veien til valgte rom. Her kan man også søke utstyr og få opp hvilket rom/område dette er lokalisert på. Dette var et problem som kom frem av brukerinnsikten.

Figur 31: Mobil prototypen av lab oversikten med kart og fargekodede rom.

Figur 32: Mobil prototype av lab oversikt etter å brukt søkefeltet for å finne veien til 3D laben.

Generell rominformasjon

Ved å trykke på et valgt rom på kartoversikten vil man få opp en utstyrsliste, krav til kurs og kontaktperson for rommet, som fremkommer av figur 33. Dette var informasjon som også kom frem av brukerinnsikten.

Figur 33: Generell rominformasjon for rommet du trykker på.

Kjøp materiale

Flere studenter savnet konkret informasjon om hvor man skulle henvende seg for å kjøpe materiale. Derfor har vi valgt å implementere funksjonen med å kunne kjøpe materiale ved å bli redirigert til nettbutikken til NTNU der man kan kjøpe ønsket materiale.

Figur 34: Redirigering til valg av institutt før du kommer inn på kjøp siden.

Slutten av uken

Denne uken har vi brukt all tid og energi på oppsettet av første utkast av den digitale prototypen vår. Denne er basert på innsikten fra tidligere brukertester og skal reflektere elementene som brukeren har trekt frem som viktige momenter. Neste uke skal vi brukerteste den digitale prototypen vår og forhåpentligvis ha tid til å starte å gjøre endringer basert på tilbakemeldingene.

Uke 12 | Brukertest og tanker rundt moral, etikk og lovverk

---

Forrige uke ble vi ferdig med først utkast av den digitale hi-fi prototypen vår. Vi er utrolig spente på å få testet denne og få tilbakemeldinger på mulige endringer og å se hvordan den fungerer for noen som ikke har noen form for relasjon til den. Denne uken blir altså planen å brukerteste prototypen for så å gjøre nødvendige endringer.

Første brukertest av hi-fi pototypen

OPPSETTET AV BRUKERTESTEN

Vi bestemte oss for å dele opp brukertesten i to hoveddeler, der første del var å kartlegge hvilke elementer på hovedskjermen som var mest foretrukket blant brukerne. Deretter ville vi gå igjennom elementene på hovedskjermen og få tilbakemeldinger på disse. Andre del besto i brukeroppgaver for å teste flyten i mobil-løsningen, navigasjon og generell opplevelse av å bruke løsningen.

Første del, hovedskjermen:

Vi hadde laget to ulike utkast med ulike elementer, som vi presenterte for brukerne. De skulle si hvilken som var mest foretrukket og begrunne hvorfor. Vi var usikre på noen elementer og hva som var det beste for brukerne, derfor ville vi teste det på denne måten.

Vi lagde kart med to ulike fargekoding-forslag som vi ville få tilbakemelding på, som figur 35 viser.

Figur 35: Kart over lab området på IVB laben, alternativ 1; heldekkende farger, alternativ 2; farger i sirkler.

Vi laget også to ulike utkast, der vi hadde NTNU-logo, klokkeslett øverst til høyre og et annet med en annen overskrift uten NTNU-logo og klokkeslett, som figur 36 viser.

Figur 36: Alternativ 1: Overskrift, logo og klokkeslett øverst til høyre, alternativ 2: Annen overskrift uten logo og klokkeslett øverst til høyre.

I tillegg ville vi få tilbakemeldinger på følgende på elementer på hovedskjermen:

• Er kalenderoversikten selvforklarende?

Figur 37: Bilde av kalenderoversikten, hovedskjerm.

• Er det forståelig at skjermen på kartet viser hvor den er plassert? (Er det tydelig at det er skjermen man står og ser på?)

Figur 38: Nærbilde av skjerm som er plassert på kartet for å vise plasseringen i rommet.

• Er teksten på snakkeboblen ved QR-koden selvforklarende og tydelig?

Figur 39: Bilde av infotekst innrammet i en snakkeboble ved siden av QR-koden.

Andre del, mobilversjon:

På den andre delen ville vi gi ulike oppgaver til brukeren for å se hvordan de gjennomførte disse. Vi valgte å ha med oppgaver her som vi var litt usikre på om var intuitive for brukeren. Ved å ha klare formulerte oppgaver og områder man vil teste, får man god innsikt på akkurat disse områdene som gir et realistisk testresultat. ^[15]

Brukeroppgavene var som følgende:

• Finn veien til 3D-laben og se hvordan utstyr det er der
• Se kalenderoversikt for Måle-Laboratoriet for neste dag
• Finn kontaktperson til 3D-print rommet
• Fri navigering for å se hvordan bruker faktisk bruker appen

Bruker 1:

Ettertanke bruker 1:

Under denne testen var vi oppmerksomme på at vi ikke skulle gi for mye hint og ikke si mye, slik at man lar brukeren få tenke selv og se på hvordan brukeren klarer oppgavene ^[15:1]. På oppgaven om å finne veien til 3D-rommet var det vanskelig for brukeren å finne frem, og derfor måtte vi gi små hint. Dette viser at her må det gjøres forbedringer. Brukeren ble også bedt om å tenke høyt under testen, noe som fungerte veldig godt. På den måten fikk vi innblikk i hvordan brukeren opplevde løsningen. Vi stilte også spørsmål i etterkant om hvordan følelser brukeren hadde under oppgavene og bruken, og resultatet her var tilfredsstillende. Han hadde ingen store frustrasjoner og synes at designet var estetisk fint og løsningen var enkel å navigere seg gjennom. Om et designet er estetisk, så er det faktisk slik at det skapes en positiv emosjonell respons i hjernen, som ofte gjør at det kan oppleves som mer brukervennlig. Det har også den effekten at man tenker mer kreativt og lettere finner løsninger på problemer som måtte oppstå. Denne effekten kalles “aesthetic-usability effect”. ^[16]

Bruker 2 og 3:

Ettertanke bruker 2 og 3:

Denne brukertesten ble gjennomført digitalt over en videosamtale med to brukere sammen. Vi delte skjerm slik at de fikk se hovedsiden, og videre scannet de QR-koden for å komme inn på mobilsiden. De ble bedt om å vise hva de gjorde på mobilen med kamera og tenke høyt på alt de gjorde. På denne måten ble vi sikre på at vi fikk med oss alt hva de faktisk gjorde og hva de tenkte. Vi har aldri gjennomført en digital test før, men ettersom situasjonen er som den er nå, var dette en god erfaring. Siden man ikke kan møtes fysisk i samme grad som før, må man tenke på alternative løsninger. Brukerne var ikke helt i riktig målgruppe, men likevel synes vi at disse kunne gi et godt bilde på hvor selvforklarende løsningen er og hvordan flyten i mobilappen og funksjonene i denne opplevdes. Det var også interessant at med disse brukerne var resultatet omtrent det samme som resten av brukertestene. Den eneste informasjonen disse brukerne fikk om løsningen, var at det var en skjerm som skulle stå ved inngangsdøren i et stort labratorie-område. Det var litt sprik i hvordan disse to brukerne opplevde mobil-løsningen, da den ene satt igjen med større frustrasjoner enn den andre. Dette gjaldt spesielt navigasjon og hvordan man skulle finne frem til informasjon. Dette kan både skyldes teknisk kompetanse og at brukerne kanskje hadde ulike mentale modeller for hvordan de ser for seg at informasjon skal være strukturert ^[17].

Animasjon i design

Som vi har snakket om tidligere så har vi prøvd å finne noe som kan trekke brukeren til å legge bedre merke til skjermen og for å trekke oppmerksomheten mot QR koden spesifikt. Vi har vært innom flere type ideer for mulige løsninger, men har nå endt opp med å legge til en animasjon ved teksten til QR koden. Animasjoner blir mer og mer vanlig i designprosessen av nettsider og digitale tjenester, og skillet mellom video og grafisk design blir sakte men sikkert visket ut. Animasjonen blir ikke lagt til for å bedre det estetiske bildet av prototypen vår, men heller som en hjelpende funksjon for brukeren. ^[18] Vi har nå lagt til en animasjon på hovedskjermen som vi vil ta med under videre brukertesting for å få tilbakemelding fra brukeren.

Figur 40: DNA gif. Stilbilde av gifen vi har brukt på hovedskjermen.

Bruker 4:

Ettertanke etter brukertest nr. 4:

Brukertesten ble gjennomført på en interaksjonsdesign student som har jobbet med brukertesting selv, noe som gjorde oppgaven vår litt enklere. Hun vet at vi er ute etter detaljer og svarer utfyllende på oppgavene vi gir. Ut fra brukertesten fikk vi mye bra tilbakemeldinger om hvilke elementer hun mener passer best til prototypen og hvorfor. Blant annet at vi burde ha “book” knapp på hvert utstyr i utstyrslisten for å minimere antall tastetrykk og forslaget om en linje hvor du kan trykke deg mellom rommene, istedenfor å ha alle tilgjengelige på en gang.

Bruker 5:

Ettertanke bruker nr. 5:

Denne brukeren måtte vi før vi begynte ha en innføring på hva en brukertest var siden han aldri hadde vært med på det tidligere. Brukertesten ble litt hastet av brukeren, men korte svar og vi måtte flere ganger minne han på å tenke høyt. Dette viser at vi kanskje må tenke litt mer på hvordan vi formulerer oss når vi snakker med brukere som helst vil svare kort og enkelt og ikke er vant med å bli spurt om hvorfor. Vi prøvde å informere brukeren om at det ikke var han vi testet, men selve designet til tjenesten. ^[19]

Bruker 6:

Ettertanke bruker nr. 6:

Siste brukeren vi brukertestet hadde aldri vært på lab området noe som gjorde at vi fikk et bedre bilde av hvordan en eventuell ny student ville opplevd tjenesten. Det var noe forvirring rundt fargekodingen, men ellers forsto han størstedelen av oppsettet.

Refleksjoner etter brukertestene:

Alle brukertestene ble gjennomført utenfor laben, altså ikke i det miljøet som løsningen er ment å brukes i. Derfor fikk brukerne heller ikke sett hovedskjermen på den skjermen som er ment for visning. Derfor måtte vi vise alle elementene på skjermen separat, og ikke som en helhet med tanke på at det ikke ble vist i riktig skjermformat. Dette kan ha påvirket resultatene i noen grad. Av praktiske årsaker måtte vi gjennomføre brukertestene utenfor det rette miljøet, men likevel fikk vi god innsikt i hvordan brukerne opplevde flyten og brukervennligheten. Vi fikk også et innblikk i hvor intuitiv løsningen er og hvordan navigasjonen opplevdes.

Oppsummering av funn og endringer som må gjøres:

• Kart med heldekkende farger som gjør det lettere å se med en gang hva som er ledig/opptatt
• Gjøre finn veien-funksjon mer tydelig og synlig
• Tydeligere indikasjon på at pilen er for neste dag
• “Book utstyr” knapp på hvert utstyr i utstyrslisten
• Overskrift med “Bookingoverview”
• Ha med NTNU-logo
• Ha med bevegende element nederst
• Klokkeslett øverst til høyre og på kalenderen

Tanker rundt etikk, moral og lovverk

GDPR

I vårt prosjekt er det spesielt GDPR som er relevant i forhold til lovverk og personvern. Alle personopplysninger fra intervjuer og mail er fjernet, slik at ikke personene kan spores opp og gjenkjennes. Før hvert intervju har vi også forklart formålet med intervjuet og hva opplysningene skal brukes til, der alle intervjukandidatene har gitt samtykke.

I forhold til løsningen vår blir GDPR relevant i forhold til å vise på skjermen hvem som har booket. Her kan en løsning være at man kun identifiserer med ansatt/student på hvem som har booket. Eventuelt kan man innhente samtykke på at navnet vises i det man skal booke noe. Ettersom vi har valgt at man kan ha muligheten til å booke rom/utstyr på mobilen etter man har scannet QR-koden, vil opplysninger som brukernavn og passord samles via Feide og BookitLab. Men dette skjer via BookitLab-nettsiden slik at det er noe som ligger utenfor vår kontroll. Om vi skulle ha utviklet en ny løsning for å booke rom/utstyr så hadde dette vært noe vi måtte tatt i betraktning i høyere grad.

Universell utforming

Et annet viktig aspekt vi må ta i betraktning er at løsningen vår skal være universelt utformet slik at den er tilgjengelig for så mange som mulig. På den måten utelukker man ingen og informasjonen blir lettere å forstå for alle. Her er det spesielt personer med fargesvakhet og nedsatt syn som er aktuelt. Vil vil bruke ulike verktøy for å forsikre oss om at de lovpålagte kravene i WCAC. 2.0 (nivå A og AA) er oppfylt og bruke fargekombinasjoner som er enklere for fargesvake å skille fra hverandre. Dette vil gi gode, enkle og tilgjengelige løsninger for alle. ^[20]

Slutten av uken:

Denne uken har vi brukertestet den digitale prototypen vår og reflektert rundt moral, etikk og lovverk som gjelder for vårt prosjekt. Som designer er det viktig å kunne ha evnen til å reflektere rundt slike aspekter og ikke kun fokusere på det estetiske/design delen. Det er også viktig å være oppmerksom på hvilke avgjørelser man tar som designer og hvordan dette påvirker mennesker som skal bruke løsningen. ^[21] Neste uke er det påskeferie så da har vi begge blitt enige om å ta oss litt fri og kose oss på fjellet.

Uke 13 | Påskeferie

---

Denne uken har vi begge sittet i solveggen på hytta med en kald øl og raske briller, dermed har dessverre skole utgått. GOD PÅSKE!

Figur 41: Ann Margit og Lisa sin påske oppsummert.

Uke 14 | Endring av prototype basert på brukertest

---

Denne uken blir målet å få gjort justeringer på prototypen basert på tilbakemeldingene og resultatene fra brukertestene. Det var interessant å se hvordan de fleste testobjektene hadde de samme problemene og at det dannet seg et mønster på hvilke forbedringer som må gjøres. Dette ga oss en god indikasjon på hva som må jobbes med videre for å skape en bedre brukeropplevelse.

Hovedskjerm

Det var tydelig at vi må bruke det kartet med heldekkende farger, slik at brukeren raskt får et overblikk over hva som er ledig/opptatt. Dette gjelder både på hovedskjermen og mobilversjonen. Flertallet av brukerne synes overskriften med “Booking overview” var mest informativ. I tillegg synes flertallet at det var nødvendig å ha med klokkeslett øverst til høyre, NTNU-logo og et bevegende element nederst. Figur 42 viser justeringene vi har gjort på hovedskjermen etter brukertesten.

Figur 42: Justeringer på hovedskjerm basert på brukertestene

Finn veien funksjonen

Alle brukerne hadde problemer med å finne ut av at de skulle søke i søkefeltet for å finne veien til rommet. Alle trykket heller på området, og resultatet var da at de fikk opp rominformasjonen. Dette skapte forvirring hos brukerne. I den nye justeringen har vi flyttet søkefeltet ned under overskriften “Laboversikt” og lagt på en linje rundt søkefeltet for å gjøre det mer synlig, som figur 43 viser. Forhåpentligvis vil dette gjøre denne funksjonen mer tydelig, slik at brukeren ikke overser dette. Vi vurderte om vi skulle gjøre slik at finn veien funksjonen heller skulle bli aktiv når de trykket på rommet, slik alle brukerne oppfattet at det egentlig var. Men da hadde det igjen blitt vanskelig å plassere rominformasjons-funksjonen et logisk sted.

Figur 43: Justeringer med tydeligere søkefelt flyttet nedover for bedre synlighet.

Kalenderoversikten for neste dag

Brukertesten ga oss også en indikasjon på at vi måtte forbedre funksjonen med å finne frem til neste dag via pilene. Flere av brukerne trodde man kunne sveipe bortover på rommene for å se neste dag, men da fikk man heller opp de neste rommene. Derfor har vi valgt å ha alle rommene som egne faner, og beholde pilen man trykker på for å se neste dag, som figur 44 viser.

Figur 44: Justeringer med faner for hvert rom.

Booking direkte fra utstyrslisten

Noen av brukerne fra brukertesten påpekte at det hadde vært praktisk med en book-knapp direkte for hvert utstyr på utstyrslisten man får opp på rominformasjonen. Vi har derfor lagt til funksjonen at man kan booke hvert enkelt utstyr fra denne listen, som figur 45 viser. På den måten slipper man å gå helt tilbake til hovedsiden for å så logge inn på BookitLab og søke opp utstyr.

Figur 45: Muligheten til å booke hvert enkelt utstyr direkte fra utstyrslisten.

NTNU-logo på alle sider

Ettersom det er en konvensjon med at logoer plassert øverste til høyre er for å komme til hovedsiden, har vi plassert denne på hver side som man kan trykke på for å komme til hovedsiden. Figur 46 viser et eksempel på dette. Den ene brukeren hadde litt problemer med å komme seg tilbake i forhold til navigasjonen, ettersom hun ikke bruke funksjonen som er innebygd på telefonen. På denne måten har man flere alternativer for å komme seg tilbake.

Figur 46: NTNU-logo øverst til venstre for å komme til hovedsiden på alle sider.

Slutten av uken:

Denne uken har vi gjort justeringer på prototypen basert på resultater og tilbakemeldinger fra brukertestene. Vi er fremdeles litt usikre på om finn veien-funksjon vil være tydelig nok for brukeren å oppfatte. Men for å finne ut av dette må vi brukerteste videre. Dette blir planen neste uke.

Uke 15 | Brukertest #2, hi-fi prototype

---

Forrige uke gjorde vi nødvendige endringer på prototypen basert på tilbakemeldingene vi hadde fått fra brukertesten i uke 12. Denne uken skal vi brukerteste de nye endringene for å se om modifikasjonene til prototypen har forbedret brukerforståelsen og brukerflyten. Vi vil også gjennomføre endringer basert på denne brukertesten om vi har tid i slutten av uken. Har vi gjort en bra nok jobb siden sist burde det være færre endringer fremover.

Miniobservasjon

Mens vi rigget prototypen til hovedskjermen for å teste, fikk vi holdt en mini felt-observasjon. Mellom brukertestene fulgte vi med på om folk som gikk forbi la merke til skjermen. Det var absolutt et mye større interessenivå rundt skjermen nå som den var endret, men om dette var fordi vi hadde laget en prototype som dro oppmerksomheten til folk mot skjermen eller om det bare var fordi det var noe nytt og spennende der er det vanskelig å si uten videre observasjon. Det var forøvring ingen som stoppet for å scanne QR koden, men det kan ha vært siden vi satt innen synsvidde. For at folk i det hele tatt skal begynne å bruke skjermen må de først erkjenne at den eksisterer og så kunne man derifra funnet ut om folk ville tatt nytte av QR koden.

Figur 47: Hovedskjerm etter forsterking av fargene på kartet og skalering av tekst.

BRUKERTEST 2:

Brukertest to av den digitale prototypen vår vil være en kortere brukertest enn den vi gjennomførte i uke 12. Målet med denne brukertesten er å teste noen elementer som vi fortsatt er usikker på fra forrige brukertest, som “finn veien” funksjonen og fargene på kartet på hovedsiden. Vi har også lagt til mer spesifikke scenarioer for brukeren å teste denne gangen for å se hvordan de forskjellige brukerflytene i prototypen blir forstått. ^[22]

Scenario:

Du er ny student på NTNU og skal møte opp på 3d-laben, hvordan finner du veien ved bruk av denne applikasjonen?

Du har planer om å sitte på læringsfabrikken neste dag (onsdag 7.april) og lurer på om det er ledig da, hvordan skal du finne ut av dette?

Spørsmål:

Hvordan oppfatter du fargene på kartet?

Hvordan opplevde du bruken av prototypen?

Bruker 1:

Ettertanke bruker nr. 1:

Første bruker satte lys på at fargene på kartet kanskje burde ha vært mer foklarende. Av de tre som var tilstede under brukertesten, så var det kun en som forstod fargekodingen på kartet. Et forslag kunne vært å legge til forklaring av fargene utenfor kartet. Men en annen nevnte at dersom man ser sammenhengen mellom teksten (ledig/opptatt) og fargene en gang så vet man hva det betyr. Ekstra forklaring på siden av kartet kan bli øverflødig, men vi vil ta det med videre til vurdering.

Enringer etter første brukertest

Vi gjorde en endring rett etter denne brukertesten, der vi gjorde om ledig/opptatt til store bokstaver og flyttet denne teksten med mer luft fra rom-navnet. Om dette fungerer bra nok vil neste brukertest mest sannsynlig gi et svar på. Det er selvfølgelig forskjeller i hvor mye informasjon de ulike brukerne oppfatter med en gang, noe som vi også ser av de andre brukertestene.

Figur 48: Ledig/opptatt/snart ledig/opptatt i store bokstaver for mer uthevelse.

Bruker 2:

Ettertanke bruker 2:

Bruker 2 kom med et veldig godt poeng om at det burde være mulig å både sveipe og trykke seg videre via pilene på kalenderfunksjonen på hovedsiden til mobil-prototypen. Dette gjør at vi ikke utelukker preferansen til brukere. Dette gjør at brukeren selv kan velge hvilken funksjonalitet de foretrekker å bruke.

Endring etter andre brukertest

Denne brukeren forstod heller ikke med en gang at fargene indikerte om det var opptatt/ledig, selv om vi hadde gjort den lille endringen. Derfor gjorde vi også en umiddelbar endring etter denne brukertesten, med å ha en høyere metning av fargene. Vi fikk tilbakemelding på at fargene var litt for duse, og at grønnfargen kunne mistolkes med en blåaktig farge. Neste brukertest vil mest sannsynlig gi en god indikasjon om denne justeringen var tilfredsstillende nok.

Figur 49: Forsterking av fargene på kartet.

Bruker 3:

Ettertanke bruker 3:

Rød / grønn fargeblindhet (protanomali og deuteranomali) er de mest utbredte fargeblindhetene, dermed vil det være stor sannsynlighet for at mennesker med disse funksjonsnedsettelsene kommer til å bruke skjermen og applikajsonen uten problemer. ^[23] Selv om vi tidligere har testet kontraster og størrelsesforhold opp mot WCAG 2.0 standarden og vet at disse er innenfor, så er det spennende å faktisk få testet prototypen på en som er fargeblind. Det at han også forstår hva fargene var ment å indikere veldig fort, var også en fin indikasjon på at denne faktisk også er forståelig for personer med nedsatt fargesyn.

Refleksjon etter brukertestene:

Gjennom disse brukertestene har vi blant annet funnet ut at vi trenger noe sterkere nyanser av fargene på lab oversikt kartet. Dette så brukeren forhåpentligvis forstår fargekodingen lettere. Vi fikk også testet kontrastene på fargene mot en med rød / grønn fargeblindhet noe som bekreftet at kontrastnivået var godt nok. I tillegg, som nevnt tidligere, fikk vi kommentar om at dagene burde være sveipbare. Dette har vi også sett at har vært et ønske hos andre brukere under tidligere brukertester.

Slutten av uken:

Denne uken har vi gjennomført en mini felt observasjon, andre runde av den digitale brukertesten og fått tilbakemelding på nødvendige endringer. Brukertestene tok opp mer tid enn forventet og vi rakk dermed ikke å gjennomføre endringene denne uken, men dette vil da være det første vi gjør neste uke.

Uke 16 | Endringer etter brukertest nr. 2

---

Forrige uke gikk vi gjennom det som vil være den siste iterasjonen vi rekker under dette prosjektet. Denne uken vil vi nevne endringene vi ville implementert ved videre arbeid, men som vi ikke har kommet til enda/ikke har nok kunnskap om for å gjøre i Figma. Vi har i tillegg hatt en veiledning med faglærer denne uken for å få tilbakemelding på prosjektet.

Veiledning med faglærer

Veiledningen med faglærer var noe vi etterspurte for å få mer utfyllende tilbakemeldinger på den delen av prosjektet vi hadde delt med han. Siden vi jobber i disk og å legge over arbeidet i RC tar mye tid, rakk vi dessverre ikke få inn alt vi hadde gjort så langt før vi sendte den. Derimot fikk vi gode tilbakemeldinger på det som lå der og en del vi måtte tenke på ved videre arbied. Noen elementer vi tok med oss videre var å unngå å skrive som en dagbok, bruke flere kilder underveis og nødvendigheten med en hovedskjerm.

Begrunnelse for hovedskjerm

Etter veiledningen med faglærer satte vi oss ned for å diskutere nettopp dette med en hovedskjerm. Vi diskuterte en stund, med både for og mot argumenter og endte med at vi skulle beholde skjermen. Grunnlaget for beslutningen vår var at vi ikke følte vi hadde fått testet/observert nok til å kunne forkaste ideen. Vi viste heller ikke om en mer estetsik fin skjerm ville bli tatt mer i bruk basert på " the aesthetic-usability effect". ^[16:1] I tillegg har vi en oppdragsgiver som ytret ønske om denne skjermen fra dag en, vi fikk frie tøyler, men vi ville ha trengt mer tid på å diskutere disse eventuelle endringene med han før vi kunne gjøre en så drastisk endring. Under tidlig brukertesting og observasjon kom det frem at de fleste ikke la merke til skjermen/ikke viste at det var en skjerm der, men støresteparten mente fortsatt at det var en god ide å ha den tilgjengelig.

Plassering av hovedskjerm

Vi har vært innom tanken om at plasseringen til skjermen muligens hadde en påvirkning på hvor mange som la merke til den. Dermed har vi også sett på andre mulige løsninger for hvor skjermen kunne vært plassert, men all resoneringen rundt dette førte oss tilbake til samme plassering som den allerede har.

Vi vurderte å sette den rett utenfor døren, men da vil man verken ha oversikt over rommet foran seg mens man ser på kartet på skjermen, samtidig som at skjermen ikke kan være plassert foran døren siden dette er en nødutgang. Dermed måtte skjermen isåfall stått mye lengre ut i gangen, noe som igjen kunne ført til at folk ikke dro koblingen mellom skjermen og laben.

Andre tanke var å ha skjermen hengende ned fra taket. Dette var også en mulighet oppdragsgiver ytret ved første møte. Ulempen med å ha den oppe i taket er at teksten fort må skaleres veldig mye opp for at den skal være leselig og med tanke på at vi hadde med QR kode så vil denne være vanskelig å scanne i høyden.

Tredje forslag til plassering var ved antibac og munnbind bordet siden folk uansett må innom dette når de kommer inn. Ulempen med å ha den plassert her er at du ikke kan sette den bak bordet fordi skjermen er såpass lav og dette er et område rett innenfor døren som det fort kan bli trangt hvis folk oppholder seg litt lengre for å se på skjermen. Dermed endte vi opp med at plasseringen den allerede hadde, var den beste plasseringen for skjermen.

Det er også viktig å merke seg at kablene må tilrettelegges der skjermen skal stå grunnet HMS. Ved å la skjermen stå på plasseringen den allerede hadde så var også kablene tilrettelagt så de ikke kom i veien for forbipasserende folk eller maskiner.

Videre arbeid basert på siste brukertest

Endringene som måtte gjøres basert på siste brukertest ble gjort kontinuerlig gjennom brukertesten. Dette er ikke den optimale måten å gjøre det på, men det viste gode resultater for de neste brukerne. Vi har samlet opp litt innsikt som vi ville tatt med oss ved videre arbeid/implementering av prototypen.

• Tilrettelegge så brukeren kan både sveipe og trykke seg mellom dagene.
• Brukerteste finn veien funksjonen yttligere og funnet ut hvor nødvendig denne funksjonen faktisk er.
• Laget en gif/animasjon relevant for IVB laben og lagt til istedenfor DNA stripen
• Brukertestet fargekodingen på kartet mer og sett om det fantes en bedre mer forståelig måte for brukeren å oppfatte trafikklys funksjonen med ledig/opptatt.
• Justeringer på størrelsen på noen av knappene i mobilversjonen
• Endret farger og fonter brukt til NTNU sine farger i grafisk profil.

Farger, bilde og typografi

Vi har valgt å bruke lyseblå som hovedfarge på mobilversjonen og en mørk blågrønn farge på bakgrunnen til bookingkalenderen. Grunnen til at vi valgte disse var at blå er hovedfargen til NTNU. Samtidig ville vi gjøre justeringer slik at vi ikke brukte akkurat samme farge som hovedfargen til NTNU. Dette var for å skape en slags under-identitet for IVB-laben, men samtidig ha fokus på blå som kjennetegner NTNU. Ved å bruke andre blå-varianter kan det også tenkes at det skaper mer oppmerksomhet, ettersom hovedfargen til NTNU brukes veldig mange steder ellers rundt om på skolen. Dessverre gikk det litt i glemmeboken at NTNU har sin egen grafiske profil både når det gjelder farger og font. Dette ble vi oppmerksomme på helt i slutten av prosessen, og derfor hadde vi ikke nok tid til å gjøre de endringene for å matche den grafiske profilen til NTNU. ^[24] Men sett fra en annen side gir de fargene og fontene sitt eget preg på designet for IVB-laben, samtidig som man får assosiasjoner til NTNU.

Når det kommer til typografi har vi brukt “Montserrat” på de fleste elementene. Vi mener at denne gir god lesbarhet, samtidig som den er estetisk appellerende. Vi har også brukt fonten “Abel” på mindre detaljer for å skape et litt mer spennende uttrykk. Begge disse fontene har ingen seriffer, noe som gir god lesbarhet på skjerm. ^[25] I tillegg skaper det ikke for mye visuelt stimuli ved at det gir et rent uttrykk.

På mobilversjonen valgte vi å ha et bilde av elementer som er 3D-printet. Dette er for å skape en assosiasjon til 3D-print laben som er en del av IVB-laben. Bildet gjør også designet mer estetisk, samtidig som det har en funksjon med å vise elementer fra IVB-laben, og derfor skaper det en sammenheng.

Slutten av uken

Denne uken har vi jobbet sett over endringene som burde ha vært implementert, men som vi ikke har hatt kapsistet til å gjennomføre. Vi har også begrunnet valg av farger og font bruk, og forklart hvorfor vi ville endret disse ved videre arbeid. Veiledningen med faglærer tidlig i uken ga oss nok punkter å jobbe med videre i oppgaven og fikk oss til å tenke på prioriteringene i prosjektet igjen. Neste uke skal vi ferdigstille den prototypen vi skal vise frem og oppsummere hvordan prosjektet har gått/har vært å jobbe med.

Uke 17 | Oppsummering og link til prototype

---

Link til Figma prototype

Link til workshop for hovedskjerm:

https://www.figma.com/file/qKZH33FClWDsKNxxoPo8Gy/Hovedskjerm?node-id=0%3A1

Link til workshop for mobilversjon:

https://www.figma.com/file/MuXwh9n7OshatdWpzyxaeY/Mobilversjon?node-id=0%3A1

Link til prototype for hovedskjerm:

https://www.figma.com/proto/qKZH33FClWDsKNxxoPo8Gy/Hovedskjerm?scaling=scale-down&page-id=0%3A1&node-id=1%3A3

Link til prototype for mobilversjon:

https://www.figma.com/proto/MuXwh9n7OshatdWpzyxaeY/Mobilversjon?node-id=4%3A1100&scaling=scale-down&page-id=0%3A1

Spørsmål som skal besvares når prosjektet er ferdig

Har vi laget en enkel og intuitiv løsning for sluttbrukeren?

Basert på tilbakemeldingene vi har fått fra brukerne under de ulike brukertestene gjennom prosjektet så virker brukerne absolutt fornøyd med løsningen. Vi har fått mye kommentarer på at både hovedskjermen og mobilversjonen er enkel og strukturert og at bruker-flytene er enkle å trykke seg gjennom.

Vi har kontinuerlig gjennom prosjektet prøvd å jobbe for en mest mulig enkel og intuitiv løsning for sluttbrukeren. Ved å starte brukertesting og innsamling av innsikt tidlig så har vi latt brukeren styre retningen løsning skulle ta. Vi har gjennom hele prosessen ønsket å ha brukeren i fokus og la dem ta avgjørelsene i situasjoner hvor vi selv var usikker på beste løsning. Også ved å brukerteste på både design studenter og IVB studenter så fikk vi innsikter fra to ulike brukergrupper som begge vil kunne ha utbytte av løsningen i fremtiden. Dermed kan også denne innsikten brukes for implementering av booking oversikt på ID institutt laber i senere tid, til en viss grad.

Er oppdragsgiver tilfreds med løsningen?

Tilbakemelding fra oppdragsgiver, primærperson:

• “Likte designet; Oversiktlig, illustrativt og “enkelt” i den forstand at det ikke ble for mye info og elementer som tar oppmerksomhet. Fin flyt. God tenkt løsning mtp mobil tilpasset innhold. Og flott utgangspunkt for videre utvikling.
• Tror kanskje at det kan bli veldig mye jobb og få til det rent teknisk (selvsagt veldig avhengig av hva som kan hentes ut av data fra bookitlab)
• Vet litt for lite i forhold til hvor skalerbar løsning er i forhold til ulike labers behov mtp på maskiner og utstyr. Noen har veldig mye utstyr og andre har lite. Hvor enkelt er det å vise 20 ulike maskiner samtidig?”

Tilbakemelding fra oppdragsgiver, sekundærperson:

• Virket storfornøyd
• Hadde gjerne brukt oss i andre prosjekter
• Farge og fontbruk skulle helst vært i samråd med NTNU sin grafiske profil
• En relevant gif for laben istedenfor DNA-molekylet

Hva ville vi gjort annerledes om vi hadde gjort det en gang til?

En av de største faktorene vi ville endret på om vi skulle begynt på nytt i dag, hadde vært å legge vekk det store fokuset på det tekniske aspektet fra start. Vi hang oss veldig mye opp i det og det tok mye tid i startfasen. Det beste hadde vært om vi hadde jobbet med den tekniske biten parallelt med brukerinnsikten. På den måten hadde vi fått en bedre fremgang i designprosessen. Men på en annen side satte det tekniske visse begrensninger for hva vi kunne designe og hvilken type skjermløsning vi skulle bruke, var en beslutning som måtte tas før vi kunne sette i gang med videre arbeid.

Vi ville også ha involvert oppdragsgiver i større grad underveis i prosessen. Dette gjelder ulike beslutninger underveis og generell oppdatering til oppdragsgiver om hvordan prosessen gikk. I bunn og grunn kunne vi hatt en tettere kommunikasjon med oppdragsgiver. I tillegg kunne vi også strukturert arbeidet bedre og jobbet mer effektivt enkelte av dagene i møttes. Men likevel anser begge sosial kontakt som ekstra viktig i disse tider og dette er også noe som kan påvirke den generelle skolemotivasjonen.

Hvilket læringsutbytte har vi fått?

Gjennom prosjektet har vi fått enda mer erfaring rundt innsamling av innsikt som en første del av designprosessen. På den måten har vi fått mer kunnskap og erfaring med å sette oss inn i brukernes behov, og ha en empatisk tilnærming til brukerne. I tillegg har vi fått både erfaring og kunnskap rundt det å designe en løsning som er ment å fungere i et spesifikt miljø og kontekst. Dette er noe som kan ha stor innvirkning på hvordan løsningen brukes og oppleves. Det er altså mange faktorer i miljøet som påvirker hvordan brukeren bruker en tjeneste. Vi har fått videre erfaring og kunnskap om viktigheten av å teste tidlig og fort, for å skape en god brukeropplevelse og løsning. I tillegg har vi tilegnet oss kunnskap og erfaring med å ha en ekstern oppdragsgiver, som kan ha andre behov og ønsker, sammenlignet med det som kommer frem av brukerinnsikten. Dette er nok et vanlig dilemma i arbeidslivet, så det å balansere disse, ser vi på som en viktig erfaring å ta med oss videre. Vi har også fått stort læringsutbytte av å måtte sette ulike avgrensninger og rammer for prosjektet selv. Selv om dette til tider har vært overveldende, sitter vi igjen med en god erfaring og kunnskap som vi kan ta med oss videre inn i andre prosjekter. Vi har heller aldri gjort en teknisk research før, og dette har gitt oss ny og verdifull kunnskap som det er viktig som designer å ha, for å lage løsninger som er realistiske.

Hvordan skal løsningen implementeres i senere tid og hvem skal involveres? Hva blir neste steg?

Som tilbakemeldingene fra oppdragsgiver tilsier, så kan det være vanskelig å få implementert alle funksjonene som vi har sett for oss, basert på brukerinnsikten. For å få overført data fra BookitLab og over til det nye grensesnittet som vi har laget, er det også en forutsetning at skolen har lisens på API’et til BookitLab. Dette er derimot noe som vurderes etter hvor mange laber som tar i bruk BookitLab som system. Fremdeles er dette en vurderingssak fra skolens side, så det er et hensyn som ikke vi har full kontroll over. Forhåpentligvis kan vårt arbeid i dette prosjektet belyse viktige aspekter på hvorfor man kan ta i bruk BookitLab på flere laber, og hvordan en slik løsning kan se ut. For å få nærmere innsikt i hva som er realistisk å implementere og hvilke funksjoner som er viktigst, kan man jobbe videre med dette prosjektet i emnet IDG3006 - Web of Things, der vi skal jobbe tverrfaglig med studenter på Webutvikling. I samråd med både webutviklings-studenter og oppdragsgiver, kan man sette tydeligere rammer for hva som kan tas med videre som aktuelle funksjoner i løsningen.

Moralske aspekter

Et moralsk problem med løsningen vår kan være folk som fortsatt ikke har tilgang på/bruker smart teknologi. Disse brukerne vil ikke ha mulighet til å ta i bruk løsningen vi har foreslått. Denne brukergruppen blir stadig mindre og mindre og med tanke på at NTNU har tatt i bruk såpass mange digitale løsninger på andre områder (ref. smittesporing) som ikke tar hensyn til denne gruppen, har vi også valgt å se bort ifra disse brukerne. Hadde løsningen vi lagde vært tilknyttet et området hvor det befant seg mye eldre brukere ville vi nok hatt et høyere fokus på nettopp dette, men med tanke på at brukerne våre hovedsaklig er studenter eller personer tilknyttet universitetet er de fleste allerede tvunget til å bruke digitale medier ellers.

Kilder

---

1. Morstøl, T. W. (2018) Hvorfor er planlegging i prosjekter viktig? Tilgjengelig fra: https://www.prosjektbloggen.no/hvorfor-er-planlegging-i-prosjekter-viktig (Hentet: 27. januar 2021) ↩︎

2. Skyttermoen, T. og Vaagaasar, A. L. (2017) Prosjektveilederen, for deg som vil skape verdi. 1. utg. Oslo: Cappelen Damm Akademisk. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

3. Interaction Design Foundation (2020) How to conduct user observations. Tilgjengelig fra: https://www.interaction-design.org/literature/article/how-to-conduct-user-observations (Hentet: 04. februar 2021) ↩︎ ↩︎

4. Stickdorn, M., Hormess, M. E., Lawrence, A. og Schneider, J. (2018) This is service design methods. 1. utg. California: O’Reilly Media Inc. ↩︎ ↩︎ ↩︎

5. Reindal, H. O. (2018) 5 tips for å lykkes med brukertesting. Tilgjengelig fra: https://www.bouvet.no/bouvet-deler/5-tips-for-a-lykkes-med-brukertesting (Hentet: 11. februar 2021) ↩︎

6. Foss-Pedersen, R. J. (2017) Fem tips til deg som skal gjennomføre brukertester. Tilgjengelig fra: https://www.usit.uio.no/om/organisasjon/bnt/web/ux/blogg/2017/brukertest.html (Hentet: 11. februar 2021) ↩︎

7. Thornton, P. (2019) How to conduct user interviews. Tilgjengelig fra: https://uxdesign.cc/how-to-conduct-user-interviews-fe4b8c34b0b7 (Hentet: 24. februar 2021) ↩︎

8. Tomitsch, M. (2018) Design. Think. Make. Break. Repeat. A handbook of methods. Amsterdam: BIS publishers. ↩︎

9. Bakke, N. W. (2019) Hva er personas og hvordan identifiserer du dem? Tilgjengelig fra: https://www.avidlyagency.com/no/innsikt-inspirasjon/blogg/hva-er-personas (Hentet: 05. mars 2021) ↩︎

10. Wreblowski, L. (2014) Designing for large screen smartphones. Tilgjengelig fra: https://www.lukew.com/ff/entry.asp?1927 (Hentet: 15. mars 2021) ↩︎

11. Geri Coady (2017) Color Accesibility Workflows, A book apart. New York. ↩︎

12. Adams, E. & von Gorp, T. (2012) Design for Emotion. Massachusetts: Morgan Kaufmann. ↩︎

13. Johnson, J. (2013) Designing with the Mind in Mind. 2. utg. Massachusetts: Morgan Kaufmann. ↩︎

14. Rhyne, T.M. (2017) Applying Color Theory to Digital Media and Visualization. CRC Press; 1 edition. ↩︎

15. Interaction design foundation. Usability Testing. Tilgjengelig fra: https://www.interaction-design.org/literature/topics/usability-testing (Hentet: 23. mars 2021) ↩︎ ↩︎

16. Norman, D.A. (2004) Emotional design - Why We Love (or Hate) Everyday Things. New York: Basic Books. ↩︎ ↩︎

17. Nielsen, J. (2010) Mental models. Tilgjengelig fra: https://www.nngroup.com/articles/mental-models/ (Hentet: 25. mars 2021) ↩︎

18. Slette, H. M. S. (2018) Animasjoner som hjelper brukeren. Tilgjengelig fra: https://blogg.bekk.no/animasjoner-som-hjelper-brukeren-9bf930ba9617 (Hentet: 25. mars 2021) ↩︎

19. Chavan, V. (2015) It is never a user’s fault. Tilgjengelig fra: https://medium.com/@davinc/it-is-never-a-user-s-fault-b4800e5c00f2 (Hentet: 25. mars 2021) ↩︎

20. Digdir. Universell utforming av ikt. Tilgjengelig fra: https://www.digdir.no/digitale-felleslosninger/universell-utforming-av-ikt/1499 (Hentet: 24. mars 2021) ↩︎

21. Bowers, M. (2020) The higher ground - the guide to design ethics. Tilgjengelig fra: https://www.toptal.com/designers/design-director/design-ethics (Hentet: 24. mars 2021) ↩︎

22. Foss-Pedersen, R. J. (2017) Fem tips til deg som skal gjennomføre brukertester. Tilgjengelig fra: https://www.usit.uio.no/om/organisasjon/bnt/web/ux/blogg/2017/brukertest.html (Hentet: 14. april 2021) ↩︎

23. Hansen E. (2010) Fargeblindhet - Årsaker, forekomst & typer. Gyldendal Norsk Forlag AS. ↩︎

24. NTNU. Farger i grafisk profil. Tilgjengelig fra: https://innsida.ntnu.no/wiki/-/wiki/Norsk/Farger+i+grafisk+profil (Hentet: 14. april 2021) ↩︎

25. Lupton, E. (2014). On web typography. New York: A Book Apart. ↩︎