Produktdesign vs. Google Design Sprint: Vad ska du välja?

Utformning

Jämförelse mellan produktdesignprocessen och Google Design Sprint.

Använd vår produktutvecklingsprocess när problemet ännu inte är definierat och produkten byggs eller tänks om från grunden. Kör en Google Design Sprint när problemet redan är känt och du behöver ett beslut inom en vecka. Det är hela svaret, och det är skillnaden mellan att rita ritningar till ett hus och att renovera ett rum i ett hus som redan står. Båda är designarbete. Bara en av dem talar om för dig var de bärande väggarna finns.

Den här artikeln jämför vår produktutvecklingsprocess, som prioriterar användar- och marknadsundersökningar innan något byggs, med Google Design Sprint, en femdagarsmetod för att påskynda beslutsfattande. Den är skriven för CTO:n, produktägaren eller grundaren som ska avgöra vilken av de två som ska finansieras innan designarbetet påbörjas.

Produktdesignprocessen kontra Google Design Sprint i korthet

	Produktdesignprocess (PDP)	Google Design Sprint (GDS)
Tidsåtgång	Veckor, fördelade på fyra faser och tolv designsteg	Fyra till fem dagar, en fas per dag
Involverat team	Produktdesignteam, med kundens affärsmässiga och tekniska intressenter vid definierade tillfällen	Hela det tvärfunktionella teamet i ett rum, plus en utsedd beslutsfattare
Utgångspunkt	Problemet är ännu inte definierat	Problemet är känt och teamet har levt med det
Leverabler	Research, wireframes, stilguide, GUI-design, prototyp, övergripande arkitektur och projektplan	En high-fidelity-prototyp, testad med slutanvändare
Bäst lämpad för	En produkt som byggs från grunden, eller en befintlig som tänks om helt	En befintlig produkt som förbättras, funktion för funktion
Största risk	Tid som läggs på research innan något syns	Prototypbygge baserat på antaganden som aldrig validerades
Kommersiellt argument	Realistiska tidsplaner och färre omdesigners senare	Ett beslut fattat på en vecka i stället för ett kvartal

Resten av den här artikeln förklarar varje process, går igenom skillnaderna och när respektive metod är mest fördelaktig.

De tolv stegen för att skapa en framgångsrik digital produkt

Varifrån den här jämförelsen kommer

Vi kom inte fram till detta genom teori. År 2014 drev vi en tjänst som hette The War Room: en produktägare, en designer och ett utvecklingsteam i samma rum under tre dagar för att leverera en Minimum Viable Product. Det var, i sin anda, en sprint. Resultaten var blandade. Vi lanserade några produkter, men de misslyckades i första mötet med marknaden. The Lean Startup och Google Design Sprint fanns i allas bokhyllor, men var för sig räckte de inte till för det arbete vi utförde.

Lärdomen vi drog av dessa misslyckanden var tydlig: en digital produkt som byggs från grunden kräver gedigen research innan man börjar prototypa, och vid den tiden fanns ingen dokumenterad process som kopplade samman research med leverans. Så vi skapade en. Det är vår produktdesignprocess, och jämförelsen i den här artikeln är den vi har gjort, projekt för projekt, ända sedan dess. Vi arbetar fortfarande med sprintliknande metoder. Vi vet bara nu vilket problem varje metod är till för.

Vill du veta mer om hur vi tillämpar vår designprocess i våra projekt? Besök vår portfolio!

Vad är produktdesign?

Interaction Design Foundation definierar produktdesign som den process där formgivare förenar användarbehov med affärsmål för att hjälpa varumärken att skapa konsekvent framgångsrika produkter.

Designgrafik som visar affärsmål kontra process steg i användarupplevelsen som forskning och prototypframtagning.

Ta Uber som exempel. Problemet är behovet av smidig och snabb transport på begäran, och Uber löser det med en app där användaren trycker på en knapp för att beställa en förare. Den lösningen kombineras sedan med affärsmål, som prismodeller som når hållbara intäkter baserat på utbud och efterfrågan.

Produktdesignern bygger alltså bron. På ena sidan handlar det om hur produkten möter användarnas behov genom att säkerställa en fantastisk användarupplevelse. På den andra sidan handlar det om vad verksamheten behöver för att nå lönsamhet.

Vad det kostar att hoppa över produktdesign

Det är så här det ligger till med att hoppa över design: du tar inte bort designbesluten. Du flyttar dem till utvecklingsfasen, där de fattas av den som råkar koda skärmen just den dagen, helt utan research att luta sig mot. Tre saker följer, och alla tre kostar pengar.

Det första är omarbete. En skärm som byggts på ett antagande som ingen testat måste byggas om när antagandet visar sig vara fel, och vid det laget har den hunnit få en mängd beroenden.

Det andra är tidsuppskattning. Ett team som inte har sett alla skärmar, tillstånd och integrationer innan de gör sin uppskattning estimerar en produkt de inte har fått se, vilket gör att tidsplanen spricker av orsaker som ingen kunde förutse.

Det tredje är helhet. Funktioner som designas en och en, i den ordning de efterfrågas, skapar en produkt som fungerar men som inte hänger ihop. Varje ny funktion måste sedan anpassas efter inkonsekvenserna istället för efter ett enhetligt mönster. Tänk dig ett hus där rummen lagts till ett i taget, vart och ett efter en egen ritning.

Inget av detta presenteras som ett designproblem. Det visar sig som ett leveransproblem, ett budgetproblem och en växande supportkö. Kostnaden är inte hypotetisk: Consortium for Information and Software Quality uppskattar kostnaden för dålig mjukvarukvalitet i USA till cirka 2,41 biljoner dollar per år, där ackumulerad teknisk skuld – priset för att omarbeta undermålig mjukvara – står för ungefär 1,52 biljoner dollar. Mer om de siffrorna senare, för mönstret bakom dem är hela poängen.

Vad är produktdesignprocessen?

Som vi går igenom i vårt inlägg om de tolv stegen för att skapa en framgångsrik produkt, är produktdesignprocessen (PDP) en tvärvetenskaplig, användarcentrerad process skapad av Imaginary Cloud. Den länkar samman etablerade tekniker som mognat i branschen över tid för att hålla designteamets arbetsflöde så effektivt som möjligt.

PDP består av fyra faser – research, idégenerering, utförande och teknisk utvärdering – uppdelade i tolv steg. Varje steg producerar något som nästa steg behöver. Det är det som gör det till design genom process snarare än genom åsikter: ordningsföljden är inte en preferens, det är en beroendekedja.

Diagram över produkt design process inklusive forskning, idé kläckning, genomförande och teknisk bedömning faser.

Research. Målet är att säkerställa att inga beslut vilar på vaga antaganden, samt att identifiera kärnan i affärsmodellen och användarnas behov. Tre steg: briefingen, en överenskommen beskrivning av vad produkten ska göra, vem den är till för och vad som definierar framgång; användarresearch, intervjuer och data om de faktiska användarna som genererar de behov designen måste svara mot; samt ett design-benchmark, en genomgång av hur jämförbara produkter löser samma problem och var de brister.

Idégenerering. Målet är att formulera produktkonceptet utifrån användarnas behov och affärsmodellen. Fyra steg: användarresan, den kompletta väg en användare tar genom produkten innan några skärmar ens finns; en beslutsmatris, en poängsatt jämförelse av olika inriktningar som väljer en väg baserat på fastställda kriterier snarare än på den som ropar högst; wireframes, enkla layouter som fastställer struktur och hierarki innan någon visuell design påbörjas; samt en moodboard, en referenssamling som fastställer den visuella inriktningen innan en skärm designas.

Utförande. Målet är att skapa en konkret representation av det koncept som hittills definierats. Tre steg: stilguiden, de komponenter, typsnitt, färger och avståndsregler som varje skärm byggs utifrån; grafiskt användargränssnitt (GUI), de färdiga skärmarna ritade enligt stilguiden; samt prototypen, skärmarna sammanlänkade till något som en användare kan klicka sig igenom och testas på.

Teknisk utvärdering. Målet är att garantera att varje krav och idé är realistisk att implementera. Två steg: övergripande arkitektur, de system, tjänster och integrationer som designen kräver, kartlagda före estimering; samt projektplanen, ordningsföljden, arbetsinsatsen och beroendena för att bygga produkten, estimerad utifrån en design som redan existerar.

Flödesschema över produkt designprocess: användarundersökning, wireframes och prototypframtagning.

Läs även: Design Research: påverka den mänskliga upplevelsen, och om en första lanseringsbar version är vad du egentligen undrar över, de olika typerna av MVP.

Produktdesignprocessen i praktiken: FundSpace

Teori är enkelt, så här är processen tillämpad på en verklig produkt. FundSpace är en finansieringsplattform som frigör kapital för små och medelstora företag. Uppdraget kom till oss som ett odefinierat problem: bygg en webbportal som tydligt redovisar fondprestanda för två vitt skilda målgrupper – fondförvaltarna som skapar fonderna och investerarna som läser rapporterna.

Det är precis vad som krävs för hela processen, inte bara en sprint. Det svåra var inte en enskild skärm, utan en datastruktur som behövde modellera fonder, fond-i-fonder och fond-i-fonder med flera olika andelsklasser. Vi började med att bygga en teknisk prototyp för att bevisa att en sådan databas ens var möjlig, och körde sedan de fyra PDP-faserna ovanpå den för att anpassa gränssnittet till varumärket och de två målgrupperna. Bygget använde Ruby on Rails, React och Node.js, och levererades av ett dedikerat team bestående av produktorienterade designers, frontend-utvecklare och en projektledare.

Siffran som betyder något: det omdesignade gränssnittet möjliggjorde en 10 gånger snabbare beslutsprocess för både fondförvaltare och investerare. Plattformen fick ett kundbetyg på 5,0 och produkten valdes ut till 500 Globals 917Ventures Accelerator-program 2023, och arbetet ledde till att Imaginary Cloud blev utsedd till en av de främsta utvecklarna av finansiella appar av Techreviewer. En sprint hade kunnat testa en skärm av detta på en vecka. Den hade inte kunnat hitta den datamodell som hela produkten vilar på. Du kan se FundSpace-casestudien i sin helhet, tillsammans med jämförbara PDP-byggen för Pulsar Helium och NotaryCam.

E-bokserbjudande med UX/UI-designtips för webbplatskonvertering med skrivbords-, mobil- och förstoringsglasikoner.

Skapa engagerande och skräddarsydda gränssnitt med vår process för produktdesign

Vad är en Design Sprint?

Design Sprint är en strukturerad process på en vecka som börjar med att kartlägga en utmaning och slutar med en högupplöst prototyp eller en testbar produkt. Produktteam använder metoden för att snabbt testa stora idéer och komprimera månader av arbete till bara några dagar.

5 faser i en design sprint: Förstå, Skissa, Besluta, Prototypa och Validera.

Under fyra till fem dagar hjälper Design Sprint dig att förstå genom att kartlägga problemet och välja ett fokusområde; skissa genom att ta fram konkurrerande lösningar; besluta genom att omvandla idéer till en testbar hypotes; prototypa genom att bygga något realistiskt; och validera genom att få feedback från riktiga användare. Vi går igenom varje steg nedan.

Under veckans gång prioriterar sprinten användarfeedback så att en fungerande prototyp når riktiga användare tidigt i produktutvecklingen istället för efter lansering; den accelererar beslutsprocessen genom att samla hela teamet i ett rum och utse en officiell beslutsfattare, vilket förhindrar att en veckolång sprint förvandlas till en månadslång diskussion; och den förbättrar samarbetet genom att prioritera snabb idégenerering, iteration och beslutsfattande så att arbetet inte stannar av i väntan på nästa möte. Dessa arbetsvanor tenderar att leva kvar långt efter att sprinten är avslutad.

Webb- och mobilutvecklingsbanner: isometrisk skärm och mobilapp med React-logotyp.

Vad är en Google Design Sprint?

Google Design Sprint (GDS) utvecklades på GV, tidigare Google Ventures, riskkapitalbolaget som investerar i teknikföretag i allt från såddfas till tillväxtfas. Metoden förenar affärsstrategi, innovation, beteendevetenskap och design thinking till en process som ett team kan genomföra på en vecka. Den definitiva beskrivningen finns i boken Sprint, skriven av Jake Knapp tillsammans med John Zeratsky och Braden Kowitz, vilken förblir den främsta källan att läsa innan man kör sin första sprint.

Processen bygger på Design Thinking – att förstå användaren, rama in problemet och testa lösningar innan man bestämmer sig – och söker sedan insikter genom snabba lösningar, prototyper och användartester. Den består av fem faser, där varje fas tar ungefär en till åtta timmar.

1. Förstå. Målet är delad kunskap så att teamet gemensamt kan identifiera affärsproblemet. Du samlar alla och går igenom vad de redan vet genom "lightning talks" – korta genomgångar på tio till femton minuter om affärsmål, insikter från användarundersökningar, en överblick av konkurrenter och tekniska möjligheter. Notera vad den här dagen inte är: den handlar om att packa upp kunskap som teamet redan besitter. Om den kunskapen inte finns än, kommer en förmiddag med lightning talks inte att skapa den.

2. Skissa. En individuell insats. Alla tar fram en detaljerad lösning, oftast på papper, eftersom papper är snabbt, kostnadsfritt att ändra och gör att hela teamet kan delta, även de som aldrig har använt ett wireframe-verktyg. För stora, komplexa problem kan det hjälpa att dela upp problemet i mindre delar och ge varje person en del. Syftet är volym: få ner så många idéer som möjligt.

3. Besluta. Det här handlar om vilken idé som ska gå vidare till prototypstadiet, och var dina lösningar kan krocka med era mål och resurser. Börja med att lista era antaganden om budget, användare, teknisk kapacitet och affärsdrivande faktorer. Gå sedan igenom varje idé utifrån vilka konflikter den skapar. De ogenomförbara alternativen sållas bort, och kvar blir de bästa som byggs in i en storyboard som visar varje interaktion steg för steg. Den storyboarden blir specifikationen för din prototyp.

4. Prototyp. En dag för att bygga något som dina användare kan testa. Använd det du känner dig bekväm med: kartong, lim och färg för att bygga fysiskt, eller skissa digitalt.

5. Validera. På dag fyra eller fem bjuder du in en grupp slutanvändare för att testa prototypen. Se till att hela teamet observerar hur de interagerar med den, antingen live eller via inspelningar. Det är även värdefullt att ta in experter och intressenter för en genomgång. Sprinten är linjär, men du uppmuntras att revidera och köra igen baserat på vad den första sprinten lärde er.

Produktdesignprocessen kontra Google Design Sprint: de största skillnaderna

Är den ena rätt och den andra fel? Nej. PDP passar för att bygga en produkt från grunden eller för att tänka om en befintlig; GDS passar för en produkt som redan finns på plats.

Slack är ett bra exempel. En sprint förbättrar den långsamt, funktion för funktion. Att tillämpa hela produktdesignprocessen på Slack skulle innebära ett helt nytt tillvägagångssätt och en ny lösning, vilket inte är rimligt för en produkt som miljontals människor redan vet hur man använder.

Den praktiska skillnaden ligger i vad som överlämnas till utvecklingsteamet. En sprint resulterar i en validerad prototyp. De tolv stegen resulterar i en specificerad produkt: skärmar, tillstånd, den arkitektur som designen kräver samt en tidsplan baserad på allt detta. En fullständig process stöder en tidsplan. En sprint stöder ett beslut.

En Design Sprint är alltså det bästa alternativet när problemet är känt, när teamet har levt med det eller när erfarenheten redan har gett dem svaren. Men om det saknas konkreta handlingsalternativ, eller om målgruppen fortfarande är okänd, kommer en sprint inte att ge användbara resultat. Det finns inget att komprimera till en vecka om teamet fortfarande gissar vad de ska besluta om. Grunden måste läggas först, och det är där produktdesignprocessen visar sitt värde.

Beslutsdiagram som jämför produktdesignprocessen och Google Design Sprint. — Den enda frågan som avgör vad som ska finansieras. Diagram av Imaginary Cloud.

Vad en CTO faktiskt fattar beslut om

Kostnaden för ett felaktigt val är inte designbudgeten. Det är utvecklingsarbetet som följer. En sprint som körs baserat på ett odefinierat problem resulterar i en prototyp som teamet tror på, men utan bevis för att problemet var värt att lösa. Valideringen sker därför i utvecklingsfasen, till utvecklingskostnad, efter att färdplanen redan har fastställts.

De ekonomiska konsekvenserna av att upptäcka fel sent är väldokumenterade, och de har bara ökat. NIST-studien från 2002 The Economic Impacts of Inadequate Infrastructure for Software Testing uppskattade den årliga kostnaden för mjukvarufel för den amerikanska ekonomin till 59,5 miljarder dollar, och tillskrev ungefär en tredjedel av detta till defekter som kunde ha upptäckts tidigare. Två decennier senare visar Consortium for Information and Software Qualitys rapport från 2022 att kostnaden för bristande mjukvarukvalitet i USA uppgår till cirka 2,41 biljoner dollar per år, med en ackumulerad teknisk skuld på nära 1,52 biljoner dollar. Siffran minskade inte i takt med att mjukvaran mognade; den växte med en faktor på ungefär fyrtio, eftersom mjukvara blev grundbulten i allt. Mönstret är detsamma som produktteam ser i sin egen skala: ju senare ett felaktigt antagande upptäcks, desto mer har hunnit byggas ovanpå det.

Varje gång en ny idé prototypas ovanpå bristfälliga krav måste mycket av det som redan gjorts designas om. Tvinga fram det omarbetet och du får en produkt som ser ihop-lappad ut snarare än byggd som en helhet. Som rum som lagts till ett efter ett, vart och ett efter en egen ritning. Ställt mot en sprint på fyra till fem dagar är de veckor en fullständig designprocess tar den billigare halvan av jämförelsen, eftersom de betalas en gång, före estimeringen, snarare än upprepade gånger mot en kodbas.

Det är därför vi på Imaginary Cloud delar upp processen i logiska faser som följer en viss ordning. PDP balanserar designkvalitet mot kostnad och en snabb marknadslansering, så att det som når marknaden både är användbart och levereras enligt en tidsplan som verksamheten har godkänt.

Vanliga frågor

Hur lång tid tar produktdesignprocessen?

Den omfattar fyra faser och tolv steg, så den mäts i veckor snarare än dagar. Research och idégenerering tar störst del av tiden, eftersom de övriga stegen bygger på dessa.

Hur lång tid tar en Google Design Sprint?

Fyra till fem dagar, en fas per dag, där varje fas tar ungefär en till åtta timmar.

När bör man inte köra en design sprint?

När problemet inte är definierat eller målgruppen är okänd. En sprint komprimerar beslutsfattandet, och det finns inget att komprimera om teamet fortfarande gissar vad det är de ska besluta om.

Kan man kombinera en Design Sprint med produktdesignprocessen?

Ja, och för en etablerad produkt är det det vanligaste upplägget. Produktdesignprocessen lägger grunden, och sedan används sprintar för att förbättra enskilda funktioner när problemområdet väl är förstått.

Vilken metod passar bäst för en befintlig produkt?

Google Design Sprint om produkten förbättras stegvis och problemet redan är känt. Produktdesignprocessen om produkten ska tänkas om helt, eftersom det i det läget i praktiken är en ny produkt.

Vad får man egentligen ut av respektive metod?

En Design Sprint avslutas med en högupplöst prototyp som testats med användare. Produktdesignprocessen avslutas med research, wireframes, en stilguide, GUI-design, en prototyp, en övergripande arkitektur och en projektplan.

Allt kokar ner till en fråga: vet du vad problemet är? Om svaret är ja, kör en sprint. Om svaret är nej, ta reda på det först, för ingen prototyp kommer att kunna ge dig det svaret.

‍

Om du hellre vill prata igenom saken, berätta om din produkt så hjälper vi dig att avgöra vilken av de två metoderna som passar bäst. Du kan även titta igenom vår fullständiga projektportfölj för att se hur processen fungerar i praktiken.

Staplar av orange böcker med titeln "Product Design Process", en handbok för digital produktdesign.

The word Amazon in white text on a solid blue background.

Anjali Ariscrisnã

Mångsidig och datadriven tillväxtmarknadsförare med fördjupad affärskunskap, uppdaterad med den senaste utvecklingen inom det digitala marknadsföringslandskapet.

‍

Läs fler inlägg av denna författare