Design thinking: Slik løser du komplekse problemer og driver innovasjon fremover

Jeg husker første gang jeg hørte uttrykket «design thinking» – det var på en konferanse i Oslo for noen år siden, og ærlighet talt tenkte jeg «enda et buzzword som kommer til å forsvinne om seks måneder». Men så skjedde noe interessant. Klienten min, en norsk teknologibedrift, hadde kjørt seg helt fast med et produktutviklingsprosjekt. De hadde brukt måneder på å finne en løsning på det de trodde var problemet, men ingenting fungerte. Det var da jeg foreslo å prøve design thinking-tilnærmingen, selv om jeg på det tidspunktet ikke var helt sikker på om jeg kunne forklare det ordentlig til bestemor mi.

Resultatet? Vi gikk tilbake til start, spurte helt andre spørsmål, og oppdaget at de faktisk hadde definert feil problem fra begynnelsen av. Innen tre uker hadde vi en løsning som ikke bare fungerte – den var genial. Det var der det gikk opp for meg at design thinking ikke bare er en metode, men en helt ny måte å tenke på når komplekse utfordringer skal løses.

Som tekstforfatter og skribent har jeg siden jobbet med alt fra oppstartsbedrifter til etablerte konsern som ønsker å bruke design thinking til å fremme innovasjon. Etter å ha sett metodikken i aksjon hundrevis av ganger, kan jeg trygt si at den har potensial til å endre hvordan vi angriper problemer – både i arbeidslivet og privat. Men la meg være ærlig: det krever at man tør å tenke annerledes og slippe kontrollen litt. Ikke alle er komfortable med det.

Hva er egentlig design thinking og hvorfor funker det så bra?

Altså, hvis jeg skal være helt ærlig, så er design thinking mye enklere å forstå enn det høres ut som. Grunnleggende handler det om å tilnærme seg problemer på samme måte som designere har gjort i årevis – men nå bruker vi denne tilnærmingen på alt mulig annet også. I stedet for å hoppe rett til løsninger (som jeg innrømmer at jeg gjorde i mange år), tar man et skritt tilbake og spør: «Hva er det egentlig vi prøver å løse her?»

Jeg jobbet en gang med en kommune som skulle forbedre sine digitale tjenester. De hadde allerede bestemt seg for at løsningen var en ny app. Men da vi brukte design thinking-metoder og faktisk snakket med innbyggerne, fant vi ut at problemet ikke var mangel på en app – det var at folk ikke visste hvilke tjenester som fantes i det hele tatt! Plutselig ble løsningen noe helt annet: bedre kommunikasjon og informasjon, ikke enda en app som ville forvirre folk ytterligere.

Design thinking bygger på noen grunnleggende prinsipper som jeg har sett fungere gang på gang. For det første: mennesket i sentrum. Det høres kanskje selvinnlysende ut, men du ville blitt overrasket over hvor mange bedrifter som bygger produkter eller tjenester uten å snakke ordentlig med de som faktisk skal bruke dem. For det andre: embrace the mess, som amerikanerne sier. Komplekse problemer er rotete, og det er greit. Man trenger ikke ha alle svarene før man begynner.

Det tredje prinsippet er noe jeg lærte på den harde måten: fail fast and cheap. Jeg brukte tidligere måneder på å perfeksjonere ideer før jeg testet dem. Nå bygger jeg grove prototyper på dager eller timer, tester dem, og forkaster dem hvis de ikke fungerer. Det sparer utrolig mye tid og energi – og ego, for å være ærlig.

De fem fasene i design thinking-prosessen

Stanford d.school populariserte en femtrinnsprosess som jeg har brukt som utgangspunkt i det meste jeg gjør. Men la meg si det med en gang: dette er ikke en lineær oppskrift du følger slavisk. Det er mer som en koreografi – du kan hoppe mellom fasene, gå tilbake, eller bruke lengre tid på én fase enn andre. Fleksibilitet er nøkkelen.

Den første fasen heter «Empathize» – eller empati på godt norsk. Det handler om å virkelig forstå hvem du lager noe for. Ikke hvem du tror du lager det for, men hvem det faktisk er. Jeg pleier å si til klientene mine: «Hvis du ikke har snakket ansikt til ansikt med minst fem personer som representerer målgruppen din, har du ikke gjort jobben din ordentlig.» Det kan høres brutalt ut, men det er sant.

En gang jobbet jeg med en bedrift som laget programvare for regnskapsførere. De hadde bygget det de trodde var verdens beste løsning, men salget gikk tregt. Da vi endelig satte oss ned med faktiske regnskapsførere, fant vi ut at hovedproblemet deres ikke var at eksisterende programvare var tungvint – det var at de brukte så mye tid på å forklare feilmeldinger til klientene sine at de holdt på å bli gale. Ingen hadde tenkt på det aspektet før.

Define: Å definere det ekte problemet

Den andre fasen, «Define», er der magien ofte skjer. Her tar du alt du har lært i empati-fasen og koker det ned til ett klart problem statement. Trikset er å formulere det som en «How might we…»-setning. Ikke «Hvordan kan vi bygge en bedre app», men «Hvordan kan vi hjelpe småbarnsfamilier å spare tid på matplanlegging slik at de kan bruke mer tid sammen?»

Jeg husker hvor frustrerende jeg syntes denne fasen var i begynnelsen. Det føltes som om vi brukte altfor mye tid på å definere problemet i stedet for å løse det. Men etter å ha sett hvor mange prosjekter som går av sporet fordi man løser feil problem, har jeg lært å verdsette denne fasen enormt. Det er mye bedre å bruke to uker ekstra på å definere riktig problem enn å bruke seks måneder på å løse feil problem.

Ideate: La kreativiteten få fritt løp

Fasen «Ideate» er der mange føler seg mest komfortable – det er her vi brainstormer og kommer med ideer. Men det er også der jeg ser flest feil. Folk hopper for fort til bedømmelse av ideer, eller de lar de mest høylytte stemmene dominere. Min erfaring er at de beste ideene ofte kommer fra de som vanligvis ikke sier så mye i møter.

Jeg har utviklet noen teknikker gjennom årene som fungerer godt. «Crazy 8s» er en av favorittene mine – alle får åtte minutter til å skissere åtte forskjellige ideer. Én idé per minutt tvinger folk til å tenke raskt og ikke sensurere seg selv. En annen teknikk jeg bruker ofte er «Yes, and…» – i stedet for å si «ja, men det vil ikke fungere fordi…», sier man «ja, og vi kunne også…» Det bygger på ideer i stedet for å rive dem ned.

En gang hadde jeg en workshop med en gruppe ingeniører som skulle finne nye måter å redusere matsvinn på. De første ideene var alle teknologiske – sensorer, kunstig intelligens, nye emballasjetyper. Men da vi brukte «Crazy 8s»-metoden, kom plutselig ideer som «hva om vi lærte folk å lage middag av rester» og «hva om butikkene ga rabatt på mat som går ut dagen etter». De enkleste ideene var ofte de beste.

Prototype: Bygg for å lære

«Prototype»-fasen er der de fleste norske bedrifter strever. Vi har en tendens til å ville perfeksjonere ting før vi viser dem frem, men hele poenget med prototyping i design thinking er det motsatte. Du bygger for å lære, ikke for å imponere. Jo raskere og billigere du kan teste en idé, jo bedre.

Jeg husker en kunde som brukte tre måneder på å bygge en prototype av en mobil app. Da vi endelig testet den, fant vi ut på fem minutter at hovednavigasjonen var helt forvirrende. De tre månedene kunne vært spart hvis de hadde laget papirprototyper først. Nå anbefaler jeg alltid å starte med det som kalles «low-fidelity prototypes» – enkle skisser, pappmodeller, eller digitale wireframes som tar timer, ikke måneder å lage.

En av mine mest suksessrike prototyping-opplevelser var med et sykehus som skulle forbedre pasientopplevelsen. I stedet for å bygge noe digitalt, laget vi en «prototype» av hele pasientreisen ved å rolleplay den. Vi oppdaget problemer og muligheter vi aldri ville funnet ved å se på flytskjemaer eller bygge software. Noen ganger er den beste prototypen ikke teknologisk i det hele tatt.

Test: Lær av ekte brukere

Den siste fasen, «Test», høres kanskje enkel ut, men det er der jeg ser flest feil. Folk tester med kollegaer, familie, eller «brukere» som egentlig bare sier hva de tror du vil høre. Ekte testing krever litt mot – både til å finne representantive testobjekter og til å håndtere tilbakemeldingerene du får.

Jeg lærte dette på den harde måten da jeg testet en prototype for en kunnskapsdelingsplatform. Jeg testet med fem kollegaer som alle sa at det var genial. Da jeg testet med fem faktiske brukere, sa fire av dem at de ikke forstod poenget med hele tingen. Tilbakemeldingene var tøffe å få, men de reddet prosjektet fra å bli en katastrofe.

Nøkkelen til god testing er å stille åpne spørsmål og observere hva folk faktisk gjør, ikke bare lytte til hva de sier. «Hvordan ville du brukt dette i en vanlig arbeidsdag?» er et mye bedre spørsmål enn «Synes du dette er bra?» Folk vil ofte være høflige og si at noe er bra, men hvis du ber dem vise deg hvordan de ville brukt det, ser du raskt hvor problemene ligger.

Praktisk anvendelse: Design thinking i det virkelige liv

La meg dele noen konkrete eksempler på hvordan jeg har sett design thinking brukt til å løse komplekse problemer i norske bedrifter og organisasjoner. Det ene eksempelet som virkelig står igjen for meg, var arbeidet med en offentlig etat som slet med lang saksbehandlingstid. De hadde prøvd alt – ny programvare, flere ansatte, bedre rutiner – men ingenting hjalp ordentlig.

Da vi brukte design thinking-tilnærmingen, startet vi med å følge faktiske saker gjennom hele systemet. Vi snakket med både saksbehandlere og borgere som ventet på svar. Det vi fant ut var helt annerledes enn det ledelsen hadde trodd: problemet var ikke kapasitet eller rutiner, men at 40% av sakene som kom inn manglet informasjon som førte til frem-og-tilbake kommunikasjon. Løsningen ble å redesigne innsendingsskjemaene og lage en enkel sjekkliste folk kunne bruke før de sendte inn søknaden.

Et annet eksempel som illustrerer kraften i design thinking er arbeidet jeg gjorde med en norsk eksportbedrift. De slet med å komme inn på det asiatiske markedet og hadde brukt enormt mye ressurser på tradisjonell markedsføring uten resultat. Gjennom empati-fasen oppdaget vi at deres antakelser om målgruppen var helt feil – de trodde prisen var viktigst, men kvalitet og pålitelighet var faktisk avgjørende. Mer interessant: måten de kommuniserte kvalitet på fungerte ikke i den kulturelle konteksten.

Løsningen involverte ikke bare å endre markedsføringsstrategien, men hele måten de tenkte på produktutvikling. De begynte å inkludere lokale partnere i designprosessen fra dag én, ikke bare i salgsleddet. Resultatet var produkter som faktisk var tilpasset markedet, ikke bare oversatt til det.

Design thinking i produktutvikling og innovasjon

Når det kommer til produktutvikling, har jeg sett design thinking gjøre underverker gang på gang. Problemet med tradisjonell produktutvikling er ofte at man starter med en teknologi eller en idé, og så prøver man å finne ut hvem som kan ha nytte av den. Design thinking snur denne prosessen på hodet – man starter med mennesker og deres behov, og finner så ut hvilken teknologi som kan løse disse behovene best.

Jeg jobbet for eksempel med et norsk teknologiselskap som hadde utviklet en fantastisk algoritme for å optimalisere energiforbruk i bygninger. De hadde brukt år på å finne ut hvordan de kunne selge denne teknologien til eiendomsforvaltere. Men da vi brukte design thinking og snakket med faktiske eiendomsforvaltere, fant vi ut at de ikke brydde seg så mye om optimalisering – de ville bare ha færre klager fra leietakerne om at det var for varmt eller for kaldt.

Plutselig ble produktet ikke lenger en «energioptimaliseringsløsning» men en «komfortgarantitjeneste». Samme teknologi, men helt annen posisjonering og brukeropplevelse. I stedet for å fokusere på kilowattimer og effektivitet, fokuserte de på komfort og færre klager. Salget eksploderte, fordi de endelig snakket om det kundene faktisk brydde seg om.

En av de mest lærerike opplevelsene jeg hadde var med en oppstartsbedrift som skulle lage en app for å hjelpe folk med å holde treningsavtaler. De kom til meg med en ferdig app som var teknisk sett perfekt – den hadde sosial integrering, gamification, personlig AI-coach, alt man kunne tenke seg. Men ingen brukte den.

Gjennom design thinking-prosessen fant vi ut at hovedproblemet folk hadde med trening ikke var motivasjon eller planlegging – det var at de ikke visste hvordan de skulle bruke utstyret på treningssenteret uten å virke dumme. Løsningen ble ikke en bedre app, men en tjeneste som koblet nybegynnere med erfarne trenere for korte, uformelle introduksjonsesjoner. Noen ganger er den beste teknologiske løsningen faktisk ikke teknologisk i det hele tatt.

Innovasjon gjennom brukerinnsikt

Det som gjør design thinking så kraftig for innovasjon er fokuset på brukerinnsikt. Men la meg være klar på en ting: brukerinnsikt handler ikke bare om å spørre folk hva de vil ha. Som Henry Ford sa (selv om han sannsynligvis aldri sa det): «Hvis jeg hadde spurt folk hva de ville ha, ville de sagt en raskere hest.» Det handler om å forstå underliggende behov og motivasjoner som folk kanskje ikke engang er bevisste selv.

Jeg jobbet en gang med en tjeneste som skulle hjelpe eldre med teknologi. Den opprinnelige ideen var å lage enklere grensesnitt på eksisterende teknologi – større knapper, enklere menyer, og så videre. Men da vi virkelig fordypet oss i empati-fasen, fant vi ut at problemet ikke var at teknologien var for komplisert. Problemet var at eldre følte seg dumme når de ikke forstod ting som barnebarna deres syntes var selvinnlysende.

Løsningen ble ikke enklere teknologi, men en læringssituasjon der eldre kunne lære sammen med andre på samme nivå, uten å føle seg dømt. Vi laget «teknologi-kaféer» der folk kunne møtes og lære sammen. Innovasjonen var ikke i teknologien, men i leveringsmodellen og den sosiale konteksten rundt læringen.

Hvordan design thinking bryter ned siloer

En av de største fordelene med design thinking er hvordan det bryter ned organisatoriske siloer. Tradisjonelt jobber markedsavdelingen med markedsføring, utviklingsavdelingen med utvikling, og kundeserviceavdelingen med kundestøtte. Men komplekse problemer bryr seg ikke om organisasjonskart. De krysser avdelinger, funksjoner og hierarkier.

Jeg husker et prosjekt med en norsk bank som slet med kundetilfredshet på deres digitale tjenester. Markedsavdelingen mente problemet var at de ikke kommuniserte fordelene godt nok. IT-avdelingen mente problemet var at bankens gamle systemer gjorde ting trege. Kundeserviceavdelingen mente problemet var at kundene ikke forstod hvordan tjenestene fungerte.

Alle hadde rett – og alle tok feil. Da vi brukte design thinking og samlet folk fra alle avdelingene til å jobbe sammen, fant vi ut at problemet var at hele kundereisen var designet fra bankens perspektiv, ikke kundens. En enkel overføring krevde at kunden hoppet mellom tre forskjellige systemer og godkjente fire forskjellige meldinger. Det tekniske fungerte perfekt, markedsføringen var presis, og kundeservicen kunne forklare hvert steg – men opplevelsen var forferdelig.

Løsningen krevde endringer fra alle avdelinger, men fordi de hadde jobbet sammen gjennom hele design thinking-prosessen, forstod alle hvorfor endringene var nødvendige og hvordan de hang sammen med andres arbeid.

Vanlige fallgruver og hvordan unngå dem

Etter å ha observert hundrevis av design thinking-prosesser, har jeg sett de samme feilene gjentatt gang på gang. Den største fallgruven er det jeg kaller «solutionism» – tendensen til å hoppe direkte til løsninger uten å bruke nok tid på å forstå problemet. Det er så fristende, spesielt når man har et team fullt av kreative folk som brenner for å lage ting.

Jeg var selv skyldig i dette i starten. En kunde kom med det de beskrev som et «enkelt problem»: de trengte en bedre måte å kommunisere med kundene sine på. I stedet for å grave dypere, satte vi i gang med å designe en kommunikasjonsplattform. Det var først etter tre uker med utvikling at vi fant ut at hovedproblemet ikke var kommunikasjonen, men at produktet deres var så forvirrende at kundene trengte konstant støtte.

En annen vanlig feil er det jeg kaller «fake empathy». Folk tror de forstår brukerne sine fordi de har lest markedsrapporter eller gjort online-undersøkelser. Men det er en enorm forskjell på å vite at «78% av målgruppen sier de er interessert i miljøvennlige alternativer» og å sitte ansikt til ansikt med noen som prøver å forklare hvorfor de fortsatt kjøper den billigste varianten selv om de er bekymret for miljøet.

Jeg lærte dette da jeg jobbet med en bedrift som laget miljøvennlig emballasje. Alle undersøkelsene viste at folk var interessert, men salget var skuffende. Da vi endelig snakket med faktiske innkjøpere, fant vi ut at miljøhensyn var viktig for dem – men bare hvis alt annet var likt. Hvis den miljøvennlige emballasjen var vanskeligere å håndtere, dyrere, eller så annerledes ut enn det kundene var vant til, valgte de det tradisjonelle alternativet. Innsikten førte til en helt annen produktstrategi som fokuserte på å gjøre den miljøvennlige løsningen lettere og mer praktisk, ikke bare grønnere.

Hvorfor design thinking feiler

La meg være brutalt ærlig: design thinking er ikke en magisk løsning som fungerer i alle situasjoner. Jeg har sett det feile spektakulært, og ofte er det fordi folk behandler det som en fast oppskrift i stedet for en fleksibel tilnærming. Den største grunnen til at design thinking-prosjekter feiler er mangel på ekte forpliktelse fra ledelsen.

Et eksempel som fortsatt gjør vondt å tenke på: jeg jobbet med et stort norsk selskap som ønsket å bruke design thinking til å forbedre medarbeideropplevelsen. Vi gjorde en grundig prosess, involvert alle nivåer i organisasjonen, og kom fram til noen fantastiske innsikter og løsninger. Men da det kom til implementering, ville ikke ledelsen endre de strukturelle problemene som var årsaken til mange av utfordringene. De ville gjerne ha de kosmetiske endringene – bedre kafé, nye møterom, fleksible arbeidstider – men ikke ta tak i kommunikasjonsproblemene og beslutningsprosessene som egentlig plaget medarbeiderne.

Resultatet var at folk følte seg mer frustrerte enn før, fordi de hadde fått håp om endring som ikke kom. Det er bedre å ikke starte en design thinking-prosess enn å starte en du ikke har tenkt å følge opp ordentlig.

Design thinking for tjenesteinnovasjon

En av områdene der jeg har sett design thinking gjøre størst forskjell er i tjenesteinnovasjon. Tjenester er komplekse – de består av mange berøringspunkter, involvert flere mennesker, og skjer over tid. Tradisjonelle tilnærminger til tjenestedesign fokuserer ofte på effektivitet og kostnader, men design thinking setter brukeropplevelsen i sentrum.

Et prosjekt som virkelig åpnet øynene mine var med en norsk kommune som skulle forbedre sin hjemmehjelptjeneste. Den tradisjonelle tilnærmingen ville vært å se på tidsbruk, ruter, og kostnader per besøk. Men da vi brukte design thinking, startet vi med å forstå opplevelsen både for brukerne som fikk hjemmehjelpet og de ansatte som leverte det.

Det vi fant ut var at den største utfordringen ikke var effektivitet, men kontinuitet. Brukerne fikk stadig nye hjemmehjelper fordi folk sluttet i jobben eller skiftevakter. Hver ny person måtte lære hvor ting sto, hvordan brukeren likte at ting ble gjort, og bygge opp tillit på nytt. For eldre brukere var dette spesielt stressende.

Løsningen ble ikke å ansette flere folk eller forbedre rutene, men å redesigne hele tjenestemodellen rundt kontinuitet. De opprettet mindre team som jobbet med færre brukere over lengre tid, og de investerte i bedre opplæring og arbeidsforhold for å redusere turnover. Kostnadene per besøk gikk faktisk opp på kort sikt, men brukertilfredshet og medarbeidertrivsel økte dramatisk, og på lang sikt ble tjenesten mer kostnadseffektiv fordi de sløste mindre tid på introduksjon og opplæring.

Et annet eksempel som viser kraften i design thinking for tjenester er arbeidet jeg gjorde med en privat helseklinikk. De slet med at pasienter ikke møtte opp til avtalte timer, noe som skapte både økonomiske tap og forstyrrelser i timeplanen. Den opplagte løsningen ville vært å innføre gebyrer for uteblivelse eller sende flere påminnelser.

Men da vi gravet dypere i brukerreisen, fant vi ut at problemet ofte oppsto fordi pasienter ikke forsto hvor viktig timen var eller hva som ville skje hvis de ikke møtte opp. Mange trodde at fysioterapi var noe man bare kunne dropne inn på når man hadde tid, som en treningstime. Andre var usikre på om de fortsatt trengte behandling fordi de følte seg bedre.

Løsningen ble å redesigne kommunikasjonen rundt timebooking og oppfølging. I stedet for bare å sende en påminnelse om at du har time klokka 14:00 på tirsdag, begynte de å forklare hvorfor akkurat denne timen var viktig i behandlingsforløpet og hva som ville skje hvis den ble avlyst. De introduserte også korte telefongodkjenning døgnet før timen hvor pasienten både ble påminnet og fikk mulighet til å stille spørsmål. Antall uteblivelser falt med over 60%.

Digitale verktøy og design thinking

Som skribent og tekstforfatter har jeg jobbet med mange digitale prosjekter der design thinking har vært avgjørende for suksess. Men jeg har også sett hvordan folk misforstår forholdet mellom design thinking og teknologi. Design thinking er ikke en metode for å lage bedre apper eller nettsider – det er en metode for å løse problemer, og noen ganger er ikke den beste løsningen digital i det hele tatt.

Jeg husker et prosjekt med en norsk utdanningsinstitusjon som ville lage en plattform for å forbedre kommunikasjonen mellom lærere og foreldre. De hadde allerede designet en omfattende løsning med meldingsfunksjoner, kalendere, karakteroversikter, og lekse-planleggere. Men da vi testet prototypen, oppdaget vi at både lærere og foreldre synes det var overveldende.

Det virkelige problemet var ikke mangel på kommunikasjonsmuligheter – det var at begge parter var usikre på når og hvordan de skulle kommunisere med hverandre. Foreldrene var redde for å virke påtrengende hvis de kontaktet læreren for ofte, og lærerne var bekymret for å ikke gi nok informasjon uten å overvelme foreldrene med detaljer.

Løsningen ble mye enklere enn den opprinnelige planen: en fast ukentlig kort oppdatering fra læreren til foreldrene, og en enkel måte for foreldre å stille spørsmål som læreren kunne besvare når det passet. I stedet for en kompleks plattform laget vi en strukturert e-post-tjeneste som automatisk samlet informasjon fra skolens eksisterende systemer og sendte den i et konsistent format.

På femelle.eu har jeg sett mange eksempler på hvordan tekstarbeid blir bedre når det er informert av design thinking-prinsipper. I stedet for å bare skrive tekst som forklarer hva et produkt gjør, starter man med å forstå hvorfor folk skulle være interessert, hvilke spørsmål de har, og hvilken kontekst de befinner seg i når de leser teksten.

Organisatoriske endringer og implementering

En ting er å lære design thinking som metode – noe helt annet er å implementere det i en organisasjon. De fleste norske bedriftene jeg har jobbet med sier de vil være mer innovative og brukersentrerte, men organisasjonsstrukturen og insentivene deres støtter ikke den typen tilnærming.

Det største hinderet er det jeg kaller «ekspertfellen». De fleste organisasjoner er bygget rundt ekspertise – folk blir ansatt fordi de vet mye om sitt fagområde, og de får anerkjennelse for å ha svar på spørsmål. Design thinking krever at man starter med å innrømme at man ikke vet svaret, og det kan være truende for folk som har bygget karrieren sin på å være eksperten.

Jeg jobbet med et ingeniørfirma som ville bruke design thinking i prosjektene sine. Problemet var at ingeniørene var vant til å få spesifikke krav fra klienter og levere tekniske løsninger basert på disse kravene. Design thinking krevde at de stilte spørsmålstegn ved kravene og foreslo helt andre løsninger. Noen av de senior ingeniørene følte at det var som å si at de hadde gjort jobben sin feil i årevis.

Løsningen var å starte med et mindre prosjekt der design thinking-tilnærmingen kunne vise konkrete resultater uten å true noens posisjon eller ekspertise. Vi valgte et prosjekt der klienten selv var frustrert over de tradisjonelle løsningene, så alle var motiverte for å prøve noe nytt. Da prosjektet ble en suksess, ble det lettere å introdusere tilnærmingen i andre deler av organisasjonen.

En annen vanlig utfordring er tidspress og budsjettbegrensninger. Design thinking kan føles som en luksus når man har stramme deadlines og begrensede ressurser. Men min erfaring er at man sparer tid på lang sikt ved å bruke design thinking, fordi man unngår å lage ting som ingen vil ha eller bruke.

Jeg bruker ofte følgende eksempel: det tar kanskje to uker ekstra å kjøre en ordentlig design thinking-prosess i starten av et prosjekt. Men hvis det sparer deg for tre måneder med å bygge feil ting og to måneder med å fikse det etterpå, har du spart fire og en halv måned totalt. Problemet er at de to ukene kommer først og er synlige, mens de fem månedene du sparer kommer senere og er usynlige.

Måling og evaluering av design thinking-resultater

En av utfordringene med design thinking er at det kan være vanskelig å måle suksess på tradisjonelle måter. Hvis du implementerer en ny programvare, kan du måle tid spart eller feilrate. Men hvordan måler du «bedre brukeropplevelse» eller «økt innovasjon»?

Jeg har eksperimentert med forskjellige tilnærminger gjennom årene, og det som fungerer best er å etablere både kvantitative og kvalitative målinger før man starter prosessen. For kvantitative mål kan det være ting som kundetilfredshet, antall kundestøttehenvelser, eller tid brukt på oppgaver. For kvalitative mål kan det være typen tilbakemeldinger man får, medarbeiderengasjement, eller hvor ofte nye ideer blir implementert.

Et konkret eksempel: når vi redesignet onboarding-prosessen for en norsk SaaS-bedrift, målte vi både hvor mange nye brukere som fullførte oppsettet (kvantitativ) og hvordan de beskrev opplevelsen i oppfølgingsintervjuer (kvalitativ). Før redesignet fullførte 45% av nye brukere oppsettet, og de vanligste beskrivelsene var «forvirrende» og «tidkrevende». Etter redesignet fullførte 78% oppsettet, og de vanligste beskrivelsene var «intuitive» og «hjelpsom».

Men kanskje det viktigste målet på suksess er om organisasjonen fortsetter å bruke design thinking-prinsipper etter at det første prosjektet er ferdig. Det er lett å kjøre en workshop og få folk engasjerte, men den reelle testen er om folk endrer hvordan de tenker om problemer i det daglige arbeidet sitt.

Fremtiden for design thinking

Etter å ha jobbet med design thinking i mange år, ser jeg at metodikken fortsetter å utvikle seg og tilpasse seg nye utfordringer. Kunstig intelligens og maskinlæring åpner for nye muligheter i empati-fasen – vi kan analysere større mengder brukerdata enn noen gang før, men vi må fortsatt være forsiktige med ikke å erstatte ekte menneskelig innsikt med dataanalyse.

Jeg har begynt å eksperimentere med hvordan AI kan støtte design thinking-prosesser uten å erstatte den menneskelige delen. For eksempel kan maskinlæring hjelpe oss å identifisere mønstre i brukerdata som kan peke mot interessante områder å utforske videre, men vi trenger fortsatt mennesker til å forstå hvorfor disse mønstrene eksisterer og hva de betyr.

En annen trend jeg ser er at design thinking blir mer distribuert og inkluderende. Tradisjonelt har det vært noe som eksperter eller spesialiserte team har gjort, men nå ser jeg at hele organisasjoner lærer grunnleggende design thinking-ferdigheter. Det er ikke lenger bare designere og innovasjonsteam som tenker brukersentrert – det er alle fra kundeservice til økonomiavdelingen.

Jeg tror også vi vil se design thinking bli brukt til å takle større samfunnsutfordringer. Klimaendringer, urbanisering, eldrebølgen – dette er komplekse problemer som krever den type systemisk tenkning og brukerfokus som design thinking tilbyr. Jeg har allerede begynt å jobbe med offentlige organisasjoner som bruker metodikken til å takle alt fra rusmiddelavhengighet til integreringsutfordringer.

Praktiske tips for å komme i gang

Hvis du har kommet så langt i artikkelen, antar jeg at du er interessert i å prøve design thinking selv. La meg dele noen praktiske tips basert på mine erfaringer med å hjelpe norske bedrifter og organisasjoner å komme i gang.

Det første rådet mitt er: start smått. Ikke prøv å revolutionere hele organisasjonen din i første forsøk. Velg et avgrenset problem som ikke er altfor politisk ladet eller strategisk kritisk. Det ideelle første prosjektet er noe hvor alle er enige om at det nåværende ikke fungerer optimalt, og hvor det er rom for eksperimentering.

For det andre: invester tid i empati-fasen. Jeg kan ikke understreke dette nok. De fleste norske bedriftene jeg jobber med vil hoppe over denne fasen fordi den føles «ineffektiv». Men det er her den reelle læringen skjer. Sett av minst en tredjedel av prosjekttiden din til å forstå problemet før du begynner å løse det.

For det tredje: mal opp tverrfaglige team. Design thinking fungerer best når du har folk med forskjellige perspektiver og kompetanseområder. Men pass på at teamet ikke blir for stort – fem til syv personer er ideelt. Og sørg for at alle forstår at deres rolle er å bidra med sine perspektiver, ikke å representere sine avdelinger.

Her er en enkel struktur du kan bruke for din første design thinking-workshop:

Fase	Tid	Aktiviteter	Resultat
Empathize	2-3 timer	Brukerintervjuer, observasjon, personage utvikling	Dypere forståelse av brukerbehov
Define	1-2 timer	Problem statement, «How might we» spørsmål	Klart definert utfordring
Ideate	1-2 timer	Brainstorming, Crazy 8s, idéprioritering	Liste over potensielle løsninger
Prototype	2-4 timer	Rask byggig av testbare løsninger	Enkel prototype for testing
Test	1-2 timer	Brukertest, tilbakemelding, læring	Innsikt for videre utvikling

Den fjerde tipsen: dokumenter alt, men ikke la dokumentasjon bli viktigere enn læring. Ta bilder av whiteboards, skriv ned sitater fra brukere, beskriv følelser og reaksjoner – ikke bare fakta og konklusjoner. Denne dokumentasjonen blir verdifull senere når du skal kommunisere innsiktene til andre i organisasjonen.

Til slutt: vær tålmodig med deg selv og teamet ditt. Design thinking er ikke en naturlig måte å jobbe på for de fleste norvegere. Vi er vant til å være effektive, planlagte, og målrettede. Design thinking krever at man er komfortable med usikkerhet og åpenhet for å endre retning. Det kan føles frustrerende i begynnelsen, men det blir lettere med praksis.

Vanlige spørsmål om design thinking

Gjennom årene har jeg fått de samme spørsmålene om design thinking gang på gang. La meg ta for meg de vanligste og dele mine erfaringsbaserte svar.

Hvor lang tid tar en design thinking-prosess?

Dette er kanskje det mest stilte spørsmålet, og svaret er: det kommer an på. Jeg har kjørt design thinking-workshops som varer en dag, og jeg har ledet prosesser som har strekt seg over flere måneder. For mindre, avgrenset problemer kan du ofte få verdifulle innsikter på en eller to dager. For komplekse organisatoriske utfordringer eller produktutvikling kan prosessen ta flere uker eller måneder.

Min erfaring er at de fleste team trenger minst tre til fem dager totalt for å kjøre gjennom alle fasene ordentlig – ikke nødvendigvis sammenhengende dager, men totalt. Du kan for eksempel bruke en dag på empati, en uke på å prosessere det du har lært, en dag på define og ideate, en uke på prototyping, og en dag på testing og oppsummering.

Kan design thinking brukes for alle typer problemer?

Nei, og det er viktig å være ærlig om det. Design thinking fungerer best for problemer som er komplekse, tvetydige, og som involverer menneskelig atferd. Det er ikke den beste tilnærmingen for problemene som har klare tekniske løsninger eller der kravene er godt definerte og uforanderlige.

For eksempel: hvis du skal optimalisere en algoritme for å kjøre raskere, er design thinking sannsynligvis ikke den beste metoden. Men hvis du skal forstå hvorfor folk ikke bruker produktet som algoritmen din driver, er design thinking perfekt.

Jeg har også sett design thinking feile når problemet egentlig er organisatorisk eller politisk, men folk behandler det som et designproblem. Hvis hovedutfordringen er at to avdelinger ikke snakker sammen, vil ikke en design thinking-workshop løse det – du trenger organisasjonsutvikling.

Hvordan overbeviser jeg ledelsen om å prøve design thinking?

Dette spørsmålet får jeg mest fra mellomledere og prosjektledere som ser verdien av design thinking, men som slet med å få støtte fra toppen av organisasjonen. Min erfaring er at det sjelden fungerer å snakke om design thinking som en abstrakt metode – ledere bryr seg om resultater, ikke prosesser.

I stedet for å si «vi burde bruke design thinking», prøv å si «vi burde forstå hvorfor våre kunder ikke bruker denne funksjonen før vi bruker mer ressurser på å forbedre den». Eller «kanskje vi burde snakke med faktiske brukere før vi bestemmer hvilke features som skal være i neste versjon».

En annen tilnærming som har fungert for meg er å foreslå et lite pilotprosjekt hvor design thinking-tilnærmingen kan sammenlignes med tradisjonelle metoder. Velg noe hvor dere uansett hadde planlagt å gjøre endringer, og forslå å prøve en annerledes tilnærming for å se om dere får bedre resultater.

Hva hvis brukerne ikke vet hva de vil ha?

Dette er en klassisk innvending, og den er basert på en misforståelse av hva design thinking egentlig handler om. Design thinking handler ikke om å spørre folk hva de vil ha – det handler om å forstå hva de trenger og hvilke problemer de har.

Henry Ford-sitatet jeg nevnte tidligere (om raskere hester) illustrerer poenget perfekt. Folk kunne ikke be om en bil fordi de ikke visste at biler var mulig. Men de kunne beskrive problemene sine med transport – det tok for lang tid, hestene ble slitne, det var dyrt å mate og stelle dem, og så videre. En god design thinking-prosess ville ha fanget opp disse underliggende behovene.

I praksis betyr dette at du stiller åpne spørsmål om folks opplevelser, utfordringer, og frustrasjoner i stedet for å spørre om ønsker og løsninger. «Fortell meg om sist gang du var frustrert med denne prosessen» er mye bedre enn «Hva synes du vi burde endre på denne prosessen?»

Hvordan håndterer man uenighet i teamet?

Uenighet er faktisk et godt tegn i en design thinking-prosess – det betyr at folk kommer med forskjellige perspektiver og innsikter. Problemet oppstår når uenighet blir personlig eller når folk låser seg fast i posisjoner i stedet for å utforske forskjellene.

En teknikk jeg bruker ofte når team ikke blir enige er «assumption mapping». I stedet for å diskutere hvem som har rett, ber jeg teamet liste opp alle antakelsene som ligger bak de forskjellige synspunktene. Deretter prioriterer vi hvilke antakelser som er mest kritiske å teste, og designer enkle eksperimenter for å lære mer.

For eksempel: hvis halvparten av teamet tror at pris er det viktigste for kunder, mens den andre halvparten tror kvalitet er viktigst, kan dere teste begge antakelsene ved å snakke med faktiske kunder om deres beslutningskriterier. Ofte finner dere ut at virkeligheten er mer nyansert enn noen av de opprinnelige posisjonene.

Er design thinking bare rebranding av eksisterende metoder?

Dette er en legitim kritikk som jeg har hørt mange ganger, spesielt fra folk med bakgrunn i antropologi, etnografi, eller tradisjonell markedsanalyse. Det er sant at design thinking ikke oppfant brukersentret tilnærming til problemløsning – designere, antropologer, og andre har brukt lignende metoder i årtier.

Det som gjør design thinking verdifullt er ikke at metodene er nye, men at de er pakket på en måte som gjør dem tilgjengelige for folk som ikke har bakgrunn i design eller samfunnsvitenskap. Design thinking har demokratisert verktøy og tilnærminger som tidligere var forbeholdt spesialister.

Dessuten legger design thinking vekt på tverrfaglig samarbeid og rask iterasjon på en måte som skiller det fra mer akademiske tilnærminger til brukeranalyse. Det er ikke bare å forstå brukere – det er å omsette den forståelsen til konkrete løsninger raskt og effektivt.

Konklusjon: Design thinking som tankesett

Etter alle disse årene med design thinking har jeg kommet til den konklusjonen at den største verdien ikke ligger i de spesifikke metodene eller verktøyene. Det ligger i tankesettet – måten å tilnærme seg komplekse problemer med åpenhet, empati, og vilje til å eksperimentere.

Jeg bruker design thinking-prinsipper i mye mer enn bare formelle workshops og prosjekter. Når jeg skal skrive en vanskelig e-post, starter jeg med å tenke på hvem som skal lese den og hvilken situasjon de er i. Når jeg planlegger et møte, spør jeg meg selv: «Hva trenger deltakerne å få ut av dette, og hvordan kan jeg designe opplevelsen for å støtte det målet?» Når jeg støter på en utfordring i egen bedrift, stopper jeg opp og spør: «Hva er det egentlige problemet her, og hvilke antakelser gjør jeg?»

Design thinking har gjort meg til en bedre problemløser, en bedre samarbeidspartner, og paradoksalt nok, en bedre tekstforfatter. Fordi jeg har lært å starte med brukerens behov i stedet for mine egne ideer, blir tekstene jeg skriver mer relevante og nyttige. Fordi jeg har lært å prototype og teste ideer raskt, sløser jeg mindre tid på konsepter som ikke fungerer.

Men kanskje det viktigste design thinking har lært meg er å være komfortable med usikkerhet. I en verden som endrer seg raskt, er evnen til å navigere i det ukjente og finne kreative løsninger på nye problemer viktigere enn å huske løsninger på gamle problemer. Design thinking er ikke bare en metode for å løse problemer – det er en måte å forberede seg på problemene vi ikke vet at vi kommer til å få.

Så hvis du har kommet så langt i denne artikkelen og lurer på om design thinking er noe for deg eller organisasjonen din, er svaret mitt: prøv det. Start smått, vær tålmodig, og husk at det handler mer om hvordan du tenker enn om hvilke verktøy du bruker. Det verste som kan skje er at du lærer noe nytt om problemene du prøver å løse. Det beste som kan skje er at du oppdager løsninger du aldri hadde tenkt på før.

Og hvem vet? Kanskje design thinking blir den tilnærmingen som hjelper deg å løse det komplekse problemet du har strevet med, eller som åpner dører til innovasjonsmuligheter du ikke visste eksisterte. I en tid hvor mange av utfordringene vi står overfor som enkeltpersoner, organisasjoner, og samfunn krever nytenkning og kreativitet, kan vi ikke råd til å ikke prøve alle verktøyene som er tilgjengelige for oss.