produktsjefen blir ofte beskrevet som»broen mellom business, design og tech». Broen» mellom design og tech » – delen er spesielt kritisk når det gjelder frakt av et kvalitetsprodukt: bug-free, pixel-perfect og som tar hensyn til alle mulige scenarii og edge tilfeller. For å sikre at bridge fungerer bra, er det flere måter det håndteres av designteamet:

• designeren sender en omfattende prototype som viser alle flytene av produktet. Dessverre vil dette ofte ta mye tid og vil fortsatt savne noen kantsaker.
• designeren vil bare sende en prototype som viser hovedflyten av funksjonen, og er fortsatt tilgjengelig for spørsmål fra utviklingsteamet. Dessverre er disse frem og tilbake svært ineffektive (spesielt i et eksternt oppsett) og kaster bort mye tid fra både design og utviklingsteam.
• designeren, i tillegg til den omfattende prototypen, skriver et riktig spesifikasjoner dokument som viser alle mulige scenarii og edge tilfeller. Problemet er at det ofte er sløsing med tid, fordi (1) designers dyrebare tid vil bli bedre brukt ved å faktisk designe andre funksjoner, ikke skrive et spec doc, og (2) de har ikke alltid den samme 360° visningen av produktet som produktledere gjør, noe som vil få dem til å overse noen scenarii og kantsaker.

det er derfor modne produktteam vanligvis overlater skrivingen av produktspesifikasjonene til produktledere.

men hvordan skal du skrive produktspesifikasjoner? Jeg har skrevet produktspesifikasjoner de siste 5 årene, og jeg fant et format som er godt verdsatt av programvareteamene jeg jobber med. I dette innlegget deler jeg mer om metodikken min og verktøyene jeg bruker til å skrive produktspesifikasjoner. Jeg beskriver også noen begrensninger som jeg står overfor med verktøyene jeg bruker og noen ideer om forbedring jeg har i tankene.

her er de 5 hovedtemaene jeg adresserer i en produktspesifikasjon:

1. Kontekst og mål
2. Arkitekturkart
3. Epics Og Brukerhistorier
4. Akseptkriterier
5. Design, innhold og oversettelser

Kontekst og mål

Selv om produktspesifikasjonen hovedsakelig er rettet mot programvareteam, liker de fortsatt å vite hvorfor de jobber med det de jobber med. Jeg har kommet for å forstå at en av hoveddriverne for motivasjon for programvareingeniører er innvirkning. De fleste drømmer om å jobbe med funksjoner som brukes av millioner av brukere. De er begeistret når de hører at den nye UX de har implementert, har økt oppbevaring med 15%, for eksempel. Så det er viktig å gi kontekst om funksjonen de skal implementere:

• Hva snakker vi om? Hvilken del av produktet? Føl deg fri til å legge noen historie av funksjonen som er nyttig for å forstå dagens situasjon.
• Hva er det nåværende problemet? Merk: det kan være flere problemer å løse.
• Er det noen kvalitative tilbakemeldinger / ordrett fra brukere å bli sitert?
• Er det noen data (f. eks. grafer) som skal vises? I denne delen, gjerne inkludere noen diagrammer eller grafer som vil gjøre dataene mer forståelig.
• Hva er den valgte løsningen? (beskriv det enkelt, i noen få setninger)
• Har noen annen løsning blitt vurdert? Hvis ja, hvorfor er det lagt til side?
• har noen annen løsning allerede blitt implementert? Hvordan har det vært utført?
• Hva er målene ? Er DET NOEN KPI vi prøver å påvirke? Dette vil spesielt hjelpe programvareteamet til å forstå om de trenger å implementere nye sporere / tagger / hendelser for å samle inn dataene riktig. Jeg har sett team som føler seg så drevet av prosjektet at de tok initiativ til å sette opp dashboards for å følge beregninger i sanntid, uten at jeg eller noen andre ber om det.

Arkitekturkart

før du går for mye inn i detaljene i funksjonen, er det viktig å gi et høyt nivå oversikt over hvilke endringer og hva som forblir det samme i produktet. Og selv om du jobber med et helt nytt produkt, vil et arkitekturkart fortsatt være svært relevant for å forstå hvordan produktet er strukturert.

«Arkitekturkart» er måten jeg kaller en diagramrepresentasjon på høyt nivå av produktets funksjoner (flyter, skjermer og innhold) og hvordan de er relatert sammen. Noen kaller det «Informasjonsarkitektur»,» Flyt kart»,» UX kartlegging», etc.

eksempel På et arkitekturkart (bygget for en av mine klienter), med en»før/etter»fargekode

det er ingen offisiell metodikk for hvordan man tegner et arkitekturkart. På en mobilapplikasjon prøver jeg vanligvis å skille mellom strømmer, skjermer og » deler av en skjerm «(eller «innhold på siden»), ved å bruke en annen form for hver av dem, som beskrevet i legenden ovenfor.

det kan også være nyttig å spille på fargekoden. I eksemplet ovenfor brukte jeg 3 farger og også solid vs. prikket linje for å forklare hvordan dagens informasjonsarkitektur ville bli oppdatert MED UX-oppgraderingen av søknaden vi jobbet med. (grønn: vil bli som den er, oransje: vil bli oppdatert, rød: vil bli slettet; solid: vil bli på samme sted, prikket: vil bli flyttet et annet sted). På den måten hadde ingeniører et klart fugleperspektiv på hvilken del av søknaden som kunne endres.Et annet tips for å bygge et forståelig arkitekturkart er å tydelig skille de ulike delene av navigasjonen, som gjort nedenfor med separate områder for hver av dem.

den nye versjonen av arkitekturkartet bygget for min klient

å ha et arkitekturkart vil være ekstremt nyttig for produktspesifikasjonen din; det vil gjøre deg i stand til å markere hvilken del av produktet du snakker om i hver av dine brukerhistorier.

Hvilket verktøy skal du bruke til å tegne et arkitekturkart? Det er tonnevis av dem tilgjengelig der ute, min favoritt Er Lunefull (fordi det er visuelt hyggelig og veldig grei, ikke rotete med så mange funksjoner), men jeg brukte også Draw.io tidligere-noe som er interessant fordi Det er integrert Med Google Disk, så hvis Du jobber Med Google Slides og Google Docs, gjør det det fint å bruke. Det er også integrert MED JIRA og Confluence.

hvis du vil lære mer om arkitekturkart (do ‘s and don’ ts, hvilke verktøy du skal bruke, noen eksempler, etc.), Toptal har kommet opp med en stor lese: Den Omfattende Guide Til Informasjonsarkitektur.

Epics og Brukerhistorier

Å Bryte ned og forklare alle deler av produktet ditt kan veldig raskt bli ganske kaotisk. Skrive produktspesifikasjoner i løpet av de siste 5 årene, den beste måten jeg har funnet for å holde spesifikasjonene organisert og forståelig, er å bryte dem ned i henhold til «brukerhistorier».

hva er en brukerhistorie? Ifølge Agile Modeling er en brukerhistorie » en svært høy definisjon av et krav, som inneholder akkurat nok informasjon slik at utviklerne kan produsere et rimelig estimat av innsatsen for å implementere den.»

ideen med brukerhistorier er å sette brukerne først og unngå å bruke utelukkende obskure& teknisk ordforråd når man diskuterer funksjoner. Som Atlassian sier det: «etter å ha lest en brukerhistorie, vet teamet hvorfor de bygger det de bygger og hvilken verdi det skaper.»

De er rettet mot å bygge et bedre produkt der brukeren er i sentrum av debattene, i motsetning til god gammel foss produktutvikling.

slik skal en brukerhistorie formuleres:

Som en < type bruker >, jeg vil < noen mål > slik at < en eller annen grunn >.

for eksempel, Slik kan vi formulere brukerhistorier for følgende del av arkitekturkartet jeg tegnet for en av mine klienter:

• brukerhistorie #1: som ansatt i profildelen vil jeg redigere profilen min slik at jeg kan oppdatere bilde, fornavn og etternavn.
• Brukerhistorie # 2: Som ansatt i profildelen vil jeg ha tilgang til innstillingene slik at jeg kan oppdatere passordet mitt og oppdatere varslingsinnstillingene.3: Som ansatt i profildelen vil jeg ha tilgang til chatten, slik at jeg kan gi tilbakemelding til appens utviklere

det er opp til produktsjefen å bestemme hvilket nivå av detaljer de vil dekke i brukerhistorien. Hvis vi ville, kunne vi også gå et nivå dypere i User Story #2, for eksempel:

• User Story #2.a: Som ansatt i innstillingene vil jeg få tilgang til» rediger passord » – delen slik at jeg kan oppdatere passordet Mitt
• User Story #2.b: som ansatt i innstillingene vil jeg få tilgang til varslingsinnstillingene, slik at jeg kan oppdatere hvor ofte jeg mottar hver type varsler, Men som du ser, er dette noe åpenbart og overflødig. Jeg valgte personlig å dekke disse scenariene i «akseptkriteriene» (se neste avsnitt) av de aktuelle historiene.

  for å organisere brukerhistorier bruker vi ofte «epics». I smidige termer er» epics » store mengder arbeid som kan brytes ned i mindre brukerhistorier. Jeg bruker personlig epics til å gruppere historier som er en del av samme tema eller område i produktet. For eksempel, jeg har valgt å gruppere historiene ovenfor som en del av «Profil» epic. Noen velger å formulere epos på samme måte som brukerhistorier, med en enklere struktur (f. eks. «Som bruker vil jeg ha tilgang til profilen min»)

  Akseptkriterier

  for å sikre at nok detaljer er lagt til i en brukerhistorie, bruker vi » akseptkriterier «(noen ganger også kalt»vilkår for tilfredshet»).

  I Henhold Til LeadingAgile.com «akseptkriterier» er » betingelsene som et programvareprodukt må tilfredsstille for å bli akseptert av en bruker, kunde eller i tilfelle systemnivåfunksjonalitet, forbrukersystemet.»

  i akseptkriteriene bør du liste opp alle funksjonelle spesifikasjoner som ikke er tydelig stavet ut av brukerhistorien. Eksempel:

  Brukerhistorie

  som ansatt i profildelen vil jeg redigere profilen min slik at jeg kan oppdatere bilde, fornavn og etternavn.Gitt at jeg er på rediger profil skjermen når jeg klikker på rediger fornavn ikonet så det bør bytte til redigeringsmodus, fokusere på inngangen og åpne tastaturet (samme for etternavn)

• Gitt at Jeg er på rediger profil skjermen når jeg klikker på rediger bilde ikonet så det bør be meg om å velge mellom kamera og bibliotek
• Gitt at jeg redigerer mitt fornavn når jeg klikker på «lagre» så det bør omdirigere meg til lesemodus og jeg burde se en suksessvarsling

etc…

tenk på akseptkriteriene som en sjekkliste som må fylles ut for at produktet skal sendes. Det Gitte / Når / da-formatet som brukes ovenfor, er en god måte å hjelpe deg med å formulere akseptkriteriene dine, men i noen tilfeller kan det være utfordrende å bruke.

Design, innhold og oversettelser

Å Ha oppdatert design i produktspesifikasjonene

Så langt har Jeg ikke nevnt hvilket verktøy jeg bruker til å skrive spesifikasjoner. Tidligere har jeg byttet Mellom Google Docs, Google Slides og Notion. Jeg likte virkelig Å bruke Notion for alle de kule integrasjonene det tilbyr(spesielt De Med InVision og Figma). Men jeg har nå helt byttet Til Google Docs: jeg foretrekker å ha mer frihet på måten jeg formaterer produktspesifikasjonene mine. Det er også enklere å bruke Google-produkter når du arbeider med eksterne partnere eller kunder.

for å sikre at produktets visuelle identitet blir nøyaktig levendegjort av utviklingsteamet, er det viktig å gi dem tilgang til de mest oppdaterte skjermene som leveres av designeren(e). Men siden Det ikke er noen reell integrasjon mellom Google Docs og designverktøy som Figma, InVision eller Zeplin, pleide jeg å eksportere skjermer og kopiere/lime dem inn i produktspesifikasjonene mine.

dette vil raskt bli et problem: designere itererer på skjermene sine daglig, og selv når alt er avtalt på en skjerm, kan det endres noen uker senere på grunn av at en bestemt komponent oppdateres i designbiblioteket. Dette vil føre til at spesifikasjonene mine blir utdaterte mesteparten av tiden.

Derfor bruker jeg bare skjermens navn i dag. For eksempel, hvis en brukerhistorie om profilutgave handler om 2 skjermer som er designet På Figma, vil jeg bare skrive «Figma skjermnavn: rediger-profil-1 og rediger-profil-2».Selvfølgelig er dette ikke ideelt og begrenser utviklere eller noen andre som leser spesifikasjonene mine for å bytte mellom flere verktøy.

Men dette viser at det i dag er noe ineffektivt i måten vi skriver produktspesifikasjoner på. Ved å bruke flere produkter reiser spørsmålene om integrasjon og synkronisering. Hvordan sikre at all informasjon som trengs for å bygge et produkt, er synlig på ett sted, uten å være utdatert? (Faktisk gjelder dette ikke bare design, men også arkitekturkart og innhold).

→ hvis du også opplever dette problemet og har funnet en løsning, vil jeg være interessert i å få tilbakemelding!

Gir enkel tilgang til innhold og oversettelser for å unngå skrivefeil

når du designer skjermer med mye innhold, er det fint å gi utviklere muligheten til enkelt å kopiere / lime det inn i stedet for å måtte skrive det selv. Ellers kan du ende opp med (1) mange skrivefeil og (2) pissed utviklere. Det er flere måter du kan gi dem tilgang til innholdet:

• Ved å gi dem tilgang til kildefilene til designarbeidet På Sketch, Figma eller Zeplin for eksempel.
• ved å kopiere / lime inn innholdet direkte i spec (det kan gjøre det litt rotete).

hvis produktet finnes på flere språk, også gi tilgang til hver oversettelse. Du kan for eksempel bruke en matrise til å vise oversettelsen av det opprinnelige innholdet på hvert språk. Det neste nivået av oversettelsesadministrasjon er å bruke et lokaliseringsverktøy (som Phrase) og bare legge til «oversettelsesnøklene» i produktspesifikasjonen. Men igjen, dette innebærer en mer frem og tilbake mellom produktspesifikasjoner og et annet verktøy.