AI og produktutviklingHafsteinn Runarsson · AI Konsulent14 Aug 2026 · 9 min

Design thinking for AI-produkter: fra brukerbehov til testbar atferd

Design thinking er en metode for å forstå et problem fra brukerens ståsted før teamet bestemmer seg for en løsning. Det høres enkelt ut. I AI-produkter er det likevel lett å gjøre det motsatte: velge modell, bygge en imponerende demo og først etterpå spørre om den løser en oppgave noen faktisk har.

En bedre prosess starter med behovet. Deretter undersøker teamet hvilken rolle AI bør ha, hvordan brukeren skal beholde kontrollen, og hva løsningen må mestre før den kan tas i bruk.

Hva er design thinking?

Design thinking, eller designtenkning, er en brukersentrert og praktisk metode for problemløsning. Teamet undersøker hvordan mennesker opplever en situasjon, avgrenser problemet, utvikler flere løsningsforslag og lærer gjennom prototyper og tester.

Metoden beskrives ofte med fem faser:

1. Forstå brukeren
2. Definere problemet
3. Utvikle ideer
4. Lage prototyper
5. Teste og lære

Fasene er ikke en rett linje. En test kan vise at problemet er feil formulert. Et intervju kan avdekke en ny brukergruppe. En prototype kan vise at vanlig automasjon løser oppgaven bedre enn AI. Da går teamet tilbake og justerer.

Det er nettopp denne bevegelsen mellom utforskning og avgrensning som gjør metoden nyttig når både problemet og løsningen er usikre.

De fem fasene, tilpasset AI-produkter

1. Forstå brukeren og arbeidssituasjonen

Start med det brukeren prøver å få gjort. Ikke start med en modell eller en liste over funksjoner.

Intervjuer er nyttige, men de bør ikke stå alene. Observer hvordan oppgaven faktisk utføres. Se hvilke systemer som brukes, hvor informasjonen kommer fra, hva som krever skjønn, og når en kollega må kobles inn. Det folk beskriver i et intervju, er ikke alltid hele arbeidsflyten.

For et AI-produkt bør teamet også undersøke forholdet mellom hjelp og kontroll:

• Hvilke beslutninger ønsker brukeren støtte til?
• Hvilke handlinger vil brukeren alltid godkjenne selv?
• Hva oppleves som en alvorlig feil?
• Når må løsningen stoppe og be om hjelp?
• Hvilken informasjon kan den bruke i oppgaven?
• Hvordan vil brukeren kontrollere at svaret er godt nok?

Dette gir mer enn en liste over ønsker. Det viser hvor et AI-system kan passe inn, og hvor det ikke bør få ansvar.

2. Definere problemet presist

Et svakt problemutsagn beskriver teknologien: «Vi trenger en chatbot.» Et bedre utsagn beskriver brukeren, oppgaven og hindringen:

> En kundebehandler trenger å finne riktig informasjon mens saken pågår, men må lete i flere kilder og kontrollere at svaret gjelder den aktuelle kunden.

Nå kan teamet vurdere flere løsninger. Kanskje behovet er bedre søk. Kanskje en copilot bør foreslå et svar som et menneske godkjenner. Kanskje deler av prosessen kan automatiseres uten AI.

En praktisk problemdefinisjon bør avklare:

• hvem løsningen er for
• hvilken situasjon den skal brukes i
• hva brukeren prøver å oppnå
• hvilke begrensninger som gjelder
• hvilke feil som ikke kan aksepteres
• hva som må være målbart i en test

For AI-produkter bør teamet også skrive tydelige avgrensninger. Hva skal produktet ikke gjøre? Hvilke saker skal sendes videre? Hvilke datakilder skal være utenfor rekkevidde? Slike valg gjør både prototypen og senere testing mer presis.

3. Utvikle flere løsningsideer

Idéfasen bør utforske flere nivåer av automasjon. Et vanlig feilgrep er å anta at den mest selvstendige AI-agenten også er den beste løsningen.

Sammenlign minst disse alternativene:

• en enklere endring i arbeidsflyten
• regelbasert automasjon
• søk eller oppslag i godkjente kilder
• en copilot som foreslår, mens brukeren beslutter
• en agent som utfører avgrensede handlinger med godkjenning

Vurder hvert alternativ mot brukerens behov, risikoen ved feil, behovet for data og hvor mye kontroll brukeren trenger. En enkel løsning kan være riktig hvis oppgaven er stabil og reglene er kjent. En mer fleksibel AI-løsning kan være aktuell når informasjonen varierer og oppgaven krever tolkning.

Idéfasen er også stedet for å tegne samspillet. Vis hva brukeren gjør, hva systemet foreslår, når en handling krever godkjenning, og hvordan produktet håndterer usikkerhet. Da diskuterer teamet faktisk atferd, ikke bare en funksjonsliste.

4. Prototype atferden før hele systemet bygges

En AI-prototype trenger ikke være en ferdig integrasjon. Målet er å lære om brukeropplevelsen og systemets rolle med minst mulig bygging.

Teamet kan begynne med:

• skisser av dialoger og beslutningspunkter
• eksempler på gode, svake og usikre svar
• en klikkbar prototype med forhåndsskrevne utfall
• en simulering der et menneske spiller rollen som AI-en
• et begrenset teknisk forsøk med anonymiserte eller konstruerte testdata

En slik prototype kan vise hvordan brukeren reagerer når systemet er usikkert, ber om bekreftelse eller ikke kan fullføre oppgaven. Det er ofte mer lærerikt enn en polert demo som bare viser det beste utfallet.

Prototypen bør dekke både normal bruk og vanskelige situasjoner. Hva skjer når viktig informasjon mangler? Når to kilder motsier hverandre? Når brukeren ber om noe utenfor oppgaven? Når en handling bør stoppes?

For en copilot kan prototypen vise et forslag, begrunnelsen for forslaget og en tydelig godkjenning. For en agent kan den vise planlagte handlinger før de utføres, samt hvilke trinn som krever menneskelig kontroll.

5. Test med tydelige kriterier

En test bør svare på mer enn om brukeren liker grensesnittet. Teamet må undersøke om løsningen hjelper med den avgrensede oppgaven, om brukeren forstår systemets rolle, og om kontrollpunktene fungerer.

Definer testkriteriene før resultatene vurderes. De kan for eksempel omfatte:

• om oppgaven blir fullført riktig
• om kritisk informasjon blir oversett
• om systemet stopper i avtalte situasjoner
• om brukeren oppdager og retter et svakt forslag
• om eskalering til et menneske skjer på riktig tidspunkt
• hvor lang tid et svar eller en handling tar
• hvilken kostnad hver gjennomføring har

For AI-produkter er en samling faste testsituasjoner nyttig. Den kan inneholde vanlige oppgaver, sjeldne tilfeller og kjente feilmodi. Den samme samlingen kan brukes når instrukser, datakilder eller modeller endres. Da får teamet et mer stabilt grunnlag for å sammenligne versjoner.

Testing vil ofte sende teamet tilbake til en tidligere fase. Det kan være nødvendig å snevre inn oppgaven, endre kontrollpunktene eller velge en enklere løsning. Det er læring, ikke et mislykket prosjekt.

Den doble diamanten forklart

Design thinking vises ofte som en dobbel diamant. Den første diamanten handler om problemet. Teamet åpner opp ved å samle innsikt fra flere brukere og situasjoner, og lukker deretter ved å definere hvilket problem som skal løses.

Den andre diamanten handler om løsningen. Teamet åpner opp igjen ved å utvikle flere ideer, og lukker ved å prototype, teste og velge retning.

For et AI-produkt kan modellen oppsummeres slik:

1. Utforsk arbeidssituasjonen, behovene og risikoene.
2. Avgrens oppgaven og ansvaret AI-en kan få.
3. Sammenlign flere løsningsformer og grader av automasjon.
4. Test atferd, kontroll og feilmodi før full bygging.

Diamantene minner teamet om to ting: Ikke lås problemet for tidlig, og ikke forelsk deg i den første løsningen.

Hva er annerledes med design thinking for AI?

Et vanlig digitalt produkt gir som regel samme resultat når brukeren gjør det samme. Et AI-produkt kan gi ulike svar på lignende forespørsler. Derfor må designarbeidet omfatte mer enn skjermbilder og navigasjon.

Produktet har en atferd, ikke bare et grensesnitt

Teamet må utforme hvordan systemet spør, foreslår, forklarer, avstår og eskalerer. Det bør være tydelig hva AI-en har gjort, hvilke valg brukeren har, og hva som skjer videre.

Tillit må erstattes av kontroll

Målet er ikke at brukeren skal stole blindt på produktet. Målet er at brukeren skal kunne vurdere et forslag, forstå grensene og gripe inn når det trengs. Synlige kilder, bekreftelser og eskalering kan være deler av denne kontrollen, avhengig av oppgaven.

Feilmodi må inn i prototypen

Hvis prototypen bare viser gode svar, lærer teamet lite om produktet som skal brukes i praksis. Testene bør også inneholde manglende data, tvetydige spørsmål, motstridende informasjon og forespørsler utenfor avgrensningen.

Evaluering må planlegges tidlig

Det er vanskelig å vurdere et AI-produkt hvis «godt svar» ikke er definert. Teamet bør derfor formulere eksempler, kriterier og stoppregler mens problemet avgrenses. Disse kan senere utvikles til faste evalueringer for produktet.

Når passer metoden?

Design thinking passer godt når teamet ikke forstår problemet fullt ut, flere brukergrupper har ulike behov, eller løsningen påvirker en eksisterende arbeidsflyt. Metoden er også nyttig når feil kan få forskjellige konsekvenser for brukeren og virksomheten.

Den er mindre nyttig som en omfattende øvelse når oppgaven allerede er presis, årsakene er godt forstått og løsningen følger kjente regler. Da kan vanlig analyse og direkte implementering være mer effektivt.

Metoden bør heller ikke bli et ritual. Antall workshops, lapper eller maler sier lite om kvaliteten. Verdien ligger i kontakten med brukerne, tydelige valg og tester som kan endre retningen.

Vanlige fallgruver

Teamet starter med teknologien

Når løsningen allerede er bestemt, blir brukerinnsikt lett brukt til å bekrefte valget. Hold derfor problemdefinisjonen åpen lenge nok til å sammenligne AI med enklere alternativer.

En god demo blir behandlet som et ferdig produkt

En demo viser gjerne ett kontrollert forløp. Et produkt må håndtere variasjon, manglende informasjon, feil og menneskelig overstyring. Prototypen bør brukes til å finne disse kravene, ikke skjule dem.

Bare fornøyde brukere blir intervjuet

Snakk også med dem som kontrollerer arbeidet, håndterer avvik eller mottar resultatet. De kan ha andre behov enn personen som bruker grensesnittet hver dag.

Testen mangler en definisjon av godt nok

Uten kriterier blir vurderingen fort subjektiv. Skriv ned forventet resultat, uakseptable feil og krav til eskalering før testen starter.

Prototypen glir rett inn i produksjon

En prototype er laget for læring. Før produksjon må teamet ta stilling til datatilgang, sikkerhet, drift, overvåking, kostnader og hvordan endringer skal evalueres.

En praktisk arbeidsmal

Bruk disse spørsmålene når dere skal utforske et AI-produkt:

Bruker og problem

• Hvem utfører oppgaven i dag?
• Hva prøver personen å oppnå?
• Hvor oppstår friksjon, venting eller usikkerhet?
• Hvem blir påvirket av resultatet?

Rolle og ansvar

• Skal løsningen informere, foreslå eller handle?
• Hvilke handlinger krever godkjenning?
• Når skal systemet stoppe eller eskalere?
• Hva ligger uttrykkelig utenfor oppgaven?

Prototype

• Hvilken atferd må brukeren få oppleve?
• Hvilke svake eller usikre utfall må vises?
• Kan dette simuleres før integrasjoner bygges?
• Hvilke data er nødvendige for en avgrenset test?

Evaluering

• Hva er et riktig resultat?
• Hvilke feil er uakseptable?
• Hvordan oppdager brukeren et svakt forslag?
• Hvilke faste testsituasjoner skal brukes på nytt?

Ofte stilte spørsmål

Hva er design thinking kort forklart?

Design thinking er en brukersentrert metode for problemløsning. Teamet undersøker behov, definerer problemet, utvikler flere ideer og lærer gjennom prototyper og tester.

Hvilke fem faser inngår i design thinking?

De fem fasene beskrives ofte som empati eller brukerforståelse, definering, idéutvikling, prototyping og testing. I praksis beveger teamet seg frem og tilbake mellom dem.

Hva er forskjellen på design thinking og den doble diamanten?

Design thinking er en metode og et tankesett. Den doble diamanten er en modell som visualiserer hvordan teamet først utforsker og avgrenser problemet, og deretter utforsker og velger løsning.

Hvordan brukes design thinking i digital produktutvikling?

Metoden brukes til å forstå arbeidsflyter og behov før funksjoner bygges. Teamet kan teste brukerreiser, grensesnitt og produktatferd i enkle prototyper, og bruke funnene til å prioritere videre utvikling.

Hvordan tester man et AI-produkt før man bygger alt?

Start med skisser, forhåndsskrevne utfall eller en simulering der et menneske spiller systemets rolle. Test både gode resultater, usikkerhet og feilmodi. Definer på forhånd hva som er riktig, hva som krever godkjenning, og når løsningen skal stoppe.

Fra innsikt til et produkt som kan bygges

Design thinking gir ikke automatisk et godt AI-produkt. Metoden gir teamet en disiplin for å forstå oppgaven, sammenligne løsninger og teste de viktigste antakelsene før hele systemet bygges.

Daia arbeider med AI-agenter og copiloter samt full-stack-produkter. Har dere en arbeidsflyt eller produktidé som bør utforskes, kan dere starte en samtale om behov, avgrensning og neste steg.