tuotepäällikköä kuvataan usein ”siltana liiketoiminnan, muotoilun ja teknologian välillä”. Bridge ”between design and tech” -osa on erityisen kriittinen, kun kyseessä on laadukkaan tuotteen toimitus: virheetön, pikselitäydellinen ja joka ottaa huomioon kaikki mahdolliset scenarii-ja edge-tapaukset. Sillan toimivuuden varmistamiseksi suunnittelutiimi hoitaa sen monella tavalla:

• suunnittelija toimittaa kattavan prototyypin, joka näyttää kaikki tuotteen virrat. Valitettavasti tämä vie usein paljon aikaa ja jää silti kaipaamaan muutamia reunatapauksia.
• suunnittelija lähettää vain prototyypin, joka näyttää ominaisuuden päävirrat, ja jää nähtäväksi kehitystiimin kysymyksiin. Valitettavasti nämä edestakaisin ovat erittäin tehottomia (erityisesti etäasetuksissa) ja tuhlaavat paljon aikaa sekä suunnittelu-että kehitystiimiltä.
• suunnittelija kirjoittaa kattavan prototyypin lisäksi kunnollisen spesifikaatioasiakirjan, jossa luetellaan kaikki mahdolliset scenarii-ja edge-tapaukset. Ongelmana on, että se on usein ajanhukkaa, koska (1) suunnittelijoiden arvokasta aikaa käytetään paremmin suunnittelemalla muita ominaisuuksia, ei kirjoittamalla spec doc, ja (2) heillä ei aina ole samaa 360°: n näkymää tuotteesta kuin tuotepäälliköillä, mikä saa heidät unohtamaan joitakin scenarii-ja edge-tapauksia.

siksi kypsät tuotetiimit antavat yleensä tuotepäälliköiden tehtäväksi laatia tuoteprofiilinsa.

mutta miten tuoteselosteet pitäisi kirjoittaa? Olen kirjoittanut tuotetiedot Viimeiset 5 vuotta ja löysin muoto, joka on hyvin arvostettu ohjelmisto joukkueet työskentelen. Tässä viestissä, olen jakaa enemmän minun menetelmiä ja työkaluja käytän kirjoittaa tuotteen tekniset tiedot. Olen myös kuvataan joitakin rajoituksia, että olen edessään työkaluja käytän ja joitakin parannusideoita minulla on mielessä.

tässä ovat 5 pääaihetta, joita käsittelen tuotespektissä:

1. Context and objectives
2. Arkkitehtuurikartta
3. epics and User stories
4. hyväksymiskriteerit
5. Design, content and translations

Context and objectives

Olen oppinut ymmärtämään, että yksi tärkeimmistä ohjelmistoinsinöörien motivaation ajureista on vaikutus. Useimmat heistä haaveilevat työstävänsä ominaisuuksia, joita miljoonat käyttäjät käyttävät. He ovat innoissaan, kun he kuulevat, että uusi UX he ovat ottaneet käyttöön on lisännyt säilyttäminen 15%, esimerkiksi. Siksi on tärkeää antaa kontekstia siitä, mitä ominaisuutta he toteuttavat:

• mistä me puhumme? Mikä osa tuotetta? Voit vapaasti lisätä mitään historiaa ominaisuus, joka on hyödyllistä ymmärtää nykytilanteen.
• mikä on nykyinen ongelma? Huomautus: voi olla useita ongelmia ratkaista.
• onko käyttäjiltä lainattavaa laadullista palautetta / verbatimeja?
• onko mitään tietoja (esim. graafeja) näytettävänä? Tässä osiossa voit vapaasti sisällyttää kaavioita tai kaavioita, jotka tekevät tiedoista ymmärrettävämpiä.
• mikä on valittu ratkaisu? (kuvaile se yksinkertaisesti, muutamalla lauseella)
• onko mitään muuta ratkaisua harkittu? Jos on, miksi se on pantu syrjään?
• onko jokin muu ratkaisu jo toteutettu? Miten se on toiminut?
• mitkä ovat tavoitteet ? Yritämmekö iskeä johonkin KPI: hen? Tämä auttaa erityisesti ohjelmistotiimiä ymmärtämään, jos heidän on toteutettava uusia jäljittimiä / tageja / tapahtumia tietojen keräämiseksi oikein. Olen nähnyt tiimien tuntevan itsensä projektista niin innostuneiksi, että he ryhtyivät oma-aloitteisesti asentamaan mittaristoja seuraamaan mittareita reaaliaikaisesti ilman, että minä tai kukaan muu sitä pyytäisi.

Arkkitehtuurikartta

ennen kuin menee liikaa ominaisuuden yksityiskohtiin, on tärkeää antaa korkeatasoinen yleiskuva siitä, mikä tuotteessasi muuttuu ja mikä pysyy samana. Ja vaikka työstäisit täysin uutta tuotetta, arkkitehtuurikartta on silti erittäin merkityksellinen tuotteen rakenteen ymmärtämiseksi.

”Arkkitehtuurikartaksi” kutsun korkean tason diagrammia, joka kuvaa tuotteen ominaisuuksia (virtauksia, näyttöjä ja sisältöä) ja miten ne liittyvät toisiinsa. Jotkut kutsuvat sitä ”Tietoarkkitehtuuriksi”, ”Virtauskartaksi”, ”UX-kartoitukseksi” jne.

ei ole virallista menetelmää, miten arkkitehtuurikartta piirretään. Mobiilisovelluksessa yritän yleensä erottaa virrat, näytöt ja ”näytön osat” (tai ”sivun sisältö”) käyttämällä eri muotoa kullekin, kuten yllä olevassa legendassa on esitetty.

voi olla myös hyödyllistä pelata värikoodilla. Yllä olevassa esimerkissä käytin 3 väriä ja myös solid vs. katkoviiva selittää, miten nykyinen tietoarkkitehtuuri päivitettäisiin UX-uudistuksella sovelluksen työskentelimme. (vihreä: pysyy sellaisena kuin on, oranssi: päivitetään, punainen: poistetaan; kiinteä: pysyy samassa paikassa, pistemäinen: siirretään jonnekin muualle). Näin insinööreillä oli selkeä lintuperspektiivi siitä, mikä osa sovelluksesta muuttuisi.

toinen vinkki ymmärrettävän arkkitehtuurikartan rakentamiseen on selvästi erottaa navigoinnin eri osat toisistaan, kuten alla tehdään erillisillä alueilla kullekin.

, jolla on arkkitehtuurikartta, on erittäin hyödyllinen tuotekehityksessä; sen avulla voit korostaa, mistä osasta tuotetta puhut kussakin käyttäjän tarinoita.

millä työkalulla arkkitehtuurikartta piirretään? On tonnia niitä saatavilla siellä, suosikkini on oikukas (koska se on visuaalisesti miellyttävä ja hyvin suoraviivainen, ei täynnä niin monia ominaisuuksia), mutta käytin myös Draw.io aiemmin-mikä on mielenkiintoista, koska se on integroitu Google Driveen, joten jos työskentelet Google Slidesin ja Google Docsin kanssa, sitä on mukava käyttää. Se on myös integroitu JIRA ja Confluence.

Jos haluat oppia lisää arkkitehtuurikartoista (do ’s and don’ t, which tools to use, some examples, jne.), Toptal on keksiä suuri lukea: kattava opas informaatioarkkitehtuuri.

eepokset ja Käyttäjätarinat

tuotteen kaikkien osien hajottaminen ja selittäminen voi hyvin nopeasti muuttua varsin kaoottiseksi. Kirjoittaminen tuotteen tiedot viimeisten 5 vuoden aikana, paras tapa olen löytänyt pitää tiedot järjestetty ja ymmärrettävä on hajottaa ne mukaan ”user stories”.

mikä on käyttäjän tarina? Agile Modelingin mukaan käyttäjätarina on ” erittäin korkeatasoinen vaatimuksen määritelmä, joka sisältää juuri sen verran tietoa, että kehittäjät voivat tuottaa kohtuullisen arvion sen toteuttamisesta.”

käyttäjien tarinoiden ideana on asettaa käyttäjät etusijalle ja välttää käyttämästä yksinomaan epämääräistä & teknistä sanastoa keskusteltaessa ominaisuuksista. Kuten Atlassian asian ilmaisee: ”luettuaan käyttäjätarinan tiimi tietää, miksi he rakentavat sitä, mitä he rakentavat, ja mitä arvoa se luo.”

niiden tarkoituksena on rakentaa parempi tuote, jossa käyttäjä on keskustelujen keskipisteessä, vastoin vanhaa kunnon vesiputouksen tuotekehitystä.

näin käyttäjän tarina pitäisi muotoilla:

kuin < käyttäjän tyyppi >, haluan < jonkun maalin > siten, että < jostain syystä >.

esimerkiksi näin voisimme muotoilla käyttäjätarinoita seuraavaan osaan arkkitehtuurikartasta, jonka piirsin eräälle asiakkaalleni:

• user story #1: profiiliosion työntekijänä haluan muokata profiiliani, jotta voin päivittää kuvani, etunimeni ja sukunimeni.
• User Story #2: Profiiliosion työntekijänä haluan käyttää asetuksia, jotta voin päivittää salasanani ja päivittää ilmoitusasetukset.
• User Story #3: profiiliosion työntekijänä haluan päästä chattiin, jotta voin antaa palautetta sovelluksen kehittäjille

on tuotepäällikön päätettävissä, minkä tason yksityiskohtia he haluavat käsitellä käyttäjän tarinassa. Halutessaan voisimme mennä myös yhtä tasoa syvemmälle käyttäjän tarinaan #2, esimerkiksi:

• käyttäjän tarina #2.a: Työntekijänä asetuksissa haluan päästä ”Muokkaa salasanaa” – osioon, jotta voin päivittää salasanani
• User Story #2.b: työntekijänä asetuksissa haluan käyttää ilmoitusasetuksia, jotta voin päivittää, millä taajuudella saan kunkin ilmoitustyypin

, mutta kuten näette, tämä on jokseenkin ilmeistä ja tarpeetonta. Itse valitsin nämä skenarii-aiheet kyseisten tarinoiden” hyväksymiskriteereissä ” (katso seuraava jakso).

käyttäjien tarinoiden järjestämiseen käytetään usein ”eepoksia”. Ketterästi ”eepokset” ovat suuria työmääriä, jotka voidaan jakaa pienempiin käyttäjätarinoihin. Itse käytän eepoksia ryhmittelemään tarinoita, jotka ovat osa samaa teemaa tai aluetta tuotteessa. Olen esimerkiksi päättänyt ryhmitellä yllä olevat tarinat osaksi ”Profile” – eeposta. Jotkut päättävät muotoilla eepokset samalla tavalla kuin käyttäjätarinat, yksinkertaisemmalla rakenteella (esim. ”Käyttäjänä haluan käyttää profiiliani”)

hyväksymiskriteerit

varmistaaksemme, että käyttäjän tarinaan lisätään tarpeeksi yksityiskohtia, käytämme” hyväksymiskriteerejä ”(joskus myös”tyydytyksen ehtoja”).

mukaan LeadingAgile.com, ” hyväksymiskriteerit ”ovat” ehtoja, jotka ohjelmistotuotteen on täytettävä, jotta käyttäjä, asiakas tai järjestelmätason toiminnallisuuden tapauksessa kuluttava järjestelmä hyväksyy sen.”

hyväksymiskriteereissä kannattaa listata kaikki toiminnalliset erityispiirteet, joita käyttäjän tarina ei selkeästi kerro. Esimerkiksi:

User Story

profiiliosion työntekijänä haluan muokata profiiliani, jotta voin päivittää kuvani, etunimeni ja sukunimeni.

hyväksymiskriteerit

• koska olen muokkausprofiilin näytöllä, kun napsautan muokkaa etunimeä-kuvaketta, sen pitäisi siirtyä muokkaustilaan, keskittyä syöttöön ja avata näppäimistö (sama sukunimelle)
• koska olen muokkausprofiilin näytöllä, kun napsautan muokkaa valokuvakuvaketta, sen pitäisi pyytää minua valitsemaan kameran ja kirjaston välillä
• koska muokkaan etunimeäni, kun napsautan ”tallenna”, sen pitäisi ohjata minut lukutilaan ja I should see a success notification

etc…

think of the acceptance criteria as a tarkistuslista, joka on täytettävä Tuotteen lähettämistä varten. Edellä käytetty Given / When / Then-muoto on hyvä tapa auttaa sinua muotoilemaan hyväksymiskriteerisi, mutta joissakin tapauksissa sen käyttäminen voi olla haastavaa.

Design, content and translations

Having up-to-date designs in your product specs

So far, I have not mentioned which tool I ’ m using to write specifications. Aiemmin, olen vaihtanut Google Docs, Google Slides ja Notion. Olen todella nauttinut käyttää käsite kaikki viileä integraatiot se tarjoaa (erityisesti niitä InVision ja Figma). Mutta olen nyt täysin siirtynyt Google Docs: mieluummin ottaa enemmän vapautta tavalla muotoilen minun tuotteen tekniset tiedot. On myös helpompaa käyttää Googlen tuotteita, kun työskentelet ulkopuolisten kumppanien tai asiakkaiden kanssa.

varmistaaksesi, että kehitystiimi herättää tuotteesi visuaalisen identiteetin tarkasti eloon, on tärkeää antaa heille pääsy suunnittelijasi(suunnittelijoidesi) toimittamiin ajantasaisimpiin näyttöihin. Mutta koska Google-dokumenttien ja suunnittelutyökalujen, kuten Figman, Invisionin tai Zeplinin, välillä ei ole todellista integraatiota, käytin näyttöjen vientiä ja niiden kopioimista/liittämistä tuotetietoihini.

tästä tulisi hyvin nopeasti ongelma: suunnittelijat iteroivat näytöillään päivittäin, ja vaikka kaikki on sovittu näytöllä, se voi muuttua muutaman viikon kuluttua, koska yksi tietty komponentti päivitetään suunnittelukirjastoon. Tämä johtaisi siihen, että silmälasini olisivat vanhentuneet suurimman osan ajasta.

siksi käytän tänään vain näyttöjen nimeä. Esimerkiksi, jos käyttäjä tarina profile edition on noin 2 näytöt, jotka on suunniteltu Figma, kirjoitan vain ”Figma screen name: edit-profile-1 ja edit-profile-2”.

tämä ei tietenkään ole ihanteellinen ja rajoittaa kehittäjiä tai muita, jotka lukevat minun määrityksiäni, vaihtamaan useiden työkalujen välillä.

mutta tämä osoittaa, että tänään on jotain tehotonta tavassa kirjoittaa tuote-eritelmiä. Useiden tuotteiden käyttö herättää kysymyksiä integraatiosta ja synkronoinnista. Miten varmistaa, että kaikki tuotteen rakentamiseen tarvittavat tiedot näkyvät yhdessä paikassa ilman, että ne ovat vanhentuneita? (Itse asiassa tämä ei koske vain malleja, vaan myös arkkitehtuurin karttoja ja sisältöä).

→ Jos koet myös tämän ongelman ja olet löytänyt ratkaisun, olisin kiinnostunut saamaan palautteesi!

tarjoaa helpon pääsyn sisältöön ja käännöksiin kirjoitusvirheiden välttämiseksi

kun suunnittelet näyttöjä, joissa on paljon sisältöä, on mukavaa antaa kehittäjille mahdollisuus kopioida / liittää se helposti sen sijaan, että heidän pitäisi kirjoittaa se uudelleen itse. Muuten, saatat päätyä (1) monia kirjoitusvirheitä ja (2) vihainen Kehittäjät. On olemassa useita tapoja, joilla voit antaa heille pääsyn sisältöön:

• antamalla heille pääsyn esimerkiksi Sketchin, Figman tai Zeplinin suunnittelutyön lähdetiedostoihin.
• kopioimalla / liittämällä sisältö suoraan spec: hen (se voi tehdä siitä hieman sotkuisen).

Jos tuotteesi on olemassa useilla kielillä, anna myös pääsy jokaiseen käännökseen. Esimerkiksi, voit käyttää array näyttää käännös alkuperäisen sisällön kullakin kielellä. Seuraava taso käännös hallinta on käyttää lokalisointi työkalu (kuten lause) ja vain lisätä ”käännös avaimet” oman tuotteen spec. Mutta jälleen, tämä merkitsee yksi edestakaisin välillä tuotteen tiedot ja toinen työkalu.