produkthanteraren beskrivs ofta som ”bron mellan företag, design och teknik”. Bryggan” mellan design och teknik ” är särskilt kritisk när det gäller att leverera en kvalitetsprodukt: buggfri, pixel-perfekt och som tar hänsyn till alla möjliga scenarii och edge-fall. För att säkerställa att bridge fungerar bra, här är flera sätt det hanteras av designteamet:

• designern skickar en omfattande prototyp som visar alla flöden av produkten. Tyvärr kommer det ofta att ta mycket tid och kommer fortfarande att sakna några kantfall.
• designern skickar bara en prototyp som visar funktionens huvudflöden och är fortfarande tillgänglig för frågor från utvecklingsteamet. Tyvärr är dessa fram och tillbaka mycket ineffektiva (särskilt i en fjärrinställning) och slösar mycket tid från både design-och utvecklingsteam.
• designern, förutom den omfattande prototypen, skriver ett korrekt specifikationsdokument som listar alla möjliga scenarii och edge-fall. Problemet är att det ofta är slöseri med tid, eftersom (1) designers dyrbara tid kommer att spenderas bättre genom att faktiskt utforma andra funktioner, inte skriva ett spec doc och (2) de har inte alltid samma 360-bild av produkten som produktchefer gör, vilket kommer att få dem att förbise vissa scenarii och edge-fall.

därför överlåter mogna produktteam vanligtvis skrivandet av sina produktspecifikationer till produktchefer.

men hur ska du skriva produktspecifikationer? Jag har skrivit produktspecifikationer för de senaste 5 åren och jag hittade ett format som är väl uppskattat av mjukvaruteam jag arbetar med. I det här inlägget delar jag mer om min metodik och de verktyg jag använder för att skriva produktspecifikationer. Jag beskriver också några begränsningar som jag står inför med de verktyg jag använder och några förbättringsförslag jag har i åtanke.

här är de 5 huvudämnena som jag tar upp i en produktspecifikation:

1. kontext och mål
2. arkitekturkarta
3. Epics och användarhistorier
4. acceptanskriterier
5. Design, innehåll och översättningar

kontext och mål

även om produktspecifikationen huvudsakligen riktar sig till mjukvaruteam, vill de fortfarande veta varför de arbetar med vad de arbetar med. Jag har förstått att en av de viktigaste drivkrafterna för motivation för mjukvaruingenjörer är påverkan. De flesta drömmer om att arbeta med funktioner som används av miljontals användare. De är glada när de hör att den nya UX de har implementerat har ökat retentionen med 15%, till exempel. Så det är viktigt att ge sammanhang om funktionen de kommer att implementera:

• Vad pratar vi om? Vilken del av produkten? Lägg gärna till någon historia av funktionen som är användbar för att förstå den nuvarande situationen.
• Vad är det aktuella problemet? Obs: Det kan finnas flera problem att lösa.
• finns det någon kvalitativ feedback / verbatims från användare som ska Citeras?
• finns det några data (t. ex. grafer) som ska visas? I det här avsnittet kan du ta med några diagram eller diagram som gör data mer begripliga.
• Vad är den valda lösningen? (beskriv det enkelt, i några meningar)
• har någon annan lösning beaktats? Om ja, varför har det avsatts?
• har någon annan lösning redan implementerats? Hur har det gått?
• vilka är målen ? Finns det några KPI vi försöker påverka? Detta kommer särskilt att hjälpa programvaruteamet att förstå om de behöver implementera nya spårare / taggar / händelser för att korrekt samla in data. Jag har sett Team känna sig så drivna av projektet att de tog initiativ till att ställa in instrumentpaneler för att följa mätvärden i realtid, utan att jag eller någon annan ber om det.

arkitekturkarta

innan du går för mycket in i detaljerna i funktionen är det viktigt att ge en överblick över vad som ändras och vad som förblir detsamma i din produkt. Och även om du arbetar med en helt ny produkt kommer en arkitekturkarta fortfarande att vara extremt relevant för att förstå hur produkten är strukturerad.

”arkitektur karta” är det sätt jag kallar en hög nivå diagram representation av produktens funktioner (flöden, skärmar och innehåll) och hur de är relaterade tillsammans. Vissa kallar det ”informationsarkitektur”, ”Flödeskarta”, ”UX-kartläggning” etc.

exempel på en arkitekturkarta (byggd för en av mina klienter), med en ”före / efter” färgkod

det finns ingen officiell metod för hur man ritar en arkitekturkarta. I en mobilapplikation försöker jag vanligtvis skilja flöden, skärmar och ”delar av en skärm” (eller ”innehåll på sidan”) genom att använda en annan form för var och en av dem, som beskrivs i legenden ovan.

det kan också vara bra att spela på färgkoden. I exemplet ovan använde jag 3 färger och även solid vs. prickad linje för att förklara hur den aktuella informationsarkitekturen skulle uppdateras med UX-moderniseringen av applikationen vi arbetade med. (grön: kommer att stanna som den är, orange: kommer att uppdateras, röd: kommer att raderas; fast: kommer att stanna på samma plats, prickad: kommer att flyttas någon annanstans). På så sätt hade ingenjörer en tydlig fågelperspektiv på vilken del av ansökan som skulle komma att ändras.

ett annat tips för att bygga en förståelig arkitekturkarta är att tydligt skilja de olika delarna av navigeringen, som görs nedan med separata områden för var och en av dem.

att ha en arkitekturkarta kommer att vara mycket användbart för din produktspecifikation; det gör att du kan markera vilken del av produkten du pratar om i var och en av dina användarhistorier.

vilket verktyg ska du använda för att rita en arkitekturkarta? Det finns massor av dem tillgängliga där ute, min favorit är nyckfull (eftersom den är visuellt trevlig och väldigt enkel, inte rörig med så många funktioner), men jag använde också Draw.io tidigare-vilket är intressant eftersom det är integrerat med Google Drive, så om du arbetar med Google Slides och Google Docs gör det trevligt att använda. Det är också integrerat med JIRA och Confluence.

Om du vill lära dig mer om arkitekturkartor (gör och gör inte, vilka verktyg du ska använda, några exempel etc.), Toptal har kommit med en bra läsning: Den omfattande guiden till informationsarkitektur.

Epics och användarhistorier

att bryta ner och förklara alla delar av din produkt kan mycket snabbt bli ganska kaotiskt. Skriva produktspecifikationer under de senaste 5 åren, det bästa sättet jag har hittat för att hålla specifikationerna organiserade och begripliga är att bryta ner dem enligt ”användarhistorier”.

vad är en användarhistoria? Enligt Agile Modeling är en användarhistoria ”en mycket hög nivå definition av ett krav, som innehåller tillräckligt med information så att utvecklarna kan producera en rimlig uppskattning av ansträngningarna att genomföra den.”

tanken med användarhistorier är att sätta användarna först och undvika att använda exklusivt obscure & teknisk ordförråd när man diskuterar funktioner. Som Atlassian uttrycker det: ”efter att ha läst en användarhistoria vet teamet varför de bygger vad de bygger och vilket värde det skapar.”

de syftar till att bygga en bättre produkt där användaren står i centrum för debatterna, i motsats till god gammal vattenfallsproduktutveckling.

Så här ska en användarhistoria formuleras:

som en < typ av användare >, jag vill ha < något mål > så att < någon anledning >.

till exempel, så här kan vi formulera användarhistorier för följande kapitel i arkitekturkartan som jag ritade för en av mina klienter:

• användarhistoria #1: som anställd på profilsektionen vill jag redigera min profil så att jag kan uppdatera mitt foto, förnamn och efternamn.
• användarberättelse # 2: Som anställd i profilsektionen vill jag komma åt inställningarna så att jag kan uppdatera mitt lösenord och uppdatera meddelandeinställningar.
• användarhistoria # 3: som anställd på profilsektionen vill jag komma åt chatten så att jag kan ge feedback till appens utvecklare

det är upp till produktchefen att bestämma vilken detaljnivå de vill täcka i användarberättelsen. Om vi ville, kunde vi också gå en nivå djupare i Användarberättelsen #2, till exempel:

• användarberättelse #2.a: Som anställd i inställningarna vill jag komma åt avsnittet ”Redigera lösenord” så att jag kan uppdatera mitt lösenord
• användarhistoria #2.b: som anställd i inställningarna vill jag komma åt aviseringsinställningarna så att jag kan uppdatera vid vilken frekvens jag får varje typ av aviseringar

men som du ser är detta något uppenbart och överflödigt. Jag valde personligen att täcka dessa scenarii i” acceptanskriterier ” (se nästa avsnitt) av berättelserna i fråga.

för att organisera användarhistorier använder vi ofta ”epics”. I smidiga termer är” epics ” stora mängder arbete som kan delas upp i mindre användarhistorier. Jag använder personligen epics för att gruppera berättelser som ingår i samma tema eller område i produkten. Till exempel, Jag har valt att gruppera berättelserna ovan som en del av ”profil” epic. Vissa väljer att formulera epics på samma sätt som användarhistorier, med en enklare struktur (t. ex. ”Som användare vill jag komma åt min profil”)

acceptanskriterier

för att se till att tillräckligt med detaljer läggs till i en användarhistoria använder vi ”acceptanskriterier” (ibland även kallade ”villkor för tillfredsställelse”).

enligt LeadingAgile.com, ” acceptanskriterier ”är” de villkor som en mjukvaruprodukt måste uppfylla för att accepteras av en användare, kund eller i fallet med systemnivåfunktionalitet, det konsumerande systemet.”

i acceptanskriterierna bör du lista alla funktionella specificiteter som inte tydligt stavas ut av användarberättelsen. Exempel:

användarhistoria

som anställd på profilsektionen vill jag redigera min profil så att jag kan uppdatera mitt foto, förnamn och efternamn.

acceptanskriterier

• med tanke på att jag är på redigeringsprofilskärmen när jag klickar på ikonen Redigera förnamn ska den växla till redigeringsläge, fokusera på ingången och öppna tangentbordet (samma för efternamn)
• med tanke på att jag är på redigeringsprofilskärmen när jag klickar på ikonen Redigera foto då borde det Be mig att välja mellan kamera och bibliotek
• med tanke på att jag redigerar mitt förnamn när jag klickar på ”Spara” så ska det omdirigera mig till läsläget och jag borde se en framgångsmeddelande

etc…

tänk på acceptanskriterierna som A checklista som måste fyllas i för att produkten ska skickas. Det givna/När / då-formatet som används ovan är ett bra sätt att hjälpa dig att formulera dina acceptanskriterier, men i vissa fall kan det vara utmanande att använda.

Design, innehåll och översättningar

med uppdaterade mönster i dina produktspecifikationer

hittills har jag inte nämnt vilket verktyg jag använder för att skriva SPECIFIKATIONER. Tidigare har jag bytt mellan Google Docs, Google Slides och Notion. Jag tyckte verkligen om att använda Notion för alla coola integrationer som den erbjuder (särskilt de med Invision och Figma). Men jag har nu helt bytt till Google Docs: jag föredrar att ha mer frihet på hur jag formaterar mina produktspecifikationer. Det är också bekvämare att använda Googles produkter när du arbetar med externa partners eller kunder.

för att säkerställa att din produkts visuella identitet är korrekt väcks till liv av utvecklingsteamet, är det viktigt att ge dem tillgång till de mest up-to-date skärmar levereras av din designer(s). Men eftersom det inte finns någon verklig integration mellan Google Docs och designverktyg som Figma, Invision eller Zeplin, brukade jag exportera skärmar och kopiera/klistra in dem i mina produktspecifikationer.

detta skulle mycket snabbt bli ett problem: designers itererar på sina skärmar dagligen, och även när allt har överenskommits på en skärm kan det ändras några veckor senare på grund av att en specifik komponent uppdateras i designbiblioteket. Detta skulle få mina SPECIFIKATIONER att vara föråldrade för det mesta.

det är därför jag idag bara använder skärmens namn. Till exempel, om en användarhistoria om profilutgåva handlar om 2 skärmar som har utformats på Figma, skriver jag bara ”Figma skärmnamn: Redigera-profil-1 och redigera-profil-2”.

naturligtvis är detta inte idealiskt och begränsar utvecklare eller någon annan som läser mina specifikationer för att växla mellan flera verktyg.

men det här visar att det idag finns något ineffektivt i hur vi skriver produktspecifikationer. Att använda flera produkter väcker frågor om integration och synkronisering. Hur ser man till att all information som behövs för att bygga en produkt är synlig på ett enda ställe utan att vara föråldrad? (Egentligen gäller detta inte bara mönster utan också arkitekturkartor och innehåll).

om du också upplever det här problemet och har hittat en lösning, skulle jag vara intresserad av att få din feedback!

ger enkel åtkomst till innehåll och översättningar för att undvika skrivfel

När du designar skärmar med en stor mängd innehåll är det trevligt att ge utvecklare möjlighet att enkelt kopiera/klistra in det istället för att behöva skriva om det själva. Annars kan du sluta med (1) många skrivfel och (2) förbannade Utvecklare. Det finns flera sätt du kan ge dem tillgång till innehållet:

• genom att ge dem tillgång till källfilerna för designarbetet på Sketch, Figma eller Zeplin till exempel.
• genom att kopiera / klistra in innehållet direkt i specifikationen (det kan göra det lite rörigt).

om din produkt finns på flera språk, ge också tillgång till varje översättning. Du kan till exempel använda en matris för att visa översättningen av ditt ursprungliga innehåll på varje språk. Nästa nivå av översättningshantering är att använda ett lokaliseringsverktyg (som fras) och bara lägga till ”översättningsnycklarna” i din produktspecifikation. Men igen innebär detta ytterligare en fram och tillbaka mellan dina produktspecifikationer och ett annat verktyg.