MSc Informatikk:
design, bruk og interaksjon
Universitetet i Oslo
Prosjekter
UX / UI DESIGN
•
CLIENT PROJECT
•
SOLO
•
2026
Tanum Ridesenter,
Ny nettside
Fornye nettsiden for å få bedre oversikt og enklere navigasjon
Problem / kontekst
Viktig informasjon var vanskelig å finne på en uoversiktlig nettside.
Den eksisterende nettsiden inneholdt mye informasjon, men den var uoversiktlig og utdatert. Målet mitt var derfor å gjøre det enklere for potensielle kunder å forstå hva Tanum Ridesenter tilbyr og finne informasjonen de trenger.
Min rolle
Dette var et selvstendig kundeprosjekt hvor jeg hadde ansvar for hele prosessen: research, informasjonsarkitektur, UX/UI-design, prototyping, brukertesting og utvikling i HTML, CSS og JavaScript.
Designprosess
- 01For å forstå både virksomhetens mål og brukernes behov intervjuet jeg først klienten ved Tanum Ridesenter. Samtalen ga innsikt i hvilken informasjon ridesenteret ønsket å formidle, hva de opplevde som utfordrende med den eksisterende nettsiden, og hva den nye løsningen skulle prioritere.
Deretter gjennomførte jeg semistrukturerte intervjuer med brukere av nettsiden. Dette ga meg et perspektiv på hva de faktisk lette etter når de besøkte nettsiden, hvilken informasjon de opplevde som viktigst, og hvor de hadde problemer med å finne frem. Ved å sammenholde klientens mål med brukernes behov kunne jeg identifisere hva den nye nettsiden faktisk burde prioritere. - 02Jeg observerte deretter brukere mens de forsøkte å finne viktig informasjon på den eksisterende nettsiden. Flere brukte unødvendig lang tid på å finne frem, noe som bekreftet at problemet var mangelen på struktur, informasjonen lå der.
Ut ifra funnene etter intervju lagde jeg en prototype i Figma hvor jeg reduserte jeg tekstmengden, prioriterte innholdet brukerne faktisk etterspurte, lot bilder få en større rolle. Bilder av stallen, fasilitetene og området var viktigere enn lange beskrivelser. Informasjon om undervisning og hvordan hestene blir ivaretatt var også viktig. - 03Jeg lagde deretter en interaktiv prototype i Figma og testet navigasjon og innholdsstruktur før jeg begynte utviklingen. Det gjorde at jeg kunne oppdage og justere uklarheter mens endringene fortsatt var raske og enkle å gjøre. Figma prototypen ble testet på nytt med oppgaver tilsvarende dem jeg hadde brukt på den gamle nettsiden. Brukerne fant frem til sentral informasjon raskere og med mindre leting.
Utfordring
Å finne ut av hva som kunne fjernes uten at kunden opplevde at viktig informasjon gikk tapt. I tillegg var det litt vanskelig å balansere brukernes behov med klientens ønsker. I intervjuene kom det blant annet frem at brukerne ønsket tydelig prisinformasjon på nettsiden, mens klienten ikke ønsket å publisere priser. Jeg måtte derfor prioritere innhold som svarte på brukernes behov og samtidig samsvarte med klientens ønsker.
Hva jeg lærte
Prosjektet lærte meg hvor stor forskjell prioritering av informasjon kan gjøre. Jeg lærte også verdien av å teste en eksisterende løsning før jeg begynner å redesigne den. Det ga meg et konkret sammenligningsgrunnlag og gjorde det lettere å begrunne designvalgene mine overfor kunden.
UX / UI DESIGN
•
TEAMPROSJEKT
•
2025
School Inspection (DHIS2)
Et verktøy for å prioritere skolebesøk og gjøre tidligere inspeksjonsdata enklere å bruke.
Problem / kontekst
Skoleinspektører trengte bedre støtte til å prioritere hvor oppfølging var mest kritisk.
Skoleinspektører måtte kunne få oversikt over hvilke skoler som burde prioriteres for oppfølging, samtidig som de hadde behov for å se tidligere inspeksjoner og relevant skoledata på en forståelig måte. Arbeidet kunne også foregå i områder med ustabil eller manglende internettilgang, noe som stilte krav til hvordan løsningen måtte fungere i praksis.
Min rolle
Research, UX/UI-design, wireframing og interaktiv prototyping i Figma, brukertesting og front-end i React/DHIS2.
Utfordringer
Vi hadde ingen «ordentlige» brukere fra målgruppen tilgjengelig i prosjektet. Personasene er derfor antakelsesbaserte og ble utviklet fra prosjektbeskrivelsen vi fikk utdelt, ikke fra intervjuer med skoleinspektører. Testene med venner og medstudenter ga nyttig innsikt i forståelighet, navigasjon og visuell tydelighet, men kunne ikke validere den reelle arbeidshverdagen eller behovene til målgruppen.
En sentral utfordring var å unngå information overload. Løsningen inneholdt store mengder tall og inspeksjonsdata, og dersom alt ble vist samtidig, ble det vanskelig å forstå hva som var viktigst. Vi måtte derfor prioritere informasjonen vi mente inspektørene trengte først, og presentere den gjennom tydelige statusnivåer. Mer detaljert informasjon ble gjort tilgjengelig ved å klikke seg videre.
Hva jeg lærte
Prosjektet lærte meg hvor viktig det er å bruke tid på å forstå datagrunnlaget før man begynner å designe. I DHIS2 var det store mengder data som potensielt kunne være relevant, og en viktig del av designarbeidet ble derfor å vurdere hva brukeren faktisk trenger å se – og hva som kan skjules eller nedprioriteres.
Resultat
En DHIS2-app som samler planlegging, prioritering, inspeksjonshistorikk og rapportering i én arbeidsflyt. Tydelige statusnivåer gjør det raskere å forstå hvilke skoler som trenger oppfølging og hvorfor. Offline-funksjonen gjør det mulig å fortsette arbeidet og redusere risikoen for tap av data når nettforbindelsen er ustabil.
Designprosess
- 01Vi ikke hadde tilgang til faktiske skoleinspektører i prosjektet, derfor måtte vi bygge den første brukerforståelsen på prosjektbeskrivelsen og utviklet personas basert på dette. Personasene representerte ulik erfaring og digital kompetanse og hjalp oss med å prioritere behovene vi måtte undersøke videre. Gjennom personasene identifiserte vi noen antatte brukerbehov vi mente var sentrale for skoleinspektørene.
- 02Deretter jobbet vi tett i teamet, for å forstå hvilke data som faktisk var tilgjengelige i DHIS2, og hvordan disse kunne brukes i løsningen. Siden vi ikke hadde tilgang til faktiske skoleinspektører, var det utfordrende å vite hvilken informasjon som var mest relevant i deres arbeidshverdag. Vi måtte derfor bruke tid på å utforske datagrunnlaget, diskutere antakelsene våre og prioritere hvilken informasjon som vi tenkte ville vært mest nyttig for brukeren. Deretter laget vi wireframes og en første MVP i Figma.
- 03Vi videreutviklet prototypen i Figma og lagde en interaktiv prototype som vi kunne teste før vi utviklet den. Siden vi ikke hadde tilgang til skoleinspektører gjennomførte vi testing med medstudenter og venner. Testingen kunne ikke fortelle oss om løsningen passet skoleinspektørenes faktiske arbeidshverdag, men den kunne avdekke grunnleggende problemer med forståelighet og brukervennlighet. Denne testen viste blant annet at grensesnittet inneholdt for mye informasjon samtidig, at det ikke var tydelig hvilke rader som kunne klikkes på og at sortering av kolonner var vanskelig å oppdage.
- 04Etter testingen gjennomførte vi en workshop med hele teamet for å igjen se på hvordan vi kan presentere dataen på en mer oversiktlig måte. Vi endte opp med å gå tilbake til likheter ved den første prototypen. Vi reduserte mengden informasjon som ble vist samtidig, erstattet abstrakte tall med statusene god, advarsel og kritisk, kombinert med farger og ikoner. Vi gjennomførte en ny test, og denne viste tydeligere forståelse og navigering.
PARTICIPATORY DESIGN
•
Team prosjekt
•
2025
Deltakende Design
Utforsking av hvordan masterstudenter kan jobbe mer effektivt og opprettholde motivasjon gjennom deltakende design.
Problem
Prosjektet måtte være deltakende design og vi startet med et bredt spørsmål: Hvordan kan masterstudenter jobbe mer effektivt og samtidig opprettholde motivasjonen?
Målet var at studentene selv skulle være med på å forme både problemområdet og konseptet. Problemdefinisjonen utviklet seg derfor gjennom workshops etter hvert som deltakerne delte erfaringer og utviklet ideer sammen med oss.
Min rolle
Jeg var UX-designer og fasilitator i et team på tre. Jeg bidro til å planlegge og gjennomføre workshopene, analysere innsikt og ferdigstille prototypen. Rollen handlet om å gi struktur og støtte uten å styre deltakerne mot løsninger vi allerede hadde bestemt.
Designprosess
- 01Workshop 1: KartleggingJeg var med på å planlegge og fasilitere workshopene, med mål om å gi deltakerne gradvis mer eierskap til både problemforståelsen og løsningene. Vi startet derfor med mindmaps for å utforske utfordringene deres. Deltakerne beskrev en vanlig studiedag, reflekterte individuelt og kartla vaner med post-its. Sammen sorterte vi erfaringene og fant mønstre, utfordringer og lite effektive rutiner.
- 02Workshop 2: IdéutviklingFor å gjøre idégenereringen tilgjengelig også for deltakere uten designerfaring, brukte vi mindmaps og Crazy 4s. Deltakerne utviklet og bygget videre på hverandres ideer før de stemte frem tre retninger. Basert på relevans for problemene fra første workshop valgte vi sammen å gå videre med motivasjonsapp og felles pauser.
- 03Workshop 3: PrototypingDeltakerne jobbet i to grupper og videreutviklet konseptene gjennom skisser og low-fidelity prototyper. Gruppene presenterte løsningene for hverandre og brukte tilbakemeldingene til å igjen videreutvikle ideene. Dette dannet grunnlaget for videre prototyping i Figma og med AI.
- 04På grunn av begrenset tid og utfordringer med å samle deltakerne igjen, ferdigstilte vi den siste løsningen uten dem. Min rolle gikk dermed fra fasilitator til en mer tradisjonell designerrolle. Jeg forsøkte å bevare behovene og designbeslutningene fra workshopene, fremfor å introdusere nye retninger basert på egne preferanser. I en ideell deltakende designprosess ville også denne delen blitt utviklet og evaluert sammen med deltakerne.
Utfordringer
For meg som designer var det også utfordrende å gi slipp på kontrollen over designet. Jeg er vant til å forme og videreutvikle løsninger selv, mens rollen min her i større grad var å legge til rette for andres ideer. Jeg måtte derfor finne en balanse mellom å bidra med designkompetansen min og å unngå at mine egne preferanser styrte resultatet.
Flere av deltakerne hadde ingen tidligere erfaring med designmetoder, noe som gjorde fasiliteringen til en viktig del av prosessen. En utfordring var derfor å utforme aktiviteter og gi nok veiledning til at alle kunne delta aktivt i designarbeidet, uten at vi som designere styrte ideene deres.
Det var vanskelig å opprettholde den samme deltakelsen gjennom hele prosjektet, og flere deltok bare i én workshop. Den korte tidsrammen begrenset også hvor mange aktiviteter og iterasjoner vi kunne gjennomføre. Dette kan ha påvirket deltakernes mulighet til å ha en tydelig stemme i alle beslutningene.
Hva jeg lærte
I flere av de andre prosjektene mine har brukerne først og fremst bidratt gjennom intervju og evaluering av løsninger vi som designere har laget. I deltakende design ble skillet mellom designer og bruker mindre tydelig. Deltakerne var også med på å definere problemet og skape ideene. Jeg lærte at fasilitering i deltakende design handler om å finne en balanse mellom struktur og åpenhet. Deltakerne måtte få nok støtte til å kunne uttrykke ideene sine gjennom designaktiviteter, samtidig som vi måtte være forsiktige med å ikke påvirke hvilke løsninger de utviklet.
Resultat
Prosessen resulterte i et konsept for en motivasjonsapp bygget på deltakernes egne behov, valg og prototyper. Løsningen kombinerer personlige mål og visuell fremgang med felles pauser og sosial støtte, og ble ferdigstilt som en high-fidelity prototype i Figma.
TANGIBLE INTERACTION
•
TEAMPROSJEKT
•
2026
Sustained by Voices
En interaktiv installasjon som holdes «i live» av publikums stemmer.
Konsept
En skjør skikkelse som bare holdes «i live» så lenge publikum snakker til den.
Sustained by Voices er en interaktiv installasjon der en skjør, menneskelignende skikkelse bare holdes «i live» så lenge publikum lager lyd. Når rommet blir stille, synker skikkelsen sammen.
Installasjonen ble utviklet for en utstillingssituasjon, der publikum skulle påvirke det gjennom sin egen tilstedeværelse. Møtet mellom mennesket, rommet og installasjonen ble en sentral del av designet.
Designprosess
- 01Den første uken jobbet vi i et team på fem med en åpen utforskning av temaet puls. Vi brukte idémyldring, skisser og enkle fysiske prototyper for å undersøke ulike tolkninger av begrepet. I stedet for å bestemme løsningen tidlig ønsket vi å utforske hvordan puls kunne uttrykkes gjennom fysisk form og interaksjon. Flere ganger i uken presenterte vi arbeidet vårt for de andre teamene og fikk tilbakemeldinger gjennom designkritikk. Dette ga oss jevnlig nye perspektiver på ideene våre og hjalp oss med å vurdere valgene vi hadde tenkt.
- 02Gjennom idéutviklingen ble vi interessert i ideen om en skjør skikkelse som var avhengig av menneskene rundt seg for å opprettholdes. Publikum skulle få en aktiv rolle hvor stemmen deres skulle holde skikkelsen levende.
Vi utviklet konseptet gjennom flere fysiske prototyper og eksperimenterte med materiale, form og bevegelse. Samtidig utviklet vi den tekniske interaksjonen, der en mikrofon registrerte lydnivået i rommet og en motor styrte skikkelsens bevegelse.
En stor del av arbeidet handlet om å få den tekniske responsen og det fysiske uttrykket til å oppleves som én sammenhengende interaksjon. Små endringer i materialet, motorens bevegelse eller mikrofonens følsomhet påvirket hvordan skikkelsen ble oppfattet. - 03Gjennom testing og designkritikk undersøkte vi om publikum forstod sammenhengen mellom egen stemme og skikkelsens bevegelse. Vi hadde flere ideer til funksjoner og uttrykk underveis, men erfarte at flere elementer også gjorde interaksjonen vanskeligere å forstå.
Hva jeg lærte
Prosjektet lærte meg hvor mye iterasjon fysisk interaksjonsdesign krever. Små endringer i materiale, bevegelse, lyd eller teknologi kunne påvirke hele opplevelsen.
Jeg lærte også verdien av å begrense et konsept. Vi hadde mange ideer til hva installasjonen kunne gjøre, men oppdaget at jo mer vi la til, desto mindre tydelig ble forholdet mellom publikums stemme og skikkelsens liv.
Utfordringer
Vi opplevde også at det var lett å gjøre konseptet for komplekst. Underveis hadde vi mange ideer til funksjoner og interaksjoner vi kunne legge til, men jo mer vi inkluderte, desto mindre tydelig ble sammenhengen mellom publikums stemme og skikkelsens «liv». Det ble viktig å begrense løsningen og la den enkle interaksjonen stå i sentrum.
I tillegg var teknologien en utfordring. Vi ønsket at bevegelsen skulle oppleves så levende som mulig, samtidig som den måtte fungere pålitelig i en utstillingssituasjon. Det krevde en del eksperimentering for å finne balansen mellom det teknisk gjennomførbare og uttrykket vi ønsket.
UX / UI DESIGN
•
TEAMPROSJEKT
•
2024
LiftOff
App for å vurdere værforhold ved rakettoppskytning — i samarbeid med Portal Space
Problem
Portal Space måtte forholde seg til flere typer værdata for å vurdere om forholdene var trygge nok for en rakettoppskytning. Informasjonen var spredt, og de manglet en løsning som kunne gi dem et raskt beslutningsgrunnlag.
Min rolle i teamet
Jeg jobbet som designer og front-end-utvikler i et tverrfaglig team på seks, med studenter fra design, robotikk, programmering og språkteknologi. Jeg arbeidet med intervju, kravprioritering, workshops, prototyping i Figma, brukertesting og implementering av brukergrensesnittet i Kotlin og Jetpack Compose.
Designprosess
- 01Vi startet med et semistrukturert intervju med en representant fra Portal Space for å forstå oppskytningsprosessen, nødvendige værparametere og behovet for egendefinerte grenseverdier. Dette var et fagområde jeg ikke kjente fra før, med mye kompleks data, så det var viktig å bruke tid å sette meg inn i det.
- 02Vi gjennomførte en workshop med hele teamet for å få en oversikt over viktige data, skissere og prioritere funksjoner til en tidlig prototype. Vi utforsket ulike måter å gjøre komplekse værdata forståelige uten å skjule informasjon brukerne faktisk trengte. Her var det viktig for oss å få en oversikt over alt som trengtes. På bakgrunn av ideene fra workshopen ble ideene samlet i flere ulike Figma-prototyper. Etter en gjennomgang felles i teamet ble vi enige om hvilken prototype vi ville gå videre med for testing med bruker.
- 03Under testingen innså vi at en kartvisning som vi i utgangspunktet trodde ville være nyttig, viste seg å gi lite nytte og dermed ble den bestemt fjernet. I tillegg innså vi at navigasjonen var vanskelig, og værvariablene var uoversiktlige. Prototypen ble oppdatert på bakgrunn av testingen.
- 04Vi gjennomførte deretter en ny runde med testing. Geriljatesting med informatikkstudenter som hjalp oss med å avdekke generelle brukbarhets-problemer. I tillegg hadde vi brukertesting med fem personer fra Portal Space. Dette ga oss tilbakemeldinger fra den faktiske målgruppen. Vi testet også med en deltaker med rød-grønn fargeblindhet grunnet valget av farger brukt i appen. Gjennom observasjon, konkrete oppgaver og tenke-høyt-metoden identifiserte vi utfordringer med blant annet navigasjon, datoer, tabeller, ikoner og grafer.
Hva jeg lærte
Prosjektet lærte meg hvor viktig det er å forstå et komplekst fagområde før man forsøker å forenkle det gjennom design. Det som virker som unødvendig kompleksitet for meg, kan være kritisk informasjon for brukeren.
Jeg lærte også mye om samarbeid mellom ulike fagområder. Når designere og utviklere jobbet tett gjennom workshops, parprogrammering og løpende diskusjoner, kunne vi avklare både tekniske begrensninger og designvalg tidligere. Samtidig erfarte jeg hvor viktig tydelig arbeidsfordeling og korte, fokuserte møter er i et større tverrfaglig team.
Hvis jeg skulle gjort noe annerledes
Jeg ville startet testingen av den siste versjonen av prototypen tidligere, slik at vi hadde hatt mulighet til en ekstra testrunde. Vi fant flere forbedringsmuligheter mot slutten av prosjektet, og en ekstra iterasjon etter denne testen ville gitt oss mulighet til å undersøke effekten av endringene bedre.
Jeg ville også tatt en mer tydeligere rolle som designer i workshopene. Noen av workshopene ble lange og mistet fokus underveis. I ettertid ville jeg strukturert dem som kortere, mer fokuserte økter med tydeligere mål.
Resultat
LiftOff samler værdata fra flere kilder og gir en tydelig anbefaling: grønt, gult eller rødt lys for oppskytning. Brukeren kan velge lokasjon, finne neste gode oppskytningstidspunkt, undersøke data i tabell eller graf og justere egne grenseverdier og marginer.
