Som en bekymret produktchef har du sandsynligvis rejst spørgsmålet på et tidspunkt: hvordan gør det nøjagtigt Google Design Sprint passer til mine behov? Som en talentfuld designer burde du også allerede have stillet spørgsmålstegn ved, hvilken værdi det virkelig tilføjer til ligningen, og til hvilken fase det kan være mere nyttigt.
Som designer selv analyserer og sammenligner jeg her Google Design Sprint med vores egne Produktdesignprocesog giver en smule kontekst i hvert enkelt tilfælde.
Design er den grundlæggende sjæl i en menneskeskabt skabelse, der ender med at udtrykke sig i successive ydre lag af produktet eller tjenesten.
— Steve Jobs
Google Design Sprint er, som Google selv udtrykker det, „en proces til at besvare kritiske forretningsspørgsmål gennem design, prototyping og test“ Det gør det muligt for produktejerne at have „en genvej til læring uden at opbygge og lancere et minimalt levedygtigt produkt“. I sidste ende, du ved, om dit produktkoncept er godt, men du bliver stadig nødt til at lave en masse design før implementering.
Det er en fem-dages proces:
Dag 1. Kortlæg problemet og vælg et vigtigt sted at fokusere;
Dag 2. Skitse konkurrerende løsninger på papir;
Dag 3. Tag vanskelige beslutninger og vend dine ideer til en testbar hypotese;
Dag 4. Hamre en prototype med høj kvalitet ud;
Dag 5. Test det med rigtige levende mennesker.
Den Produktdesignproces er i en nøddeskal en proces, der får dig igennem alle trin i selve produktopbygningen. I slutningen af processen har du alt hvad du behøver for at begynde at implementere, hvilket forklarer den længere tidsramme, der kræves.
Det følger en firetrinsproces, hvor den tekniske vurdering sker samtidig med de andre faser:
Fremover understreger Sprint-præsentationen tydeligt, at vurderingen af virksomhedens levedygtighed er dens hovedmål, men nævner også, at den kan anvendes på „lav den første version af nye mobile apps“ eller „forbedre produkter med millioner af brugere“.
Selvom det bestemt kan, er det ikke en passende proces at gøre det, hvilket forklarer, hvorfor Google ikke præsenterer oprettelsen af nye mobilapps som sit hovedmål.
Du kan også perfekt starte en ild ved at gnide to pinde sammen, men der er meget få lejligheder, hvor det ville være den bedste måde at gøre det på.
Det er i denne fase, at Google har nogle begrænsninger, kræver, at vi kun har én målkunde og én målbegivenhed. På en enkel måde betyder det, at hvis du udvikler den første version af en mobilapp, skal den være meget grundlæggende, da forbedringen af et eksisterende produkt kun sker gennem tilføjelse eller ændring af en funktion.
For eksempel ville du være i stand til at ændre et element ad gangen, hvilket gør det umuligt at målrette mod to forskellige personas samtidigt. Selvom det at have kun én målperson kan være det ideelle scenarie for en designer, ved vi meget godt, at vi det meste af tiden ikke kan slippe af sted med det. Under alle omstændigheder kan vi ikke overse dem, Personas er afgørende, når man udvikler et nyt produkt.
Hvis du enten har en kompleks app, vil arbejde på forbedring af forskellige funktioner eller lave flere nye funktioner, kan du ikke gøre det på én gang. For at tilføje yderligere indhold skal du lave flere Design Sprints. Det er hvad der skete med casestudiet præsenteret i Sprint-bogen om Slap, hvor det står, at der var behov for to sprints, før de begyndte at bygge det.
I modsætning hertil, Produktdesignprocessen kan overveje mere end én personog er dermed mere velegnet til produkter, der kræver flere brugerroller. For eksempel sundhedsapps, der kræver forskellige grænseflader til fagfolk og patienter, eller undervisningsapps, der bruges af både lærere og studerende.
Tidsrammen og person-/funktionsbegrænsninger er kun de første barrierer, som vi står over for, når vi vælger Sprint til at udvikle en ny app. Denne proces har et større problem, når den anvendes til udvikling af nye produkter - et problem, der ikke kan løses ved at udføre flere Sprints eller ved at forlænge dets varighed.
Google Sprint præsenterer dig hvad du skal gøre og efter hvilken rækkefølge, men det giver dig ingen indsigt i hvorledes at bevæge sig fra trin til trin, og heller ikke hvordan man udfører nogle af opgaverne derimellem.
Når vi når den del af at lave det visuelle, nævner Sprint det Skabere (designere eller ingeniører) bør oprette de enkelte komponenter: skærme, sider, stykker og så videre, under ledelse af Sticher, hvem skal give stilvejledningerne at følge. Det overvejer dog ikke oprettelsen af disse stilguider, tiden til at lave dem eller de opgaver, der er nødvendige for at definere det visuelle koncept, som stilguiderne er baseret på. Dette er ikke afgørende for at få adgang til produktkonceptets levedygtighed (Sprints hovedmål), men det er afgørende, hvis målet er at opbygge det.
Når den visuelle konceptdefinition forsømmes (ikke udført eller udført, men uden at være baseret på bruger- og markedsundersøgelser) Det har alvorlige konsekvenser:
Det er usandsynligt, at du vil brænde en rumfærge op eller skyde et fly ned, men Dårlig brugeroplevelse kan meget vel være katastrofal for dit produkts succes.
Når du opretter indhold, skal du være empatisk frem for alt andet. Prøv at leve dit publikums liv.
— Rand Fishkin, grundlægger af Moz
Et mindre åbenlyst tilfælde, men stadig lignende, findes i begyndelsen af processen, i „Remix og forbedringer“ dag (den anden). Her fortæller processen dig at „Bed alle på teamet om at komme med en liste over produkter eller tjenester, der skal gennemgås for inspirerende løsninger“ og derefter præsentere dem for teamet og skriv de mest nyttige ideer ned på en whiteboard.
Problemet her er, at disse referencer indsamles baseret på teamets personlige præferencer og oplevelser. Processen overvejer ikke noget brugerinput og er således faktisk ikke brugercentreret design. Det er vigtigt at tage højde for, at en funktion kun er „god“ fra et subjektivt synspunkt.
En god funktion for nogen kan være disponibel eller endda skadelig for andre og det samme gælder brugervenlighed og brugeroplevelse. Nogle mennesker kan finde en bestemt måde at vise information intuitiv på, mens andre kan finde det forvirrende. En person kan finde det tiltalende, og en anden bliver afskrækket af det.
Måden at løse det på er ved at definere en brugermålprofil og se på de referencer, som folk, der passer til den profil, har og foretrækker. Mens Sprint definerer en målbruger på den første dag, bruger den ikke rigtig den til at guide yderligere beslutninger om produktet. Vi kan ikke understrege det nok, du skal design til din målgruppe, ikke for dig selv.
Der er ingen mening (ud fra perspektivet om at sikre produktets succes) at have nogen ansvarlig for brugergrænsefladen, der hverken er:
Den eneste mulige grund til at gøre det er at engagere klienter i processen, skabe et bedre forhold til dem og have lettere godkendelsesprocesser, da de føler sig som forfatterne af løsningen. Der er dog ingen fordel med hensyn til slutproduktets kvalitet.
Faktisk kan det endda være skadeligt. I Google-venture-sammenhæng fungerer Sprint muligvis på grund af det faktum, at alle mennesker er nedsænket i en designkultur, men når produktejeren er en person, der ikke kommer fra produktdesignmiljøet og ikke har kendskab til de potentielle brugerprofiler, vender tidevandet.
I ProduktdesignprocesI modsætning hertil, selvom du ikke havde chancen for at kontakte potentielle brugere for at kende deres personlige referencer og præferencer, fokuserer teamet på at sætte sig selv i brugerens sko og undersøge ikke deres egne referencer, men andre produkter, der vides at blive brugt og værdsat af målbrugerne.
Du er nødt til at forstå brugeren. Hvis du ikke kan, vil han helt sikkert heller ikke være i stand til at forstå dig.
Sammenfattende er Produktdesignproces bedre end Google Sprint? Det kommer an på. Google Sprint er velegnet til de tidlige stadier af produktkonceptualiseringen, når du har et nyt produktkoncept, men du ikke har defineret det klart, og du ønsker at få adgang til dets levedygtighed.
Det er også afgørende for Google Sprints succes, at hele designteamet kender deres publikum. Hvis det er tilfældet, kan du drage stor fordel ved at lave en foreløbig sprint.
Hvis du har fået adgang til produktets levedygtighed med Google Sprint og ønsker at gå videre til implementeringen, kan du drage fordel af Produktdesignproces, hvilket ikke lægger nogen begrænsninger, når du bygger mere komplekse apps eller opgraderer funktioner. Det er dog også muligt at starte designet fra bunden ved hjælp af det nyeste, der dækker hele designprocessen.
Produktdesignprocessen løser problemet med, hvordan du integrerer UX med visuelt design. Dette garanterer for visuelle designere, at de har noget solidt til at opretholde deres valg og beslutninger og ikke blot personlige præferencer, hvilket gør deres arbejde lettere.
Hvad angår produktledere, garanterer det, at UX-design tilføjer konkret værdi til produktet, og det er ikke spildt indsats, hvilket gør det klart, hvordan hver UX-opgave afspejler sig på GUI, hvilket også vil hjælpe salgsteamet med at håndtere potentielle kunder og præsentere værdien af at ansætte UX-designere.
Sidst men ikke mindst betyder det også, at udviklerne ikke behøver at bruge tid på at tage - ofte forkerte - designbeslutninger, og at de grænseflader, som designere leverer, er nemme at implementere.
Ved Imaginær sky vi har et team af eksperter på UI og UX design. Hvis du tror, du kunne bruge lidt hjælp til design, så send os en linje her!
Fandt du denne artikel nyttig? Du kan måske også lide disse!
Med 10 års erfaring og en baggrund inden for kognitiv videnskab. Jeg brænder for inkluderende design og rolig teknologi.
People who read this post, also found these interesting:
