Fra idé til prototype på rekordtid: Vårt eksperiment med KI-verktøy
Med bruk av KI, prototypet vi en løsning på 3 dager som for få måneder siden ville tatt oss 1000 timer
av Mari og Helge
Hvor raskt kan man egentlig gå fra idé til brukertestet prototype? Det var spørsmålet vi stilte oss i Pilot helse-teamet. Vi ønsket å se hvordan KI-verktøy kunne endre måten vi jobber på. Tidligere kunne det ta uker å lage en prototype i Figma, med begrensede muligheter for testing. Appfarm gjorde prosessen bedre ved å tillate testing av flere ulike flyter. Men nå, med KI, kan vi lage en fullt funksjonell løsning med “ekte” innhold og teste alle mulige flyter.
UX designer Mari
Utvikler Helge
Vi snakker ikke lenger om å teste utvalgte scenarioer, men om å la brukerne utforske løsningen basert på deres egne opplevelser. Sånn gjorde vi det:
Bakgrunn: Hva jobber vi med?
Vi i Pilot helse-teamet utvikler en digital selvhjelpsløsning som skal støtte innbyggerne ved nyoppstått sykdom og skade. Løsningen skal gi konkrete råd om egenomsorg og veiledning om når man bør kontakte helsetjenester. For de som vil vite mer om prosjektet, kan dere besøke prosjektsiden til Helsehjelppiloten.
Nå står vi foran en ny utfordring: Hvordan skal "inngangen" til tjenesten utformes? Med inngang mener vi det første steget hvor innbyggerne beskriver sine symptomer og plager. Dette er kritisk for brukeropplevelsen og for at tjenesten skal gi relevant hjelp fra første stund.
Dag 1 - Idégenerering og analog prototyping
Dag 1 samlet vi hele teamet til idégenerering. Vi tok utgangspunkt i spørsmålet: "Hvordan kan vi utforme en inngang til tjenesten som gjør det enkelt for innbyggere å beskrive sine symptomer og plager?"
Vi valgte en analog tilnærming med penn og papir, og vekslet mellom individuelt arbeid og gruppearbeid. Denne kombinasjonen sikret både rom for egen refleksjon og kollektiv idéutvikling. Hvis du er nysgjerrig på metoden, kan du lese mer om analog prototyping her.
Etter en produktiv økt satt vi igjen med to lovende konsepter:
Flervalgskonseptet: En inngang med flere måter å oppgi symptomer på - søk, kategorivelger eller interaktivt kroppskart
Fritekst: Et fritekstfelt hvor brukeren beskriver problemet (via tekst eller tale), som så går over til en flyt med spørsmål og svaralternativer
Analog prototype fra idegenerering
Dag 2-3 - Prototyping
Med ideene klare var det på tide å lage prototyper, og her kom KI-verktøyene inn i bildet. Vi valgte forskjellige KI-verktøy, for å teste hvilke som var best egnet til å lage prototyper. Her deler vi våre erfaringer.
Erfaring som utvikler med Bolt.new, Firebase Studio og Claude Code
Som utvikler er det fort gjort å bli nysgjerrig når noen nevner et nytt verktøy i lunsjen. Så da Firebase Studio kom opp som et alternativ vi burde teste, benyttet jeg muligheten. Her får man en egen prototypingsmodus via chat-prompt, og en mer klassisk kode-modus (VsCode) der du kan skrive selv begge bruker GIT for versjonering.
Det hørtes lovende ut, men opplevelsen ble noe treg med lasting mellom moduser, og den satte seg ofte fast. Litt som mange av de generative AI-verktøyene vi ser i dag.
Raskere fremgang med Bolt.new
Ettersom jeg trengte noe som faktisk fungerte til en brukertest bare noen dager senere, hoppet jeg over til Bolt.new - et verktøy jeg har brukt før. Her fikk jeg raskt opp en fungerende versjon med samme start-prompt og kom raskere videre.
Bolt.new gir en mer sømløs overgang fra chat-prompt til kode-modus. I tillegg får du hosting direkte via Stackblitz, sånn at det går kjapt å vise frem noe som faktisk virker (Firebase Studio har også hosting ut av boksen). Et ekstra pluss er stjerneknappen under prompt-feltet, som oversetter en enkel idé til en mer strukturert prompt med techstack og arkitekturoppsett. Dette passer bra for de som ikke koder selv, men ønsker å utforske ideer eller konsepter raskt.
Her må man følge nøye med slik at ikke en endring ødelegger eksisterende funksjonalitet, da det fort sniker seg med en endring som KI’en tenkte ville være en bra endring. I tillegg skal man være bevisst på sikkerheten i løsningen som genereres – da den valgte å implementere OpenAI direkte fra browseren og ikke server-side. Dette var ok til brukertesten, men i produksjon ville API-nøkkelen vår kunne blitt misbrukt.
Claude Code som kodeassistent
Etter den grunnleggende funksjonaliteten var på plass, eksporterte jeg prosjektet og fortsatte lokalt. Her fikk jeg hjelp av Claude Code – en agentisk kode-assistent som forstår hele prosjektet ditt, kan forklare arkitektur, redigere filer, kjøre tester og linting. Hvis det kan kjøres i terminalen, kan Claude Code håndtere det for deg.
Deretter satt jeg opp et git-repo og fortsatte i en mer tradisjonell utviklerflyt. Claude Code er kraftig, men det koster fort tokens – om man prøver å automatisere for mye i én omgang, eller får den til å flytte en knapp eller gjøre en enkel omdøping.
Jobb slik du ellers ville gjort som utvikler: løs én oppgave om gangen, forstå hva du prøver å oppnå, og bruk Claude Code som et verktøy – ikke som en snarvei til et ferdig produkt.
UX er fortsatt UX
Det skulle vise seg at ikke alt lot seg løse med kommandoer som “Fix the UX issue” eller “Make it more user friendly”. Heldigvis satt det en dyktig UX-designer i rommet, og selv om vi laget konkurrerende løsninger, fikk jeg god hjelp.
Oppsummering
Til tross for noen tekniske utfordringer i starten, endte jeg opp med en fungerende prototype hvor brukere kunne beskrive symptomer, svare på spørsmål generert fra GPT-4-1 og få råd og anbefalinger basert på svarene. Dette gjorde det mulig å teste langt bredere enn vi ellers kunne gjort.
Bolt.new er perfekt for å komme kjapt i gang, spesielt til prototyping. Claude Code er en god kode-assistent for videreutvikling og strukturert arbeid. Og Firebase Studio fortjener nok en ny sjanse.
Erfaring som UX designer Databutton og Lovable
Dette var mitt første møte med KI-verktøy som lager ferdige tjenester og jeg var spesielt interessert i å sjekke ut tre ting:
Hvordan så det visuelle designet ut? (Jeg la ikke inn noen føringer på dette, sa bare at jeg ønsket et profesjonelt design til en helseapp)
Hvordan ble brukeropplevelsen? Kunne jeg få gode forslag til hvordan jeg kan løse ulike UX-utfordringer i tjenesten?
Hvor stor grad av kontroll hadde jeg på sluttresultatet?
1. Visuelt utseende
Databutton imponerte med profesjonelt design fra første prompt – det kunne lett forveksles med en ferdig nettside. Lovables design trengte mer finpussing, og mine forsøk på forbedringer gjorde faktisk designet verre. Her hadde det muligens vært nyttig å legge inn mer informasjon om hva jeg ønsket fra start.
2. Brukeropplevelse og inspirasjon
Databutton forstod oppgaven godt og lagde en prototype med en god brukeropplevelse. Her er det flere konsepter jeg kommer til å ta med videre til den endelige tjenesten. Lovable tolket oppgaven annerledes og trengte mer justering for å få til en god flyt.
3. Arbeidsflyt og kontroll
De to verktøyene hadde ulik tilnærming. Databutton gav meg både mulighet til å laste opp det jeg hadde av dokumentasjon og ga meg en stegvis prosess med mulighet for godkjenning underveis. Dette likte jeg godt og det gav meg god kontroll over sluttresultatet. I Lovable la jeg inn all informasjon i starten og måtte vente lenger på at den bygde hele løsningen på én gang, som endte med at prototypen ikke ble helt som ønsket.
Oppsummering
Jeg valgte Databutton for den endelige prototypen på grunn av bedre visuelt design og mer kontroll. Det mest fascinerende med begge verktøyene var hastigheten – jeg kunne teste ut konsepter mye raskere enn med tradisjonelle designverktøy. Samtidig oppdaget jeg at KI ikke alltid følger god UX-praksis, og små justeringer på prototypen fort ble tidkrevende.
Databutton forside
Lovable forside
Databutton innganger
Lovable innganger
Dag 4 - Brukertesting: Effektiv feedback
Dag fire brukte vi til å teste prototypene på 7 ekte mennesker (og en AB test med Chat gpt), og det ga oss flere nyttige svar. Inngangen med fritekstfeltet var en klar vinner! Testerne likte den best og løste oppgavene raskere med den. Men vi så også at det er lurt å ha en alternativ inngang hvor man kan velge symptomer fra en liste, siden folk er forskjellige og kan være i ulike situasjoner når de bruker tjenesten. Testen viste at søkefunksjonen var en god idé, men det ble tydelig at den må gi relevante treff for å være nyttig – noe vår prototype ikke helt fikk til ennå. Vi fikk oss også en overraskelse da vi oppdaget at mange ikke så "Neste"-knappen vår som satt fast nederst på siden, så her må vi gjøre en jobb med interaksjonen.
Og så var det emojiene da (til UX designerens frustrasjon), de skapte engasjement og folk syntes de var morsomme, men det ble raskt påpekt at de ikke stemte helt med symptomene. Alt i alt ga testdagen oss akkurat det vi trengte – konkrete tilbakemeldinger vi kan jobbe videre med!
Oppsummering
Etter en intensiv uke kan vi konkludere: KI-drevet prototyping er ekstremt effektivt! På bare fem dager gikk vi fra løse ideer til brukertestede løsninger. Vi har fått mange gode forslag til brukerflyt som vi tar med oss videre i utviklingen. Vår erfaring er at KI-verktøyene utmerker seg på å lage hele prototypen kjapt, mens små justeringer fortsatt er best å gjøre selv. Denne kombinasjonen av KI-kraft og fagkunnskap er en vinnende formel vi definitivt kommer til å bruke igjen.
