Som berörd produktchef har du förmodligen ställt frågan någon gång: hur exakt gör det Google Design Sprint passar mina behov? Som en begåvad designer borde du också ha ifrågasatt redan vilket värde det verkligen tillför ekvationen och till vilken fas det kan vara mer användbart.
Som designer själv kommer jag här att analysera och jämföra Google Design Sprint med vår egen Produktdesignprocess, ger lite sammanhang i varje enskilt fall.
Design är den grundläggande själen i en mänsklig skapelse som slutar uttrycka sig i successiva yttre lager av produkten eller tjänsten.
— Steve Jobs
Google Design Sprint är, som Google själv uttrycker det, ”En process för att besvara kritiska affärsfrågor genom design, prototypning och testning” som gör det möjligt för produktägare att ha ”en genväg till lärande utan att bygga och lansera en minimal livskraftig produkt”. Till slut, du vet om ditt produktkoncept är bra, men du måste fortfarande göra mycket design innan implementering.
Det är en femdagars process:
Dag 1. Kartlägg problemet och välj en viktig plats att fokusera;
Dag 2. Skissa konkurrerande lösningar på papper;
Dag 3. Ta svåra beslut och förvandla dina idéer till en testbar hypotes;
Dag 4. Hamra ut en prototyp med hög trovärdighet;
Dag 5. Testa det med riktiga levande människor.
Den Produktdesignprocess är, i ett nötskal, en process som tar dig igenom alla steg i själva produktbyggnaden. I slutet av processen har du allt du behöver för att börja implementera, vilket förklarar den längre tidsram som krävs.
Den följer en process i fyra steg, där den tekniska bedömningen sker samtidigt med de andra etapperna:
Vidare understryker Sprint-presentationen tydligt att bedömningen av företagets lönsamhet är dess huvudmål, men nämner också att den kan tillämpas på ”skapa den första versionen av nya mobilappar” eller ”förbättra produkter med miljontals användare”.
Även om det verkligen kan, är det inte en adekvat process att göra det, vilket förklarar varför Google inte presenterar skapandet av nya mobilappar som sitt huvudmål.
Du kan också perfekt starta en eld genom att gnugga två pinnar ihop, men det finns väldigt få tillfällen där det skulle vara det bästa sättet att göra det.
Det är i denna fas som Google har vissa begränsningar, kräver att vi bara har en målkund och en målhändelse. På ett enkelt sätt betyder det att om du utvecklar den första versionen av en mobilapp måste den vara mycket grundläggande, eftersom förbättringen av en befintlig produkt endast görs genom tillägg eller ändring av en funktion.
Till exempel skulle du kunna ändra ett element i taget, vilket gör det omöjligt att rikta in sig på två olika personer samtidigt. Även om att bara ha en målperson kan vara det perfekta scenariot för en designer, vet vi mycket väl att vi för det mesta inte kan komma undan med det. I vilket fall som helst kan vi inte förbise dem, Personas är avgörande när man utvecklar en ny produkt.
Om du antingen har en komplex app, vill arbeta med förbättring av olika funktioner eller skapa flera nya funktioner kommer du inte att kunna göra det på en gång. För att lägga till ytterligare innehåll måste du göra flera Design Sprints. Det är vad som hände med fallstudien som presenterades i Sprint-boken om Slack, där det anges att två Sprints behövdes innan de började bygga den.
Däremot Produktdesignprocessen kan överväga mer än en personoch är därmed mer lämpade för produkter som kräver flera användarroller. Till exempel hälso- och sjukvårdsappar som kräver olika gränssnitt för proffs och patienter eller undervisningsappar som används av både lärare och studenter.
Tidsramen och person-/funktionsbegränsningarna är bara de första hindren som vi möter när vi väljer Sprint för att utveckla en ny app. Denna process har ett större problem när den tillämpas på utveckling av nya produkter - ett problem som inte kan lösas genom att göra flera Sprints eller genom att förlänga dess varaktighet.
Google Sprint presenterar dig vad du borde göra och i vilken ordning, men det ger dig ingen inblick i på vilket sätt att gå från steg till steg, inte heller hur man utför några av uppgifterna däremellan.
När vi når den del av att göra det visuella, nämner Sprint det Tillverkare (designers eller ingenjörer) bör skapa de enskilda komponenterna: skärmar, sidor, bitar och så vidare, under ledning av Sticher, vem ska ge stilguiderna att följa. Det överväger dock inte att skapa dessa stilguider, tiden att göra dem eller de uppgifter som behövs för att definiera det visuella konceptet som stilguiderna är baserade på. Detta är inte nödvändigt för att få tillgång till produktkonceptets livskraft (Sprints huvudmål), men det är avgörande om målet är att bygga det.
När den visuella begreppsdefinitionen försummas (inte gjort eller gjort men utan att baseras på användar- och marknadsundersökningar) Det har allvarliga konsekvenser:
Det är osannolikt att du bränna upp en rymdfärja eller skjuta ner ett flygplan, men dålig användarupplevelse kan mycket väl vara katastrofal för din produkts framgång.
När du skapar innehåll, var empatisk framför allt annat. Försök att leva din publiks liv.
— Rand Fishkin, grundare av Moz
Ett mindre uppenbart fall, men fortfarande liknande, finns i början av processen, i ”Remix och förbättringar” dag (den andra). Här säger processen dig att ”be alla i teamet att komma med en lista över produkter eller tjänster att granska för inspirerande lösningar” och sedan presentera dem för teamet och skriva ner de mest användbara idéerna i en whiteboard.
Problemet här är att dessa referenser samlas in baserat på teamets personliga preferenser och erfarenheter. Processen överväger inte någon användarinmatning, vilket i själva verket inte är användarcentrerad design. Det är viktigt att ta hänsyn till att en funktion endast är ”bra” från en subjektiv synvinkel.
En bra funktion för någon kan vara disponibel eller till och med skadlig för andra och detsamma gäller användbarhet och användarupplevelse. Vissa människor kan hitta ett visst sätt att visa information intuitivt, medan andra kan tycka att det är förvirrande. En person kan tycka att det är tilltalande och en annan avskräcks av det.
Sättet att lösa det är genom att definiera en användarmålprofil och titta på referenser som personer som passar den profilen har och föredrar. Medan Sprint definierar en målanvändare den första dagen, använder den inte riktigt den för att vägleda ytterligare beslut om produkten. Vi kan inte betona det tillräckligt, du måste design för din målgrupp, inte för dig själv.
Det finns ingen mening (ur perspektivet att säkerställa produktens framgång) att ha någon som ansvarar för användargränssnittet som varken är:
Det enda möjliga skälet till att göra det är att engagera kunder i processen, skapa en bättre relation med dem och ha enklare godkännandeprocesser, eftersom de känner sig som upphovsmännen till lösningen. Det finns dock ingen fördel när det gäller slutproduktens kvalitet.
Faktum är att det till och med kan vara skadligt. I Googles satsningssammanhang kan Sprint fungera på grund av att alla människor är nedsänkta i en designkultur, men när produktägaren är någon som inte kommer från produktdesignmiljön och inte har kunskap om de potentiella användarprofilerna, vänder tidvattnet.
I ProduktdesignprocessDäremot, även om du inte hade chansen att kontakta potentiella användare för att känna till deras personliga referenser och preferenser, fokuserar teamet på att sätta sig i användarens skor, undersöka inte sina egna referenser utan andra produkter som är kända för att användas och uppskattas av målanvändarna.
Du måste förstå användaren. Om du inte kan, han kommer säkert inte att kunna förstå dig heller.
Sammanfattningsvis är Produktdesignprocess bättre än Google Sprint? Det beror på. Google Sprint är väl lämpad för de tidiga stadierna av produktkonceptualiseringen, när du har ett nytt produktkoncept men du inte har definierat det tydligt och du vill få tillgång till dess livskraft.
Det är också avgörande för Google Sprints framgång att hela designteamet känner sin publik. Om så är fallet kan du dra stor nytta av att göra en preliminär sprint.
Om du har fått tillgång till produktens lönsamhet med Google Sprint och vill gå vidare till genomförandet, du kan dra nytta av Produktdesignprocess, vilket inte ställer några begränsningar när du bygger mer komplexa appar eller uppgraderar funktioner. Det är dock också möjligt att starta designen från grunden med det senaste, som täcker hela designprocessen.
Produktdesignprocessen löser problemet med hur du integrerar UX med visuell design. Detta garanterar, för visuella designers, att de har något solidt för att upprätthålla sina val och beslut och inte bara personliga preferenser, vilket underlättar deras arbete.
När det gäller produktchefer garanterar det att UX-design tillför konkret värde till produkten och det är inte slösad ansträngning, vilket gör det tydligt hur varje UX-uppgift återspeglar GUI, vilket också hjälper säljteamet att hantera potentiella kunder och presentera värdet av att anställa UX-designers.
Sist men inte minst betyder det också att utvecklarna inte behöver spendera tid på att fatta - ofta felaktiga - designbeslut, och att gränssnitten som designers levererar är lätta att implementera.
Vid Imaginärt moln vi har ett team av experter på UI och UX design. Om du tror att du kan använda lite hjälp med design, skicka oss en rad här!
Hittade den här artikeln användbar? Du kanske gillar dessa också!
Med 10 års erfarenhet och bakgrund inom kognitiv vetenskap. Jag brinner för inkluderande design och lugn teknik.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
