Hei! Mitt navn er Maria.
Hi! My name is Maria.
Som UX-designer vektlegger jeg prosess: innsikt → problemforståelse → konsept → prototyping → testing → læring. Her er utvalgte case-studier som forklarer hvorfor beslutningene ble tatt, ikke bare hva som ble bygget.
As a UX designer I emphasize process: research → problem framing → concept → prototyping → testing → learning. These case studies highlight why decisions were made, not just what was built.
Skybound – Planleggingsapp for rakettoppskytning
IN2000 – vår 2025
Jeg var UX-ansvarlig i et tverrfaglig team på seks. Startet med kravspesifikasjon fra PortalSpace, men trengte raskt mer innsikt i faktisk brukskontekst og behov. Gjennom intervju, workshops og iterativ prototyping landet vi på en løsning som gjorde det raskere og tryggere å finne riktig oppskytningstidspunkt for en rakett.
Kravspesifikasjon → behov for ekte innsikt
Prosjektet startet med en predefinert kravspesifikasjon definert av PortalSpace
Jeg gjorde: Gikk gjennom predefinert kravspesifikasjon og skilte antakelser fra oppgaver.
Hvorfor: Unngå å designe for hypotetiske behov.
Hva jeg lærte: Krav beskriver ofte løsninger, ikke problemer – avklar behov tidlig.
Semistrukturert intervju
Jeg gjorde: Semistrukturert intervju med engasjert deltaker fra PortalSpace som ble vår hovedbruker.
Hvorfor: For å forstå brukskontekst, behov og faktiske mål.
Hva jeg lærte: En tilgjengelig hovedbruker gir kontinuerlig validering. Kravspesifikasjon gir mye innsikt, men et supplerende intervju gir bedre forståelse for faktisk bruk.
Syntese + Crazy-8
Jeg gjorde: Kodet funn, delte innsikt og fasiliterte Crazy-8 workshop innad i teamet for felles forståelse.
Hvorfor: Raskt utforske IA, navigasjon og flows sammen.
Hva jeg lærte: Felles skissing skaper eierskap og enighet.
Figma prototype v1
Jeg gjorde: Oversatte papirskisser til en klikkbar mobilprototype i Figma og presenterte for teamet.
Hvorfor: Visualisere skjermtilstander tidlig for å avdekke hull i flyt og ordlyd før brukertest.
Hva jeg lærte: Selv en enkel, klikkbar prototyp avslører antakelser raskt – den ga oss diskusjoner om navigasjon og begreper.
Workshop: papir + prototype
Jeg gjorde: Lot brukeren teste, skissere og kommentere på utskrifter og i prototypen.
Hvorfor: Lav- og høy-fi sammen gir ærlige tilbakemeldinger på begrep og flyt.
Hva jeg lærte: Navigasjonen ble bedre når brukeren “tegnet over”.
Interaktiv Figma-flow
Jeg gjorde: Oppdaterte prototypen med realistiske overganger/tilstander.
Hvorfor: Mer rettferdig test av grensesnitt, brukervennlighet og oppgaveløsing.
Hva jeg lærte: Å teste å navigere i appen viser om navigasjon fungerer som tiltenkt.
Komponenter: I første Figma-prototype (v1) glemte vi å bruke Material 3. Etter workshoppen oppdaterte vi prototypen til Material 3-komponenter slik at utviklerne kunne gjenbruke de samme komponentene i implementasjonen.
Hva jeg lærte: Å forankre designet i et etablert designsystem (som Material 3) gjør samarbeidet mellom design og utvikling smidigere og sikrer at det som designes i Figma faktisk lar seg implementere i praksis.
Geriljatest
Jeg gjorde: Korte oppgaver med folk uten domenekunnskap.
Hvorfor: Testing av intuitivitet og første klikk. Er applikasjonen enkel å navigere for førstegangsbrukere?
Hva jeg lærte: Friske øyne avslører hvor vi må forenkle. Hovedpoenget med appen var å forenkle og gjøre planlegging mer effektivt. Da må navigasjonen være så enkel som mulig, slippe unødvendige trykk.
Tett samarbeid med utviklere
Jeg gjorde: Delte innsikt, vi prioriterte sammen, kvalitetssikret tilstander/feil gjennom hvert steg av prosessen.
Hvorfor: Minimere design-gjeld og kode-rewrites.
Hva jeg lærte: Små avklaringer tidlig sparer store endringer senere. Å involvere hele teamet i hele prosessen gir en felles forståelse for løsningen samt gjensidig læring. Alle var med på alt, jeg kodet programmerte dersom jeg hadde tid til det. Slik fikk jeg også tilhørighet til selve koden.
Systemtest & oppsummering
Jeg gjorde: Da prototyper var ferdig testet, funksjonalitet ble implementert i appen. Lot hovedbruker teste implementert funksjonalitet mot realistiske scenarioer.
Hvorfor: Verifisere at beslutningsstøtten oppleves rask og trygg.
Hva jeg lærte: Grundig designprosess tidlig kan gi mindre endringer i sluttfasen. Ettersom vi hadde jevnlig testet prototyper, kunne vi være relativt sikre på at den tiltenkte designet på appen skulle fungere optimalt i forhold til brukerbehov.
Meditasjonsball – IN1060
Samspill mellom form og funksjon → skjermfri, taktil veileder for pust.
Rolle: Prototyping (Arduino/Neopixel), interaksjonsdesign, research & test. Kontekst: IN1060 (vår 2022) • Målgruppe: unge voksne (20–30) som er nye i meditasjon. Prosjektside (UiO).
Oppstart: «Samspill mellom form og funksjon»
Jeg gjorde: Samlet gruppen og avklarte at temaet var eneste ramme – alt annet måtte vi definere.
Hvorfor: Et felles utgangspunkt før løsning.
Hva jeg lærte (prosess): Tidlig problemformulering, suksesskriterier og en enkel beslutningslogg gjorde prosjektet styrbart.
Brainstorm → fokus: pust
Jeg gjorde: Ledet åpen brainstorming og sorterte stikkord/assosiasjoner.
Hvorfor: Utforske bredt før forpliktelse.
Hva jeg lærte (prosess): En tydelig How might we…? ga en klar retning å konvergere mot senere i prosessen.
Moodboard + domenekartlegging
Jeg gjorde: Lagde moodboard (ro/hav/varme farger) og samlet grunnbegreper om meditasjon/breathwork.
Hvorfor: Et felles visuelt språk og referanseramme.
Hva jeg lærte (prosess): Et lett tilgjengelig referansebibliotek (moodboard + notater) forkortet diskusjoner og reduserte omkamper.
Målgruppe (Double Diamond)
Jeg gjorde: Idémyldring på målgrupper → affinity-diagram → konsolidering.
Hvorfor: Gi konseptet en klar adressat.
Hva jeg lærte (prosess): Å synliggjøre antakelser i et affinity-diagram gjorde konvergeringen raskere og bedre begrunnet.
Brukerinnsikt: pilot → intervju → koding
Jeg gjorde: Kjørte pilotintervju for å teste intervjuguiden → hovedintervjuer → kodet funn.
Hvorfor: Redusere metode-risiko og bygge sporbarhet fra data til beslutning.
Hva jeg lærte (prosess): En kort minipilot sparte tid, og tidlig koding ga tydelig sporbarhet gjennom resten av prosjektet.
Idéworkshop → avstemning
Jeg gjorde: Fasiliterte divergerende skissing og konvergerende avstemning mot kriterier.
Hvorfor: Skape eierskap og tempo i beslutningene.
Hva jeg lærte (prosess): Klare konvergeringskriterier (problempass, gjennomførbarhet, klarhet) gjorde valgene raske og lite kontroversielle. Vi landet på «Omsorgsball», «Romsystem» og «Liten reminder» som retninger.
Look & feel-workshop
Jeg gjorde: Testet farge, tempo, materiale og formstørrelser med målgruppen.
Hvorfor: Validere uttrykk før videre bygging.
Hva jeg lærte (prosess): Å teste én variabel om gangen (f.eks. tempo) ga renere signaler og kortere iterasjoner.
Prototype v1 – pust med lys
Jeg gjorde: Bygget Arduino/Neopixel-prototype med jevn inn–hold–ut og «pustesirkel».
Hvorfor: «Bygg for å tenke» og korte feedbacksløyfer.
Hva jeg lærte (prosess): Riktig fidelitet gjorde det lett å forkaste og bygge nytt uten å miste fart.
Tidsbasert påminnelse
Jeg gjorde: Testet hypotesen: økende lysstyrke jo lenger siden siste økt.
Hvorfor: Etablere vane uten mobilvarsler.
Hva jeg lærte (prosess): Å formulere testbare hypoteser («Vi tror… fordi… vi vet at… når…») forenklet evaluering og neste beslutning.
Brukertest → iterasjoner
Jeg gjorde: Små, hyppige justeringer (tempo, farge, form).
Hvorfor: Unngå store ombygginger sent i løpet.
Hva jeg lærte (prosess): Korte iterasjonssløyfer med «scope freeze» per runde slo sjeldne, store endringer.
Resultat
Jeg gjorde: Leverte en skjermfri, håndholdt kule som visualiserer pust og minner diskret over tid.
Hvorfor: Redusere distraksjon og støtte en jevn, kroppslig rytme.
Hva jeg lærte (prosess): En enkel prosessmal (ramme → divergere → konvergere → prototype → test → beslutning) var gjenbrukbar i nye prosjekter.
Ekko-kamre og demokrati – IN3010
Installasjon som gjør algoritmisk polarisering synlig og følbart.
Vi undersøkte hvordan algoritmisk polarisering kan gjøres synlig og følbart. Jeg hadde ansvar for konsept, interaksjon og etikk. Med gigamapping og speculative design bygget vi en installasjon med feeds, lyd og plakatvegg.
Skybound – Rocket Launch Planner
IN2000 – Spring 2025
I was the UX lead in a cross-functional team of six. We started from a client spec (PortalSpace) but quickly needed deeper insight into real context and needs. Through interviews, workshops and iterative prototyping we arrived at a solution that made it faster and safer to find an optimal launch window.
Specification → need for real insight
The project began with a predefined specification from PortalSpace.
What I did: Reviewed the spec and separated assumptions from tasks.
Why: Avoid designing for hypothetical needs.
What I learned: Specs often describe solutions, not problems – clarify needs early.
Semi-structured interview
What I did: Interviewed an engaged PortalSpace participant who became our primary user.
Why: Understand context, needs and goals.
What I learned: An accessible primary user enables continuous validation; the spec is useful, but interviews deepen real understanding.
Synthesis + Crazy-8
What I did: Coded findings, shared insights and facilitated a Crazy-8 session for shared understanding.
Why: Quickly explore IA, navigation and flows together.
What I learned: Sketching together builds ownership and alignment.
Figma prototype v1
What I did: Turned paper sketches into a clickable mobile prototype and presented it to the team.
Why: Visualize early to uncover gaps in flows and wording before usability testing.
What I learned: Even a simple clickable prototype quickly exposes assumptions – great for discussing navigation and concepts.
Workshop: paper + prototype
What I did: Let the user test, sketch and annotate on printouts and in the prototype.
Why: Low- and high-fi together trigger honest feedback on terms and flows.
What I learned: Navigation improved when the user “drew over” screens.
Interactive Figma flow
What I did: Updated the prototype with realistic transitions/states.
Why: Fairer test of interface, usability and task success.
What I learned: Testing navigation shows whether the structure works as intended.
Design system: We forgot to apply Material 3 in the first prototype. After the workshop we updated the prototype to use Material 3 components so developers could implement the same components one-to-one.
What I learned: Grounding the UI in a design system (Material 3) tightens the designer–developer collaboration and ensures what you design in Figma is feasible and maps cleanly to code.
Guerrilla test
What I did: Short tasks with people without domain knowledge.
Why: Validate intuitiveness and first-click. Is the app easy to navigate for first-time users?
What I learned: Fresh eyes reveal where to simplify; navigation must be minimal to speed planning.
Close collaboration with developers
What I did: Shared insights, co-prioritized, and quality-checked states/errors throughout the process.
Why: Minimize design debt and code rewrites.
What I learned: Early clarifications prevent big changes later; involving the whole team builds shared understanding.
System test & wrap-up
What I did: When prototypes were validated, functionality was implemented and tested by the primary user on realistic scenarios.
Why: Verify that the decision support feels fast and safe.
What I learned: Thorough early process reduced late changes; iterative testing increased confidence in fit.
Meditation Ball – IN1060
Screen-free, tactile breathing aid – light as a metronome, gentle haptics.
Role: Prototyping (Arduino/LED), interaction design, user testing. Context: IN1060 (Spring 2022) • Target: young adults new to meditation. Project page (UiO).
- Problem: People want a calm breathing habit but get distracted by screens/notifications.
- Approach: Screen-free object guiding inhale–hold–exhale through light; touch sensor to start/stop.
- My deliverables: Light logic, Neopixel prototypes, time-since-last-session reminder, testing and iterations.
Ekko-kamre og demokrati – IN3010
Installasjon som gjør algoritmisk polarisering synlig og følbart.
Team: Smilla Stadshaug, Miski Ali, Maria Andersen
Mål: Skape en transformativ utstilling som ikke “løser” noe, men øker bevissthet og refleksjon om hvordan algoritmer snevrer inn verdensbildet.
Målgruppe: Unge voksne/studenter som bruker sosiale medier mye.
Ramme & motivasjon
Hvorfor: Sterke reaksjoner på serien Adolescence trigget oss til å utforske hvordan plattformer kan bli grobunn for radikalisering og polarisering.
Transformativt fokus: Irwin mfl. – Transition/Transformative Design: designe for bevisstgjøring og refleksjon fremfor løsning.
Konseptutvikling
Metoder: Gigamapping, “New Metaphors”, idéworkshops.
Retning: To ideologiske ekko-kamre i fysisk rom (tematikk: toxic masculinity / toxic femininity) med nøytral intro og refleksjon til slutt.
Bevisst valg: Droppet “escape room” og fiktive ekko-kamre til fordel for realistisk, emosjonell gjenkjenning.
Prototype
Artefakter: Autoplay TikTok-feeds (kuratert), meningssterk AI-chatbot, plakatvegger, lyssetting og rominndeling.
Intensjon: Gjøre “mørk materie” i infrastruktur synlig (algoritmisk sortering som normalt er usynlig) ved å føle det i et fysisk rom.
Evaluering – runde 1
Oppsett: Én “toxic masculinity”-sone, TikTok-liste + opinionated AI.
Funn: For lyst rom og manglende plakat/lys ga lavere emosjonell intensitet. Deltakere ble usikre på hensikten → behov for bedre rammesetting.
Evaluering – runde 2
Oppsett: To rom: introduksjon (Mentimeter før/etter) + hovedrom med plakater, autoplay-feed og opinionated AI.
Resultat: Gruppe 2 hadde tydelig engasjement og dype samtaler etterpå (algoritmisk bias, polarisering, nettatferd). Formatet ga ønsket refleksjon.
Sluttvisning
Tiltak: Rødt lys, flere plakater, begge feeds etter hverandre for å tydeliggjøre kontrast. Tidsknapphet → ingen Mentimeter, men spontan diskusjon oppsto.
Konklusjon: Opplevdes slagkraftig og i tråd med målet om bevisstgjøring.
Etikk & læring
Balansen: Skape sterk følelse uten å manipulere; likeverdig framstilling av perspektiver; rom for debrief.
Hva vi lærte: Atmosfære og rammesetting er avgjørende; design som demokratisk spørsmål fremfor svar; prototyping ga innsikt gjennom doing.
Videre: Mer tid over tid (longitudinelt), flere plattform-miljøer, modulær vandreutstilling, dypere AI-dialog, større studier.