Produktdesignprocessen er den rækkefølge, et team følger for at forvandle et markedsproblem til et fungerende digitalt produkt. Vores kaldes Product Design Process (PDP). Den strækker sig over fire faser (research, idégenerering, eksekvering og teknisk vurdering), der er opdelt i tolv trin, som hver især har en ansvarlig og et leverance, som det næste trin afhænger af.
Tænk på det som mise en place. Alt er snittet, afmålt og inden for rækkevidde, før panden overhovedet kommer i nærheden af varmen.
Dette indlæg forklarer, hvad produktdesign er, hvorfor rækkefølgen betyder noget, og hvad der sker i hvert af de tolv designtrin. Det er skrevet til stiftere, produktejere og ledere, der skal beslutte, hvor meget designarbejde der skal finansieres, før den første linje kode skrives.
Vi holder ikke metoden for os selv. Den er udgivet i sin helhed, med alle faser og konkrete eksempler, i vores bog om Product Design Process, skrevet af tre af de personer, der har udviklet og driver den hos Imaginary Cloud. Det, der følger herunder, er den aktive version af metoden – den samme, som ligger bag vores digitale produktdesign.
| Fase | Trin | Ansvarlig | Leverance |
|---|---|---|---|
| Research | 1. Briefing | UX-designer | Fælles formulering af vision, mål og forretningskrav |
| Research | 2. Brugerundersøgelse | UX-designer | Målgruppeprofil, mål og motivationer |
| Research | 3. Design-benchmark | UX-designer | Overblik over konkurrerende og supplerende produkter |
| Idégenerering | 4. Brugerrejse | UX-designer med product owner | Kortlagte brugerscenarier og produktkrav |
| Idégenerering | 5. Beslutningsmatrix | Product owner med UX-designer | Prioriteret omfang inden for tids- og økonomirammer |
| Idégenerering | 6. Wireframes | UX-designer | Skærmstruktur og navigationsflow |
| Idégenerering | 7. Moodboard | Produktdesigner | Aftalt udtryk og stil (look and feel) |
| Eksekvering | 8. Styleguide | Produktdesigner | Farvepalette, skrifttyper, billedstil, grænsefladekomponenter |
| Eksekvering | 9. GUI-design | Produktdesigner | Endelige skærmbilleder, godkendt af interessenter |
| Eksekvering | 10. Prototype | Produktdesigner | Delbar klikbar prototype |
| Teknisk vurdering | 11. Overordnet arkitektur | Tech lead | Teknisk design og tredjepartsafhængigheder |
| Teknisk vurdering | 12. Projektplan | Tech lead med product owner | Mæler, arbejdsindsats og forventede omkostninger pr. fase |
Produktdesign er arbejdet med at beslutte, hvad et produkt skal kunne, hvem det er til, og hvordan det skal fungere, før det bliver bygget. I PDP resulterer dette arbejde i tolv definerede leverancer, lige fra en brugerprofil til en projektplan med tilhørende omkostninger. (Se vores korte definition af produktdesignprocessen.)
Begrebet overlapper ofte med industrielt produktdesign, som dækker varer fremstillet gennem masseproduktion: en iPhone, en brødrister, en guitar, en stol. Denne artikel handler om digitalt produktdesign, som er en underkategori heraf. Et digitalt produkt er et immaterielt gode, der findes online, såsom en hjemmeside eller en app.
Handler design så om, hvordan et produkt ser ud? Ikke primært, nej. Æstetik betyder noget, men design handler mest om, hvordan produktet fungerer.
Den skelnen har en praktisk konsekvens. Trin 1 til 7 i PDP, altså mere end halvdelen, producerer slet ikke noget visuelt design. De producerer en brugerprofil, en benchmark, en brugerrejse, et prioriteret omfang og en wireframe. Først derefter vælger man farver.
Produktdesigneren finder ud af, hvilke brugere produktet skal tjene, og hvad de forsøger at opnå, for derefter at omsætte det til noget brugbart. Det første skridt i produktdesignprocessen er at identificere slutbrugernes problemer, hvilket er grunden til, at brugerresearch er trin 2 i PDP og ikke et skærmbillede.
Det er lige så vigtigt at vide, hvem der skal bruge produktet, som at vide, hvilket problem det løser. Det samme problem får forskellige løsninger afhængigt af, hvem der har det.
Titlen dækker over flere jobfunktioner. En UI-udvikler, en UX-designer, en interaktionsdesigner, en experience-designer og en prototyper falder alle ind under kategorien produktdesigner. Forskellige virksomheder trækker grænserne forskelligt, og derfor navngiver PDP en ansvarlig for hvert trin i stedet for at stole på, at jobtitlerne gør det.
At bygge det forkerte produkt rigtigt er det dyreste resultat, et produktteam kan ende med. Det er også det resultat, som en ustruktureret tilgang mest pålideligt fører til.
Vi ved det, fordi vi selv har prøvet det. Projekterne beskrevet herunder blev leveret til tiden og efter specifikationerne, men fejlede alligevel på markedet, fordi ingen havde afklaret, hvad markedet ønskede, før udviklingen gik i gang.
Design er det, der lukker det hul. At gøre det ordentligt kræver forretningsanalyse, brugerresearch, forståelse for menneskelig adfærd og tilstrækkelig softwareindsigt til at kunne skelne en god idé fra en dyr en.
Det omvendte er lige så sandt. En app kan være baseret på en genial idé og stadig fejle, hvis navigationen forvirrer brugerne, oplevelsen føles tung, og slutbrugeren ikke kan finde ud af at bruge den. En god idé bliver aldrig til mere end en idé, hvis produktdesignet ikke imødekommer slutbrugernes ønsker.
Lad os dele lidt af Imaginary Clouds historie. Tilbage i 2014 designede vi en tjeneste kaldet "The War Room". Løftet var at samle en produktejer, en designer og et udviklerteam i ét rum i tre dage for at levere et MVP (Minimum Viable Product).
Resultaterne var svingende. Vi leverede et par projekter, men de fejlede alle, da de ramte markedet. Tiden, hvor man bare kunne "bygge det, så skal de nok komme", var for længst forbi. The Lean Startup og Google Design Sprint stod på alles bogreoler og i deres bogmærker, men ingen af dem var tilstrækkelige alene.
På det tidspunkt indså vi, at digitale produkter kræver grundig research, før de bygges. Og der fandtes ingen dokumenteret designproces, vi kunne bruge. Så vi byggede vores egen: Product Design Process (PDP).
PDP er en samling af eksisterende teknikker, der er modnet over tid i branchen og kædet sammen, så produktdesignteamets arbejdsgang er så effektiv som muligt.
Den dag i dag udgør vores Product Design Process kernen i, hvordan vi leverer digitale produkter, og det er den proces, der ligger bag hvert eneste projekt i vores portefølje.
Product Design Process (PDP) er en brugercentreret designproces til digitale produkter, der følger en tværfaglig tilgang. Hovedformålet er at få produkter hurtigt på markedet uden at gå på kompromis med det datagrundlag, de bør hvile på. Processen fungerer lige så effektivt til projekter, der søger vækst gennem optimering.
Vores vision er enkel. Vi ønsker at levere den bedste tilgængelige løsning på et specifikt problem på et marked, hvor de fleste konkurrerende produkter lanceres uden en sådan.
Den første fase af PDP er UX-designerens ansvar. Målet er at indsamle dokumentation, der understøtter alle fremtidige beslutninger, så intet er baseret på vage antagelser. Det er her, de vigtigste aspekter af forretningsmodellen og brugernes behov identificeres.
1. Briefing. Sikrer, at hele teamet er afstemt og har al relevant information: projektets vision og mål samt forretningskravene.
2. Brugerresearch. Brugerprofilen drøftes med produktets interessenter. Ved at definere målgruppens profil identificeres deres primære mål og motivationer. Brugerresearch sikrer produktets nytteværdi og effektivitet set fra brugerens perspektiv.
3. Design-benchmark. Teamet gennemgår lignende og komplementære produkter, de anvendte designmønstre og de bagvedliggende teknologier. Denne gennemgang viser, hvor det nye produkt kan placeres på markedet, hvilke konventioner brugerne forventer, og hvilke funktioner og designvalg der for alvor vil skille det ud.
Ideudvikling er kernen i den kreative proces. Det er her, produktkonceptet formuleres ud fra brugernes behov og forretningsmodellen, som begge blev identificeret i researchfasen. Her bør UX-designeren, produktdesigneren og produktansvarlige arbejde tæt sammen.
4. Brugerrejse. Den ideelle brugeroplevelse kortlægges ved at beskrive hver enkelt brugerhandling. Forskellige brugerscenarier skrives og valideres. Dette giver et helhedsbillede af oplevelsen, sikrer konsistens og flow, og fungerer som grundlag for at fastlægge produktkravene.
5. Beslutningsmatrix. Beslutningsmatrixen vurderer hver potentiel funktion ud fra to akser: hvor vigtig den er for brugeren og forretningen, og hvor meget tid og penge det koster at udvikle den. Det, der overlever vurderingen, udgør det scope, der realistisk kan lanceres inden for de givne rammer på produktets nuværende stadie. Det, der ikke overlever, bliver noteret frem for glemt.
6. Wireframes. Her begynder skelettet af skærmbillederne at tage form. Sidestruktur og navigationsflow fastlægges, hvilket definerer placeringen af alt indhold, før det bliver stylet, og forkorter det efterfølgende designarbejde.
7. Moodboard. Sikrer, at produktets udseende og følelse formidler den ønskede oplevelse og er i tråd med brugerprofilen og markedsstrategien. Dette trin indfanger produktets "stemning" gennem en samling af billeder, ord og andre visuelle elementer.
I denne fase omdanner produktdesigneren det hidtil aftalte koncept til skærmbilleder, som folk rent faktisk kan se og klikke sig igennem.
8. Styleguide. Det er her, den grafiske brugerflade får sine regler: farvepalette, skrifttyper, billedstil, inputfelter, knapper og så videre. Ved at fastlægge disse valg én gang i ét dokument sikres det, at alle skærmbilleder i applikationen er visuelt sammenhængende.
9. Design af grafisk brugerflade (GUI). De endelige skærmbilleder udarbejdes ved at anvende styleguiden på wireframes. Det niende trin giver interessenterne det endelige udseende af produktets skærme, så de kan godkende det, før implementeringen påbegyndes.
10. Prototype. Der udvikles en klikbar prototype, som er tilgængelig online og kan deles med andre enheder og brugere via et link og en adgangskode. Den gør det muligt at navigere fra skærm til skærm, hvilket gør det nemt at indsamle feedback, uanset om det er fra interessenter, potentielle brugere eller investorer.
Hovedformålet med denne fase er at sikre, at alle krav og idéer er realistiske at implementere og kan opnås inden for den fastlagte tidsramme og det fastlagte budget.
11. Overordnet arkitektur. Dette trin udvikler det tekniske design med den rette balance mellem kompleksitet og rækkevidde. Det er også her, eksterne afhængigheder fra tredjepartsudbydere, såsom Stripe til betalinger, Meta (Facebook) til godkendelse, eller Amazon Web Services til hosting, identificeres. Det beskriver detaljeret, hvordan produktet skal bygges, samt hvilke teknologier og kompetencer der kræves for at bygge det.
12. Projektplan. Det sidste trin definerer de vigtigste milepæle og giver en generel forståelse af projektets struktur, faser, overlap og indbyrdes afhængigheder. Du ender med at vide, hvordan produktet skal bygges, hvor stor en indsats det vil kræve, og hvad de forventede omkostninger er for hver fase.
Det er afgørende at overholde rækkefølgen af de angivne faser. Resultaterne fra de tidlige faser er en forudsætning for de efterfølgende trin. Selvom det er almindelig praksis inden for design at udføre flere opgaver samtidigt, gør det mere skade end gavn, når det sker på tværs af faser.
At følge en produktdesignproces (PDP) giver en række fordele sammenlignet med ustrukturerede tilgange. Det reducerer tid og omkostninger brugt på produktdesign og -udvikling, gør det muligt at planlægge realistiske tidsplaner og fører til et produkt af højere kvalitet.
Årsagen er en omkostningskurve, der er veldokumenteret inden for softwareøkonomi, selvom det er værd at være præcis omkring den. Boehm og Basilis fagfællebedømte gennemgang af feltet viste, at et problem, der opdages efter levering, kan koste langt mere at udbedre end det samme problem, hvis det opdages under kravspecifikation og design: for store systemer med høj pålidelighed er faktoren omkring 100 gange højere (Software Defect Reduction Top 10 List, IEEE Computer, 2001). Den præcise multiplikator er omdiskuteret og afhænger i høj grad af systemet: Boehms eget senere arbejde satte forholdet tættere på 5:1 for små, agile projekter med kontinuerlig integration, hvilket ligger tættere på profilen for de fleste digitale produkter. Retningen er dog ubestridt: jo senere du opdager et design- eller kravproblem, jo mere koster det.
Makrotallet er blevet opdateret siden da. Den amerikanske standardiseringsorganisation NIST's studie fra 2002 anslog de årlige omkostninger ved utilstrækkelig softwaretestinfrastruktur til omkring 59,5 milliarder dollars. To årtier senere estimerede Consortium for Information and Software Quality (CISQ) omkostningerne ved dårlig softwarekvalitet i USA til cirka 2,41 billioner dollars i 2022, hvoraf omkring 1,52 billioner er akkumuleret teknisk gæld (The Cost of Poor Software Quality in the US: A 2022 Report). Konklusionen er den samme, blot i langt større skala: kvalitetsproblemer er billigst at forebygge tidligt.
Designbeslutninger fungerer på samme måde. At ændre en wireframe koster en eftermiddag. At ændre den samme beslutning, efter interfacet er bygget og lanceret, koster en release. At vælge at designe ud fra en proces frem for improvisation er det, der holder disse beslutninger i den billige ende af kurven.
Du kan ikke skabe gode idéer uden at forstå det problem, du står overfor. Og du kan ikke eksekvere uden at forstå, hvad der skal bygges. Hver gang en ny idé bliver prototypet oven på umodne krav, skal en stor del af det allerede udførte arbejde gentænkes eller redesignes.
At tvinge et komplet redesign igennem vil i bedste fald efterlade dig med et produkt, der virker lappet sammen frem for bygget som en integreret helhed. Det er derfor, det er så vigtigt at opdele processen i faser og trin i en defineret rækkefølge.
Det er essentielt at respektere fasernes rækkefølge, men inden for hvert trin vil du finde flere opgaver, der kan udføres samtidigt. Denne fleksibilitet gør det muligt at imødekomme forskellige projektkarakteristika og teampræferencer uden at gå på kompromis med produktkvalitet, tidsramme eller budget.
Skal du bygge videre på et eksisterende produkt? Gå tilbage og genbesøg de tidligere faser og trin. Hvis ny feedback skal integreres i en prototype, bør teamet vende tilbage til de tidligere stadier, før ændringerne foretages. At foretage ændringer i det endelige design er altid langt dyrere end at justere løbende, efterhånden som feedbacken kommer ind, hvilket er grunden til, at god kommunikation bærer hele processen.
I løbet af processen bør der i hvert trin være mindst tre kommunikationspunkter: en indledende workshop, en statusopdatering når trinnet er halvvejs, og et afsluttende møde for at validere trinnet.
Mellem disse checkpoints bør teamet fokusere på det aktuelle trin uden at lade sig aflede af unødvendige input. Ved hvert møde bør teamet altid have tilført værdi og indsamlet feedback.
I samme tråd gælder det, at hvis produktejeren ikke er tilgængelig til statusopdateringen midtvejs, bør teamet påbegynde de resterende trin i fasen frem for at lade projektet gå i stå. Konstant kommunikation med produktejeren er et kritisk krav for succesen af en PDP: det er det, der muliggør korte feedback-cyklusser og dermed korte eksekveringstider.
For at se vores produktdesignproces i praksis, kan du tage et kig på vores TravelWifi case study. TravelWifi er en e-handelsplatform, der tilbyder bærbare internetløsninger. Vores mission var at afspejle de mange produkter, platformen tilbyder, visuelt og imødekomme brugernes forventninger ved at guide dem gennem en gnidningsfri og enkel rejse på tværs af platformen. Casestudiet gennemgår research, interface-arbejde og det endelige resultat.
Hvis du vil vide mere om, hvordan vi anvender vores produktdesignproces i vores projekter, er du velkommen til at besøge vores portfolio.
Når PDP er gennemført, og den første version er lanceret, skal produktet stadig forbedres gennem en design-, udviklings- og læringscyklus. Disse ændringer efter lanceringen er normalt anderledes end dem, der blev identificeret under udviklingen af prototypen.
Der er ofte tale om små detaljer baseret på brugerfeedback, som indebærer en lav risiko for at kompromittere det eksisterende grafiske brugerfladedesign. Det er netop pointen med de tolv trin. Fundamentet er allerede på plads, så det, der følger, er forfining frem for omarbejdning.
De fleste trin kræver ikke forudgående specifik viden, men det er lettere at mestre PDP, hvis du laver yderligere research og indsamler så mange referencer som muligt. Den største fordel ved at bruge PDP er, at vigtigheden af hvert trin og dets leverancer bliver tydelig, hvilket forhindrer teams i at springe direkte til de senere faser uden et fundament, der kan understøtte deres valg.
PDP er nu en stabil proces, men den bliver aldrig færdig, da produktdesign hele tiden udvikler sig. Vi vil løbende opdatere den efter behov og integrere nye værktøjer og teknikker, der forbedrer den samlede ydeevne.
For et typisk digitalt produkt strækker de tolv designtrin sig over nogle uger frem for måneder. Research og idégenerering tager som regel længst tid, da de fastlægger de krav, som alle efterfølgende trin afhænger af. Varigheden afhænger af antallet af brugerrejser, der er omfattet, ikke af antallet af skærmbilleder.
UX-design dækker, hvordan et produkt fungerer for brugeren: research, brugerrejser, wireframes og brugervenlighed. Produktdesign dækker alt dette plus forretningsmodellen, den visuelle brugerflade og den tekniske gennemførlighed af det foreslåede. I PDP-processen står UX-design for researchfasen og en del af idégenereringen, mens produktdesign står for eksekveringen.
Prisen afhænger af omfanget, men den relevante sammenligning er ikke design kontra intet design. Det er design kontra omarbejdning. Trin 12 giver det forventede omkostningsestimat for hver fase, før implementeringen starter, så budgetdialogen foregår på et oplyst grundlag frem for på gætteri.
Ikke uden at betale prisen for det. Hvert trins output er input til det næste: brugerresearch føder brugerrejsen, brugerrejsen føder beslutningsmatricen, og matricen føder wireframes. Springer du et trin over, bygger de efterfølgende trin på antagelser, og antagelser viser sig som omarbejdning, når brugerfladen først er bygget.
Ja, inden for en fase. Flere trin i samme fase kan køre samtidigt for at passe til teamets tilgængelighed. Det, der ikke kan paralleliseres, er selve faserne, da hver fase afhænger af leverancerne fra den foregående.
En UX-designer leder research og den indledende idégenerering, en produktdesigner leder eksekveringen, en tech lead står for den tekniske vurdering, og produktejeren deltager ved tre kontrolpunkter i hvert trin: en indledende workshop, en statusopdatering midtvejs og et valideringsmøde.
Ja. For et produkt, der allerede er på markedet, starter processen fra den fase, der indeholder den beslutning, du genbesøger. Tilføjelse af en funktion betyder normalt, at man går tilbage til brugerrejse og beslutningsmatrix. Et redesign betyder normalt, at man går tilbage til design-benchmark og moodboard.
Tolv, én pr. trin: et brief, brugerresearch, et design-benchmark, en brugerrejse, en beslutningsmatrix, wireframes, et moodboard, en stilguide, GUI-designs, en klikbar prototype, en overordnet arkitektur og en projektplan med milepæle og omkostninger.
Hvis du overvejer, hvor meget designarbejde der skal finansieres, før udviklingen går i gang, gennemgår vi gerne vores PDP i forhold til dit produkt og fortæller dig, hvilke faser der er vigtigst for netop dit projekt. Kontakt os, eller læs mere om vores digitale produktdesign og webapplikationsudvikling .
Du kan også læse hele vores metodik i vores Product Design Process-bog. Den beskriver hver fase med praktiske eksempler og fortæller, hvad du bør have opnået ved afslutningen af hvert trin. Du kan bestille den direkte på Amazon.
Indholdsadministrator, teksteditor, og præsentator for strategiske ideer, sammen med at være en ivrig fan af filmkunst og visuel historiefortælling.
Marketing praktikant med særlig interesse for teknologi og forskning. I min fritid spiller jeg volleyball og forkæler min hund så meget som muligt.
CEO hos Imaginary Cloud og medforfatter til bogen Product Design Process. Jeg nyder mad, vin og Krav Maga (ikke nødvendigvis i den rækkefølge).
LinkedIn
People who read this post, also found these interesting:
