Written by:
Last Published:
9 augusti 2026
•
Produktdesignprocessen är den sekvens ett team följer för att omvandla ett marknadsproblem till en fungerande digital produkt. Vår kallas Product Design Process (PDP). Den omfattar fyra faser (research, idégenerering, utförande och teknisk utvärdering) uppdelade i tolv steg, där varje steg har en ansvarig person och ett leverabelt som nästa steg är beroende av.
Se det som mise en place. Allt är hackat, uppmätt och inom räckhåll innan pannan ens kommer i närheten av värmen.
Det här inlägget förklarar vad produktdesign är, varför sekvensen är viktig och vad som händer i vart och ett av de tolv stegen i designprocessen. Det är skrivet för grundare, produktägare och företagsledare som ska besluta hur mycket designarbete som ska finansieras innan en enda rad kod skrivs.
Vi håller inte metoden för oss själva. Den är publicerad i sin helhet, med alla faser och praktiska exempel, i vår bok om produktdesignprocessen, skriven av tre av personerna som skapade och driver den på Imaginary Cloud. Det som följer är arbetsversionen av den metoden, samma metod som ligger bakom vår digitala produktdesign.
| Fas | Steg | Ansvarig | Leverabel |
|---|---|---|---|
| Research | 1. Briefing | UX-designer | Gemensam beskrivning av vision, mål och affärskrav |
| Research | 2. Användarresearch | UX-designer | Målgruppsprofil, mål och drivkrafter |
| Research | 3. Designbenchmark | UX-designer | Översikt över konkurrerande och kompletterande produkter |
| Idégenerering | 4. Användarresa | UX-designer med produktägare | Kartlagda användarscenarier och produktkrav |
| Idégenerering | 5. Beslutsmatris | Produktägare med UX-designer | Prioriterat omfång inom tids- och kostnadsram |
| Idégenerering | 6. Wireframes | UX-designer | Skärmstruktur och navigeringsflöde |
| Idégenerering | 7. Moodboard | Produktdesigner | Överenskommet visuellt uttryck (look and feel) |
| Genomförande | 8. Styleguide | Produktdesigner | Färgpalett, typsnitt, bildstil, gränssnittskomponenter |
| Genomförande | 9. GUI-design | Produktdesigner | Slutgiltiga skärmar, godkända av intressenter |
| Genomförande | 10. Prototyp | Produktdesigner | Delbar klickbar prototyp |
| Teknisk utvärdering | 11. Övergripande arkitektur | Tech lead | Teknisk design och tredjepartsberoenden |
| Teknisk utvärdering | 12. Projektplan | Tech lead med produktägare | Milstolpar, arbetsinsats och beräknad kostnad per fas |
Produktdesign handlar om att bestämma vad en produkt ska göra, för vem och hur den ska fungera, innan någon bygger den. I PDP resulterar det arbetet i tolv namngivna leverabler, från en användarprofil till en projektplan med tillhörande kostnader. (Se vår korta definition av produktdesignprocessen.)
Begreppet överlappar ofta med industriell produktdesign, som omfattar varor som tillverkas genom massproduktion: en iPhone, en brödrost, en gitarr, en stol. Den här artikeln handlar om digital produktdesign, som är en underkategori till detta. En digital produkt är en immateriell vara som finns online, till exempel en webbplats eller en app.
Handlar design alltså om hur en produkt ser ut? Inte främst, nej. Estetik spelar roll, men design handlar mest om hur produkten fungerar.
Den distinktionen får praktiska konsekvenser. Steg 1 till 7 i PDP, alltså mer än hälften, innebär ingen visuell design alls. De resulterar i en användarprofil, ett riktmärke, en användarresa, en prioriterad omfattning och en wireframe. Först därefter väljer någon en färg.
Produktdesignern tar reda på vilka användare produkten är till för och vad de försöker uppnå, för att sedan omvandla det till något användbart. Det första steget i produktdesignprocessen är att identifiera slutanvändarnas problem, vilket är anledningen till att användarundersökningar är steg 2 i PDP och inte en skärm.
Att veta vem som ska använda produkten är lika viktigt som att veta vilket problem den löser. Samma problem får olika lösningar beroende på vem som har det.
Titeln omfattar flera olika arbetsfunktioner. En UI-utvecklare, en UX-designer, en interaktionsdesigner, en upplevelsedesigner och en prototypare faller alla under kategorin produktdesigner. Olika företag drar gränserna på olika sätt, vilket är anledningen till att PDP anger en ansvarig för varje steg istället för att förlita sig på yrkestitlar.
Att bygga fel sak på rätt sätt är det dyraste misstaget ett produktteam kan göra. Det är också det resultat som en ostrukturerad arbetsprocess mest tillförlitligt leder till.
Vi vet, för vi har gjort det själva. Projekten som beskrivs nedan levererades i tid och enligt specifikation, men misslyckades ändå på marknaden eftersom ingen hade tagit reda på vad marknaden faktiskt ville ha innan utvecklingen påbörjades.
Design är det som överbryggar det gapet. Att göra det på rätt sätt kräver affärsanalys, användarundersökningar, förståelse för hur människor faktiskt beter sig och tillräcklig teknisk kunskap för att kunna skilja en bra idé från en dyrköpt sådan.
Motsatsen är lika påtaglig. En app kan vila på en genuint smart idé och ändå misslyckas om navigeringen förvirrar användarna, upplevelsen känns seg och slutanvändaren inte kan hantera den. En fantastisk idé förblir aldrig mer än en idé om produktdesignen inte möter slutanvändarnas önskemål.
Låt oss dela med oss av lite av Imaginary Clouds historia. År 2014 designade vi en tjänst som vi kallade "The War Room". Löftet var att samla en produktägare, en designer och ett utvecklarteam i ett rum under tre dagar för att leverera en MVP (Minimum Viable Product).
Resultaten var ojämna. Vi levererade några projekt, men alla misslyckades vid den första kontakten med marknaden. Eran av "bygg det, så kommer de" var sedan länge förbi. The Lean Startup och Google Design Sprint fanns i allas bokhyllor och bokmärken, men ingen av dem räckte till på egen hand.
Vid det laget insåg vi att digitala produkter kräver omfattande research innan de byggs. Och det fanns ingen dokumenterad designprocess som vi kunde använda. Så vi skapade en egen: Product Design Process (PDP).
PDP är en samling etablerade tekniker som mognat med tiden inom branschen och som länkats samman för att göra produktdesignteamets arbetsflöde så effektivt som möjligt.
Än idag utgör vår Product Design Process kärnan i hur vi levererar digitala produkter, och det är processen bakom varje projekt i vår portfölj.
Product Design Process (PDP) är en användarcentrerad designprocess för digitala produkter som bygger på ett tvärvetenskapligt arbetssätt. Huvudmålet är att snabbt få ut produkter på marknaden utan att för den sakens skull hoppa över det underlag som bör ligga till grund för besluten. Processen fungerar lika bra för projekt som fokuserar på tillväxt genom optimering.
Vår vision är enkel. Vi vill leverera den bästa tillgängliga lösningen på ett specifikt problem, på en marknad där de flesta konkurrerande produkter lanseras utan en sådan.
Den första fasen av PDP ligger på UX-designerns ansvar. Målet är att samla in underlag som stödjer varje beslut som fattas framöver, så att inget vilar på vaga antaganden. Det är här de viktigaste aspekterna av affärsmodellen och användarnas behov identifieras.
1. Briefing. Säkerställer att hela teamet är införstått med projektets vision, mål och affärskrav, samt har tillgång till all relevant information.
2. Användarresearch. Användarprofilen diskuteras med produktens intressenter. Att definiera målgruppens profil hjälper till att identifiera deras främsta mål och drivkrafter. Användarresearch garanterar att produkten är användbar och effektiv ur ett användarperspektiv.
3. Designbenchmark. Teamet granskar liknande och kompletterande produkter, deras designmönster och den underliggande tekniken. Denna genomgång visar var den nya produkten kan placeras på marknaden, vilka konventioner användarna förväntar sig, samt vilka funktioner och designval som verkligen får den att sticka ut.
Ideation är kärnan i den kreativa processen. Det är här produktkonceptet formuleras utifrån användarnas behov och affärsmodellen, vilka båda identifierats i researchfasen. Här bör UX-designern, produktdesignern och produktägaren arbeta i nära samarbete.
4. Användarresa. Den ideala användarupplevelsen kartläggs genom att beskriva varje användaråtgärd. Olika användarscenarier skrivs och valideras. Detta ger en helhetsbild av upplevelsen, säkerställer konsekvens och flöde, och fungerar som en grund för att fastställa produktkraven.
5. Beslutsmatris. Beslutsmatrisen poängsätter varje potentiell funktion utifrån två axlar: hur viktig den är för användaren och verksamheten, samt hur mycket tid och pengar den kostar att bygga. Det som överlever poängsättningen utgör den omfattning som realistiskt kan lanseras inom givna ramar i produktens nuvarande skede. Det som inte överlever dokumenteras istället för att glömmas bort.
6. Wireframes. Här börjar skelettet för skärmarna att ritas upp. Sidstrukturen och navigeringsflödet fastställs, vilket bestämmer var varje innehållsdel ska placeras innan den formges, vilket i sin tur förenklar det efterföljande designarbetet.
7. Moodboard. Säkerställer att produktens utseende och känsla förmedlar den önskade upplevelsen och är i linje med användarprofilen och marknadsstrategin. Detta steg fångar produktens "stämning" genom en samling bilder, ord och andra visuella element.
I denna fas omvandlar produktdesignern det koncept som hittills fastställts till skärmar som användare faktiskt kan titta på och klicka sig igenom.
8. Stilguide. Det är här det grafiska gränssnittet får sina regler: färgpalett, typsnitt, bildstil, inmatningsfält, knappar och så vidare. Genom att fastställa dessa val en gång, i ett och samma dokument, säkerställs att varje skärm i applikationen är visuellt konsekvent med nästa.
9. Design av grafiskt användargränssnitt (GUI). De slutgiltiga skärmarna tas fram genom att tillämpa stilguiden på wireframes. Det nionde steget ger intressenter en bild av hur produktens skärmar kommer att se ut, så att de kan godkänna designen innan implementeringen påbörjas.
10. Prototyp. En klickbar prototyp tas fram, som är tillgänglig online och kan delas med andra enheter och användare via en länk och ett lösenord. Den möjliggör navigering mellan skärmar, vilket gör det enkelt att samla in feedback, oavsett om det är från intressenter, potentiella användare eller investerare.
Huvudmålet med denna fas är att garantera att alla krav och idéer som genererats är realistiska att implementera och genomförbara inom den fastställda tidsramen och budgeten.
11. Övergripande arkitektur. Detta steg utvecklar den tekniska designen med rätt balans mellan komplexitet och omfattning. Det är även här externa beroenden från tredjepartsleverantörer, såsom Stripe för betalningar, Meta (Facebook) för autentisering, eller Amazon Web Services för hosting, identifieras. Det beskriver i detalj hur produkten ska byggas samt vilka tekniker och kompetenser som krävs för att bygga den.
12. Projektplan. Det sista steget definierar de viktigaste milstolparna och ger en övergripande förståelse för projektets struktur, faser, överlappningar och beroenden. Du får en tydlig bild av hur produkten ska byggas, hur mycket arbete som krävs och de förväntade kostnaderna för varje fas.
Det är avgörande att följa den ordning som faserna presenteras i. Resultaten från tidigare faser är en förutsättning för de efterföljande stegen. Inom design är det vanligt att utföra flera uppgifter samtidigt, men att göra detta över olika faser stjälper mer än det hjälper.
Att följa en produktdesignprocess (PDP) ger en rad fördelar jämfört med ostrukturerade arbetssätt. Det minskar tiden och kostnaderna för design och utveckling, möjliggör realistisk tidsplanering och leder till en produkt av högre kvalitet.
Anledningen är en kostnadskurva som är väldokumenterad inom mjukvaruekonomi, även om det är värt att vara specifik. Boehm och Basilis expertgranskade studie på området visade att ett problem som upptäcks efter leverans kan kosta betydligt mer att åtgärda än om samma problem upptäcks under kravställnings- och designfasen: för stora, verksamhetskritiska system kan det handla om upp till 100 gånger mer (Software Defect Reduction Top 10 List, IEEE Computer, 2001). Den exakta multiplikatorn är omdiskuterad och beror i hög grad på systemet: Boehms eget senare arbete satte förhållandet närmare 5:1 för små, agila projekt med kontinuerlig integration, vilket ligger närmare profilen för de flesta digitala produkter. Riktningen är dock odiskutabel: ju senare du upptäcker ett problem med design eller krav, desto mer kostar det.
Makrosiffran har uppdaterats sedan dess. Den amerikanska myndigheten NIST:s studie från 2002 uppskattade den årliga kostnaden för bristfällig infrastruktur för mjukvarutestning till cirka 59,5 miljarder dollar. Två decennier senare uppskattade Consortium for Information and Software Quality (CISQ) kostnaden för dålig mjukvarukvalitet i USA till ungefär 2,41 biljoner dollar år 2022, varav cirka 1,52 biljoner utgörs av ackumulerad teknisk skuld (The Cost of Poor Software Quality in the US: A 2022 Report). Slutsatsen är densamma, fast i mycket större skala: kvalitetsproblem är billigast att förebygga tidigt.
Designbeslut fungerar på samma sätt. Att ändra en wireframe tar en eftermiddag. Att ändra samma beslut efter att gränssnittet har byggts och lanserats kostar en hel release. Att välja att designa genom en process snarare än genom improvisation är det som håller dessa beslut i den billiga änden av kurvan.
Du kan inte generera bra idéer utan att förstå det aktuella problemet. Och du kan inte exekvera utan att förstå vad som behöver byggas. Varje gång en ny idé prototypas ovanpå omogna krav, måste en stor del av det som redan gjorts tänkas om eller designas om.
Att tvingas till en fullständig omarbetning kommer i bästa fall att lämna dig med en produkt som ser ihop-lappad ut snarare än byggd som en integrerad helhet. Det är därför det är så viktigt att dela upp processen i faser och steg i en definierad ordning.
Att respektera ordningen på faserna är avgörande, men inom varje skede finns flera steg som kan köras parallellt. Den flexibiliteten gör att du kan anpassa dig efter olika projektförutsättningar och teampreferenser utan att kompromissa med produktkvalitet, tidsram eller budget.
Behöver du bygga vidare på en befintlig produkt? Gå tillbaka och se över de tidigare faserna och stegen. Om ny feedback måste integreras i en prototyp bör teamet återgå till de tidigare stadierna innan ändringarna görs. Att göra ändringar i den slutgiltiga designen är alltid betydligt dyrare än att justera i varje steg allt eftersom feedback inkommer, vilket är anledningen till att god kommunikation bär hela processen.
Under processens gång bör det i varje steg finnas minst tre kommunikationstillfällen: en inledande workshop, en statusuppdatering när stegets genomförande nått halvvägs, samt ett avslutande möte för att validera steget.
Mellan dessa avstämningar bör teamet fokusera på det aktuella steget utan att ta in ytterligare input som orsakar onödiga avvikelser. Vid varje möte bör teamet alltid ha ett mervärde att bidra med och feedback att samla in.
I samma anda: om produktägaren inte är tillgänglig för statusuppdateringen halvvägs, bör teamet påbörja de återstående stegen i fasen istället för att låta projektet stanna av. Ständig kommunikation med produktägaren är ett kritiskt krav för att PDP ska lyckas: det är vad som möjliggör korta feedbackcykler och därmed korta exekveringstider.
För att se vår produktdesignprocess i praktiken, ta en titt på vår TravelWifi-fallstudie. TravelWifi är en e-handelsplattform som erbjuder bärbara internetlösningar. Vårt uppdrag var att visuellt spegla de olika produkter som plattformen erbjuder och möta användarnas förväntningar genom att guida dem genom en smidig och enkel resa på plattformen. Fallstudien redogör för forskningen, gränssnittsarbetet och vad som lanserades.
För att få veta mer om hur vi tillämpar vår produktdesignprocess i våra projekt, besök gärna vår portfölj.
När PDP är slutförd och den första versionen har lanserats behöver produkten fortfarande förbättras genom en design-, bygg- och lärprocess. Dessa ändringar efter lansering skiljer sig oftast från de som identifierades under utvecklingen av prototypen.
Det rör sig oftast om små detaljer baserade på användarfeedback, med låg risk att påverka det befintliga grafiska gränssnittet. Det är just det som är poängen med de tolv stegen. Grunden är redan lagd, så det som följer är förfining snarare än omarbetning.
De flesta stegen kräver inga förkunskaper, men det är lättare att bemästra PDP om du gör efterforskningar och samlar på dig så många referenser som möjligt. Den största fördelen med att använda PDP är att vikten av varje steg och dess leverabler blir tydlig, vilket hindrar team från att hoppa direkt till de senare faserna utan att ha en stabil grund för sina val.
PDP är numera en stabil process, men den blir aldrig helt färdig eftersom produktdesign ständigt utvecklas. Vi kommer att fortsätta uppdatera den vid behov och integrera nya verktyg och tekniker som förbättrar helheten.
För en typisk digital produkt sträcker sig de tolv stegen i designprocessen över flera veckor snarare än flera månader. Research och idégenerering tar oftast längst tid, eftersom de lägger grunden för de krav som alla efterföljande steg bygger på. Tidsåtgången skalas efter antalet användarresor som omfattas, inte efter antalet skärmar.
UX-design omfattar hur en produkt fungerar för användaren: research, användarresor, wireframes och användbarhet. Produktdesign omfattar allt detta plus affärsmodellen, det visuella gränssnittet och den tekniska genomförbarheten för det som föreslås. I PDP ansvarar UX-design för researchfasen och en del av idégenereringen, medan produktdesign ansvarar för genomförandet.
Kostnaden beror på omfattningen, men den relevanta jämförelsen är inte design kontra ingen design, utan design kontra omarbete. Steg 12 ger den förväntade kostnaden för varje fas innan implementeringen påbörjas, vilket gör att budgetdiskussionen baseras på fakta snarare än på gissningar.
Inte utan att det får konsekvenser. Varje stegs resultat är indata till nästa: användarresearch ligger till grund för användarresan, användarresan ligger till grund för beslutsmatrisen, och matrisen ligger till grund för wireframes. Hoppar du över ett steg kommer ett senare steg att baseras på antaganden, och antaganden leder till omarbete när gränssnittet väl är byggt.
Ja, inom en fas. Flera steg i samma fas kan köras samtidigt för att passa teamets tillgänglighet. Det som inte kan parallelliseras är själva faserna, eftersom varje fas är beroende av leverablerna från den föregående.
En UX-designer leder research och tidig idégenerering, en produktdesigner leder genomförandet, en tech lead ansvarar för den tekniska bedömningen, och produktägaren deltar vid tre kontrollpunkter i varje steg: en inledande workshop, en statusuppdatering halvvägs och ett valideringsmöte.
Ja. För en produkt som redan finns på marknaden börjar processen från den fas som rör det beslut du vill se över. Att lägga till en funktion innebär oftast att man går tillbaka till användarresa och beslutsmatris. En omdesign innebär oftast att man går tillbaka till designbenchmark och moodboard.
Tolv stycken, en per steg: en brief, användarresearch, en designbenchmark, en användarresa, en beslutsmatris, wireframes, en moodboard, en stilguide, GUI-designer, en klickbar prototyp, en övergripande arkitektur samt en projektplan med milstolpar och kostnader.
Om du funderar på hur mycket designarbete som bör finansieras innan utvecklingen påbörjas, går vi gärna igenom vår PDP utifrån din produkt och berättar vilka faser som är viktigast för just den. Hör av dig, eller läs mer om vårt digitala produktdesignarbete och utveckling av webbapplikationer .
Du kan även läsa hela vår metodik i vår bok Product Design Process. Den beskriver varje fas med praktiska exempel och vad du bör ha uppnått vid slutet av varje steg. Du kan beställa den direkt via Amazon.
Innehållshanterare, textredigerare, och presentatör av strategiska idéer, tillsammans med att vara en ivrig beundrare av filmkonst och visuellt berättande.
Marknadsföringspraktikant med ett särskilt intresse för teknik och research. På fritiden spelar jag volleyboll och skämmer bort min hund så mycket jag bara kan.
VD på Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i den ordningen).
LinkedIn
People who read this post, also found these interesting:
