Udformning

Anjali Ariscran

Maria Teixeira

8. august 2026

•

Min Read

Produktdesign vs. Design Sprint: Hvad skal du vælge?

Sammenligning mellem produktdesignprocessen og Google Design Sprint.

Brug vores produktdesignproces, når problemet endnu ikke er defineret, og produktet skal bygges eller gentænkes fra bunden. Kør en Google Design Sprint, når problemet allerede er kendt, og du har brug for en beslutning inden for en uge. Det er hele svaret, og det er forskellen på at tegne planer for et hus og at renovere et rum i et hus, der allerede står. Begge dele er designarbejde. Kun den ene fortæller dig, hvor de bærende vægge er.

Denne artikel sammenligner vores produktdesignproces, som prioriterer bruger- og markedsundersøgelser, før noget bliver bygget, med Google Design Sprint, en femdages metode til at fremskynde en beslutning. Den er skrevet til CTO'en, produktejeren eller grundlæggeren, der skal beslutte, hvilken af de to der skal finansieres, før designarbejdet går i gang.

Produktdesignproces vs. Google Design Sprint i korte træk

	Produktdesignproces (PDP)	Google Design Sprint (GDS)
Varighed	Uger, fordelt på fire faser og tolv designtrin	Fire til fem dage, én fase pr. dag
Involveret team	Produktdesignteam, med kundens forretningsmæssige og tekniske interessenter på definerede tidspunkter	Hele det tværfaglige team i ét rum, plus en navngivet beslutningstager
Udgangspunkt	Problemet er endnu ikke defineret	Problemet er kendt, og teamet har levet med det
Output	Research, wireframes, styleguide, GUI-design, prototype, overordnet arkitektur og projektplan	Én high-fidelity-prototype, testet med slutbrugere
Bedst egnet til	Et produkt bygget fra bunden, eller et eksisterende produkt der gentænkes helt	Et eksisterende produkt, der forbedres funktion for funktion
Største risiko	Tid brugt på research, før noget er synligt	Prototyping baseret på antagelser, der aldrig blev valideret
Kommercielt argument	Realistiske tidsplaner og færre omdesign senere	En beslutning nået på en uge i stedet for et kvartal

Resten af denne artikel gennemgår hver proces, ser nærmere på forskellene og forklarer, hvornår de hver især er mest fordelagtige.

De tolv trin til at skabe et succesfuldt digitalt produkt

Hvor denne sammenligning stammer fra

Vi er ikke nået frem til dette gennem teori. Tilbage i 2014 drev vi en service kaldet The War Room: en produktejer, en designer og et udviklingsteam samlet i ét rum i tre dage for at levere et Minimum Viable Product. I ånden var det en sprint. Resultaterne var blandede. Vi lancerede et par produkter, og de fejlede i første møde med markedet. The Lean Startup og Google Design Sprint stod på alles bogreoler, men alene slog de ikke til i forhold til det arbejde, vi udførte.

Læringen, vi tog med os fra de fiaskoer, var specifik: Et digitalt produkt, der bygges fra bunden, kræver grundig research, før nogen overhovedet begynder at prototype, og dengang fandtes der ingen dokumenteret proces, der forbandt den research med selve leverancen. Så vi byggede en. Det er Produktdesignprocessen, og sammenligningen i denne artikel er den, vi har foretaget projekt for projekt lige siden. Vi udfører stadig sprint-baseret arbejde. Vi ved bare nu, hvilket problem hver enkelt er til for.

Vil du vide mere om, hvordan vi bruger vores produktdesignproces i vores projekter, så tag et kig på vores portfolio!

Hvad er produktdesign?

Interaction Design Foundation definerer produktdesign som den proces, designere bruger til at forene brugernes behov med forretningsmæssige mål, så brands kan skabe konsekvent succesfulde produkter.

Designgrafik, der sammenligner forretningsmål med brugeroplevelsens proces trin som forskning og prototyping.

Tag Uber som eksempel. Problemet er behovet for bekvem og hurtig transport efter behov, og Uber løser det med en app, hvor brugeren trykker på en knap for at bestille en chauffør. Den løsning kombineres derefter med forretningsmæssige mål, såsom prismodeller, der sikrer en bæredygtig indtjening baseret på udbud og efterspørgsel.

Så en produktdesigner bygger broen. På den ene side handler det om, hvordan produktet opfylder brugernes behov ved at sikre en fantastisk brugeroplevelse. På den anden side handler det om, hvad forretningen har brug for, at det tjener.

Hvad det koster at springe produktdesign over

Sagen er den med at springe design over: Du fjerner ikke designbeslutningerne. Du flytter dem over i selve udviklingen, hvor de bliver truffet af den, der koder den pågældende skærm, på selve dagen, uden nogen form for research at holde dem op imod. Det medfører tre ting, og alle tre koster penge.

Den første er omarbejde. En skærm, der er bygget på en antagelse, som ingen har testet, skal bygges om, når antagelsen viser sig ikke at holde – og til den tid er der opstået afhængigheder, der hænger ved den.

Den anden er estimering. Et team, der ikke har set det fulde sæt af skærme, tilstande og integrationer, før de estimerer, estimerer et produkt, de ikke har fået vist. Derfor skrider tidsplanen af årsager, som ingen kunne have forudset.

Den tredje er sammenhæng. Funktioner, der designes én efter én i den rækkefølge, de bliver efterspurgt, skaber et produkt, der virker, men som ikke hænger sammen. Hver efterfølgende tilføjelse må derfor tilpasse sig uoverensstemmelserne i stedet for at følge et mønster. Tænk på et hus: rum tilføjet ét efter ét, hver især efter en ny plan.

Intet af dette ankommer med mærkatet "designproblem". Det ankommer som et leveringsproblem, et budgetproblem og en supportkø. Omkostningerne er ikke hypotetiske: Consortium for Information and Software Quality anslår, at dårlig softwarekvalitet i USA koster omkring 2,41 billioner dollars om året, hvoraf akkumuleret teknisk gæld – prisen for at omarbejde suboptimal software – udgør omkring 1,52 billioner dollars. Mere om de tal senere, for mønsteret bag dem er hele pointen.

Hvad er produktdesignprocessen?

Som vi gennemgår i vores indlæg om de tolv trin til at skabe et succesfuldt produkt, er produktdesignprocessen (PDP) en tværfaglig, brugercentreret proces skabt af Imaginary Cloud. Den kæder eksisterende teknikker sammen, som er modnet over tid i branchen, for at holde designteamets arbejdsgang så effektiv som muligt.

PDP består af fire faser: research, idégenerering, eksekvering og teknisk vurdering, opdelt i tolv trin. Hvert trin producerer noget, som det næste trin har brug for. Det er det, der gør det til design baseret på proces frem for holdninger: rækkefølgen er ikke et spørgsmål om præference, men en afhængighedskæde.

Produkt designproces diagram inklusiv forskning, idéskabelse, eksekvering og teknisk vurdering faser.

Research. Målet er at sikre, at ingen beslutninger hviler på vage antagelser, og at identificere kernen i forretningsmodellen og brugernes behov. Tre trin: briefingen, en aftalt erklæring om, hvad produktet skal bruges til, hvem det er til, og hvordan succes ser ud; brugerresearch, interviews og data om de faktiske brugere, der skaber de behov, designet skal opfylde; samt et design-benchmark, en gennemgang af, hvordan sammenlignelige produkter løser de samme problemer, og hvor de fejler.

Idégenerering. Målet er at formulere produktkonceptet ud fra brugernes behov og forretningsmodellen. Fire trin: brugerrejsen, den fulde sti en bruger tager gennem produktet, før nogen skærme eksisterer; en beslutningsmatrix, en vægtet sammenligning af retninger, der vælger én ud fra fastlagte kriterier frem for den højeste stemme; wireframes, layout med lav detaljegrad, der fastlægger struktur og hierarki før selve det visuelle design; og et moodboard, en referencesamling, der fastlægger den visuelle retning, før en skærm designes.

Eksekvering. Målet er at skabe en fysisk repræsentation af det koncept, der er defineret indtil videre. Tre trin: stilguiden, de komponenter, typografi, farver og regler for afstand, som alle skærme bygges ud fra; grafisk brugerfladedesign (GUI), de færdige skærme tegnet ud fra stilguiden; og prototypen, skærmene forbundet til noget, en bruger kan klikke sig igennem og testes på.

Teknisk vurdering. Målet er at garantere, at alle krav og idéer er realistiske at implementere. To trin: overordnet arkitektur, de systemer, tjenester og integrationer, som designet indebærer, kortlagt før estimering; og projektplanen, rækkefølgen, indsatsen og afhængighederne for at bygge det, estimeret ud fra et design, der allerede eksisterer.

Flowchart over produkt designproces: bruger research, wireframes og prototyping.

Læs også: Designresearch: at påvirke den menneskelige oplevelse, og hvis en første leveringsdygtig version er dit egentlige spørgsmål, de forskellige typer af MVP.

Produktdesignprocessen i praksis: FundSpace

Teori er nemt, så her er processen anvendt på et rigtigt produkt. FundSpace er en finansieringsplatform, der frigør kapital til SMV'er, og de kom til os med en udefineret opgave: byg en webportal, der præsenterer fondenes resultater klart for to meget forskellige målgrupper – fondsadministratorerne, der opretter fondene, og investorerne, der læser rapporterne.

Det er netop tilfældet for hele processen, ikke bare en sprint. Den svære del var ikke en skærm; det var en datastruktur, der skulle kunne modellere fonde, fonde af fonde og fonde af fonde med flere aktieklasser. Vi startede med at bygge en teknisk prototype for at bevise, at en sådan datastruktur overhovedet var mulig, og kørte derefter de fire PDP-faser ovenpå for at tilpasse interfacet til brandet og de to målgrupper. Løsningen blev bygget med Ruby on Rails, React og Node.js og leveret af et dedikeret team bestående af produktorienterede designere, front-end-udviklere og en projektleder.

Tallet, der betyder noget: Det redesignede interface muliggjorde en 10x hurtigere beslutningsproces for både fondsadministratorer og investorer. Platformen opnåede en kundevurdering på 5,0, produktet blev udvalgt til 500 Global's 917Ventures Accelerator-program i 2023, og arbejdet førte til, at Imaginary Cloud blev anerkendt som Top Financial App Developer af Techreviewer. En sprint kunne have testet én skærm af dette på en uge. Den kunne ikke have fundet den datamodel, som hele produktet hviler på. Du kan se FundSpace-casestudiet i sin helhed sammen med sammenlignelige PDP-løsninger for Pulsar Helium og NotaryCam.

E-bogstilbud med UX/UI-designtips til konvertering af hjemmesider med skrivebords-, mobil- og forstørrelsesglasikoner.

Skab engagerende og skræddersyede brugerflader med vores produktdesignproces

Hvad er en Design Sprint?

En Design Sprint er en trinvis proces af en uges varighed, der starter med at kortlægge en udfordring og slutter med en high-fidelity prototype eller et testbart produkt. Produktteams bruger den til hurtigt at teste store idéer og komprimere potentielt måneders arbejde til få dage.

5 faser i en design sprint: Forstå, Skitsere, Beslutte, Prototype og Validere.

I løbet af fire til fem dage har en Design Sprint til formål at hjælpe dig med at forstå ved at kortlægge problemet og vælge et fokusområde; skitsere ved at tegne konkurrerende løsninger; beslutte ved at omdanne idéer til en testbar hypotese; prototype ved at bygge noget realistisk; og validere ved at få feedback fra rigtige brugere. Vi gennemgår hvert af disse punkter herunder.

I løbet af ugen prioriterer sprinten brugerfeedback, så en fungerende prototype når ud til rigtige brugere i starten af produktudviklingen frem for efter lanceringen; den accelererer beslutningsprocessen ved at samle hele teamet i ét rum og udpege én officiel beslutningstager, hvilket forhindrer, at en ugelang sprint bliver til en månedlang diskussion; og den forbedrer samarbejdet ved at sætte hurtig idégenerering, iteration og beslutningstagning i højsædet, så arbejdet ikke går i stå, mens man venter på det næste møde. Disse vaner har tendens til at vare ved efter sprintens afslutning.

Hvad er en Google Design Sprint?

Google Design Sprint (GDS) blev udviklet hos GV, tidligere Google Ventures, som er et investeringsselskab, der tilbyder kapital til teknologivirksomheder i alle faser. Metoden samler forretningsstrategi, innovation, adfærdspsykologi og design thinking i én samlet proces, som et team kan gennemføre på en uge. Den definitive beskrivelse findes i bogen Sprint, skrevet af Jake Knapp sammen med John Zeratsky og Braden Kowitz, som stadig er den vigtigste kilde, man bør læse, før man går i gang.

Processen tager udgangspunkt i Design Thinking – at forstå brugeren, definere problemet og teste løsninger, før man låser sig fast – og søger derefter indsigt gennem hurtige løsninger, prototyping og brugertest. Den består af fem faser, der hver varer mellem en og otte timer.

1. Forstå. Målet er fælles viden, så teamet sammen kan identificere forretningsproblemet. Man samler alle deltagere og deler den eksisterende viden gennem "lightning talks" – korte oplæg på ti til femten minutter om forretningsmål, brugerindsigter, konkurrentoversigter og tekniske muligheder. Vær opmærksom på, hvad denne dag ikke er: Den handler om at udpakke den viden, teamet allerede besidder. Hvis den viden ikke findes endnu, kan en formiddag med oplæg ikke skabe den.

2. Skitsér. En individuel indsats. Alle producerer en detaljeret løsning, typisk på papir, fordi det går hurtigt, er gratis at rette i, og gør det muligt for alle at deltage – også dem, der aldrig har brugt et wireframe-værktøj. Ved store, komplekse problemer kan det være en hjælp at opdele problemet i mindre bidder og give hver person en del. Målet er volumen: Få så mange idéer ned på papir som muligt.

3. Beslut. Her handler det om, hvilken idé der skal videre til prototypen, og hvor jeres løsninger eventuelt strider mod jeres mål og ressourcer. Start med at opstille jeres antagelser om budget, brugere, teknisk formåen og forretningsmæssige drivere. Gennemgå derefter hver idé i forhold til de konflikter, den skaber. De urealistiske løsninger sorteres fra, så de bedste står tilbage og kan bygges ind i et storyboard, der viser hvert interaktionstrin. Dette storyboard bliver specifikationen for jeres prototype.

4. Prototypér. Én dag til at bygge noget, som jeres brugere kan teste. Brug hvad end du er fortrolig med: pap, lim og farver til en fysisk model, eller skitsér den digitalt.

5. Validér. På fjerde eller femte dag inviteres en gruppe slutbrugere til at teste prototypen. Sørg for, at hele teamet observerer, hvordan de interagerer med den – enten live eller via optagelser. Det er også en god idé at inddrage eksperter og interessenter til en gennemgang. Sprinten er lineær, men man opfordres til at revidere og køre processen igen baseret på den læring, man har fået fra den første runde.

Produktdesignproces vs. Google Design Sprint: de vigtigste forskelle

Er den ene rigtig og den anden forkert? Nej. PDP er velegnet til at bygge et produkt fra bunden eller gentænke et eksisterende; GDS er velegnet til et produkt, der allerede er på markedet.

Slack er et godt eksempel. Et sprint forbedrer det langsomt, funktion for funktion. At anvende hele produktdesignprocessen på Slack ville betyde en helt ny tilgang og løsning, hvilket ikke giver mening for et produkt, som millioner af mennesker allerede ved, hvordan man bruger.

Den praktiske forskel ligger i, hvad hver metode giver videre til udviklingsteamet. Et sprint leverer én valideret prototype. De tolv trin leverer et specificeret produkt: skærmbillederne, tilstandene, arkitekturen som designet indebærer, og en plan estimeret ud fra alle tre. En fuld proces understøtter en tidsplan. Et sprint understøtter en beslutning.

Så et Design Sprint er den bedste løsning, når problemet er kendt, når teamet har arbejdet med det, eller når erfaringen allerede fortæller dem, hvad det drejer sig om. Men hvis der ikke er nogen konkrete handlemuligheder, eller målgruppen stadig er ukendt, vil et sprint ikke give brugbare resultater. Der er intet at komprimere til en uge, hvis teamet stadig gætter på, hvad de skal beslutte. Fundamentet skal lægges først, og det er her, produktdesignprocessen viser sit værd.

Beslutningsdiagram, der sammenligner produktdesignprocessen og Google Design Sprint. — Det ene spørgsmål, der afgør, hvad der skal finansieres. Diagram af Imaginary Cloud.

Hvad en CTO reelt beslutter

Prisen for det forkerte valg er ikke designbudgettet. Det er den efterfølgende udvikling. Et sprint baseret på et udefineret problem skaber en prototype, som teamet tror på, men uden bevis for, at problemet var værd at løse. Derfor sker valideringen i udviklingsfasen, til udviklerlønninger, efter at køreplanen allerede er fastlagt.

De økonomiske konsekvenser ved at opdage fejl sent er veldokumenterede, og de er kun vokset. NIST-studiet fra 2002 The Economic Impacts of Inadequate Infrastructure for Software Testing anslog de årlige omkostninger ved softwarefejl for den amerikanske økonomi til 59,5 milliarder dollars og tilskrev cirka en tredjedel af dette til mangler, der kunne være fundet tidligere. To årtier senere anslår Consortium for Information and Software Qualitys rapport fra 2022 omkostningerne ved dårlig softwarekvalitet i USA til omkring 2,41 billioner dollars om året, med en akkumuleret teknisk gæld på nær 1,52 billioner dollars. Tallet faldt ikke i takt med, at software modnedes; det voksede med en faktor på cirka fyrre, fordi software blev fundamentet for alt. Mønsteret er det samme, som produktteams ser i deres egen skala: jo senere en forkert antagelse opdages, jo mere er der bygget ovenpå den.

Hver gang en ny idé bliver prototypet oven på forældede krav, skal meget af det allerede udførte arbejde redesignes. Tvinger man det ekstra arbejde igennem, får man et produkt, der virker lappet sammen frem for bygget som en helhed. Som rum tilføjet ét efter ét, hver efter en forskellig plan. Holdt op mod et sprint på fire til fem dage er de uger, en fuld designproces tager, den billigste halvdel af sammenligningen, fordi de betales én gang, før estimatet, frem for gentagne gange i en kodebase.

Det er derfor, vi hos Imaginary Cloud opdeler processen i logiske faser, der følger en fast rækkefølge. PDP balancerer designkvalitet mod omkostninger og en hurtig lancering, så det, der når markedet, både er brugbart og leveret efter en tidsplan, som forretningen har godkendt.

Ofte stillede spørgsmål

Hvor lang tid tager produktdesignprocessen?

Den strækker sig over fire faser og tolv trin, så den måles i uger frem for dage. Research og idégenerering optager det meste af tiden, da de resterende trin afhænger af netop disse.

Hvor lang tid tager en Google Design Sprint?

Fire til fem dage, én fase om dagen, hvor hver fase tager mellem en og otte timer.

Hvornår bør man ikke køre en design sprint?

Når problemet ikke er defineret, eller målgruppen er ukendt. En sprint komprimerer beslutningsprocessen, og der er intet at komprimere, hvis teamet stadig gætter på, hvad de skal beslutte.

Kan man kombinere en Design Sprint med produktdesignprocessen?

Ja, og for et etableret produkt er det ofte tilfældet. Produktdesignprocessen lægger fundamentet, hvorefter sprints forbedrer de enkelte funktioner, når problemstillingen er forstået.

Hvilken metode er den rette til et eksisterende produkt?

Google Design Sprint, hvis produktet forbedres trinvist, og problemet allerede er kendt. Produktdesignprocessen, hvis produktet skal gentænkes fuldstændigt, da det i så fald reelt er et nyt produkt.

Hvad får man helt konkret ud af hver proces?

En Design Sprint afsluttes med én high-fidelity prototype, der er testet af brugere. Produktdesignprocessen afsluttes med research, wireframes, en style guide, GUI-design, en prototype, en overordnet arkitektur og en projektplan.

Alt koger ned til ét spørgsmål: Ved du, hvad problemet er? Hvis ja, så kør en sprint. Hvis nej, så find ud af det først, for det kan ingen prototype fortælle dig.

‍

Hvis du hellere vil tale det igennem, så fortæl os om dit produkt og vi vil fortælle dig, hvilken af de to tilgange der passer bedst. Du kan også gennemse vores fulde portefølje af projekter for at se processen i praksis.