Det opprinnelige bookingsystemet ved Universitetet i Bergen — for rom, utstyr og kurs — var uoversiktlig, visuelt rotete og vanskelig å navigere i. Sammen med to medstudenter tok jeg fatt på å redesigne det fra bunnen av: fra wireframes i Figma til en fungerende iOS-prototype. Det som gjorde prosjektet spesielt var at ingen av oss hadde solid erfaring med koding fra før — så for å komme fra design til en reell, interaktiv app, ble KI-verktøy en sentral del av arbeidsflyten. Prototypen ble til slutt presentert på universitetets Innovation Day.

Fra idé til design

Vi startet med å bruke ChatGPT til å utforske svakhetene ved det eksisterende systemet og samle idéer til forbedringer — alt fra en samlet dashbord-oversikt til smartere varsler og enklere avbestilling. Basert på denne research fikk vi et klart bilde av hvilken retning appen skulle ta: ren, rolig og lett å forstå, i kontrast til det opprinnelige systemet. Denne visuelle og følelsesmessige retningen — det man i bransjen gjerne kaller appens «vibe» — ble bygget opp gjennom wireframes og en delt Figma-fil, der fargevalg, mellomrom og typografi gradvis formet en helhetlig, minimalistisk stil.

Figma-wireframes av Aurora-bookingsystemet: utstyrsoversikt, produktdetaljer og kalender
Figur 1 — Wireframes fra Figma-filen: utstyrsoversikt, produktdetaljer, bookingkalender og profilside for det redesignede systemet.

Fra design til kode

Neste utfordring var å gjøre de statiske Figma-designene om til en fungerende prototype. Vi testet først Builder.io, et verktøy som lovet å konvertere Figma-filer automatisk til kode — men resultatene var strukturelt rotete og visuelt inkonsekvente, og integrasjonen tok lengre tid enn den sparte. Vi la derfor verktøyet til side og gikk i stedet over til Cursor, en KI-drevet kodeeditor, som ga en langt mer stabil og forutsigbar arbeidsflyt: den genererte fungerende kode direkte fra Figma-strukturen, og lot oss se endringer i sanntid. Dette gjorde det mulig å teste og justere raskt — følte et skjermbilde seg for «rotete» ut, kunne vi gå tilbake til Figma, luke bort elementer, og se resultatet i kode på minutter.

Den kritiske feilen: den blanke skjermen

Mot slutten av prosjektet skulle vi konvertere web-prototypen til en frittstående iOS-app i Xcode, slik at den kunne kjøres uavhengig av nettleser under Innovation Day. Cursor genererte Swift-koden som skulle laste inn HTML, CSS og JavaScript i en WKWebView, og alt så ut til å fungere — helt til vi testet appen på en fysisk enhet. Skjermen var da fullstendig blank: ingen brukergrensesnitt, ingen feilmelding, ingen tegn til liv.

Ved hjelp av Xcodes innebygde feilsøkingsverktøy fant jeg ut at HTML-filen faktisk lastet inn korrekt, men at JavaScript-koden som skulle sette i gang React-grensesnittet aldri ble kjørt. Årsaken viste seg å ligge i selve KI-genererte koden: den brukte Swifts contains()-metode til å lete etter et regex-mønster i filnavnet, men contains() sjekker kun etter eksakte tekststrenger — ikke regex. I tillegg inneholdt filnavnene spesialtegn som punktum og bindestrek, som ikke var escaped korrekt for regex-søket. Koden så syntaktisk riktig ut, men var strukturelt feil — den «løy» pent uten å faktisk fungere.

Cursor-skjermbilde som viser KI-ens forklaring på den blanke skjerm-feilen og løsningen
Figur 2 — Cursor forklarer årsaken til den blanke skjermen: feil bruk av contains() i stedet for et regex-søk, samt ikke-escapede spesialtegn i filnavn.

Løsningen var å bytte ut den feilaktige logikken med riktig regex-håndtering (range(of:options:.regularExpression)) og å bruke NSRegularExpression.escapedPattern(for:) for å håndtere spesialtegnene i filnavnene korrekt. Etter denne rettelsen lastet grensesnittet inn umiddelbart og pålitelig — appen fungerte som den skulle, helt offline.

Xcode med den ferdige Aurora-appen kjørende på en iPhone-simulator, med innloggingsskjermen synlig
Figur 3 — Den rettede appen kjører stabilt i Xcode-simulatoren, med Auroras innloggingsskjerm synlig på en iPhone.
KI-generert kode kan se helt plausibel ut og likevel feile fullstendig, stille og uten varsel. Den viktigste lærdommen fra dette prosjektet var derfor ikke hvor mye raskere KI kunne gjøre arbeidet, men hvor avgjørende menneskelig kvalitetskontroll fortsatt er når verktøyene tar feil.

Hva jeg lærte om KI-assistert utvikling

Denne opplevelsen sa noe viktig om hvordan KI faktisk fungerer i praksis. Verktøyene akselererer arbeidet enormt — det som tidligere ville tatt dager, kunne nå gjøres på minutter — men de har ingen egen estetisk dømmekraft, og de garanterer ikke at koden faktisk virker. Det gjorde den menneskelige kvalitetskontrollen enda viktigere: ikke å skrive hver eneste linje kode selv, men å forstå nok til å lese, teste og feilsøke det verktøyene produserte.

Prosjektet endret også hvordan jeg tenker på egen rolle som designer. I stedet for kun å tegne grensesnitt, ble jobben i økende grad å koordinere mellom flere verktøy — velge riktig verktøy til riktig oppgave, formidle designintensjoner tydelig nok til at KI-en kunne tolke dem riktig, og gripe inn når noe gikk galt. Det er en annen type kompetanse enn den jeg lærte på bachelornivå, der verktøyene var enklere og mer forutsigbare, men grensene for hva jeg kunne bygge alene også var tydeligere.

Min rolle

Jeg hadde hovedansvar for grensesnittdesignet i Figma og ledet arbeidet med å omsette dette til kode ved hjelp av KI-verktøy som Cursor, inkludert å spore opp og fikse den kritiske «blanke skjerm»-feilen som gjorde appen ubrukelig på ekte enheter — sammen med to medstudenter som bidro med design og struktur underveis.

Resultat

Den ferdige prototypen fungerte stabilt og pålitelig, og ble presentert på Universitetet i Bergens Innovation Day. Prosjektet viste at kombinasjonen av grundig designarbeid og kritisk, velinformert bruk av KI-verktøy kan gjøre det mulig å bygge en fungerende, profesjonell iOS-prototype — selv uten dyp erfaring med native apputvikling fra før.