managerul de produs este adesea descris ca „puntea dintre afaceri, design și tehnologie”. Puntea „între design și tehnologie” este deosebit de critică atunci când vine vorba de expedierea unui produs de calitate: fără bug-uri, pixel-perfect și care ia în considerare toate scenariile posibile și cazurile de margine. Pentru a vă asigura că bridge funcționează bine, iată câteva moduri în care este gestionat de echipa de proiectare:

• proiectantul livrează un prototip cuprinzător, care arată toate fluxurile produsului. Din păcate, acest lucru va dura adesea mult timp și va lipsi în continuare câteva cazuri de margine.
• proiectantul va livra doar un prototip care arată fluxurile principale ale caracteristicii și rămâne disponibil pentru întrebări din partea echipei de dezvoltare. Din păcate, acestea înainte și înapoi sunt extrem de ineficiente (mai ales într-o configurație de la distanță) și pierd mult timp atât din partea echipei de proiectare, cât și din cea de dezvoltare.
• proiectantul, pe lângă prototipul cuprinzător, scrie un document de specificații adecvat care enumeră toate scenariile posibile și cazurile de margine. Problema este că este adesea o pierdere de timp, deoarece (1) timpul prețios al designerilor va fi mai bine petrecut prin proiectarea de fapt a altor caracteristici, nu prin scrierea unui document specific și (2) nu au întotdeauna aceeași vedere de 360 de centimi a produsului ca și managerii de produs, ceea ce îi va determina să treacă cu vederea unele scenarii și cazuri de margine.

de aceea, echipele mature de produse încredințează de obicei scrierea specificațiilor lor de produse managerilor de produse.

dar cum ar trebui să scrieți specificațiile produsului? Am scris specificațiile produsului în ultimii 5 ani și am găsit un format care este bine apreciat de echipele de software cu care lucrez. În această postare, împărtășesc mai multe despre metodologia mea și instrumentele pe care le folosesc pentru a scrie specificațiile produsului. De asemenea, descriu câteva limitări cu care mă confrunt cu instrumentele pe care le folosesc și câteva idei de îmbunătățire pe care le am în minte.

Iată cele 5 subiecte principale pe care le abordez într-un spec produs:

1. Context și obiective
2. harta arhitecturii
3. epopee și povești de utilizator
4. criterii de acceptare
5. Design, conținut și traduceri

Context și obiective

chiar dacă specificațiile produsului sunt destinate în principal echipelor de software, le place totuși să știe de ce lucrează la ceea ce lucrează. Am ajuns să înțeleg că unul dintre principalii factori de motivație pentru inginerii software este impactul. Cei mai mulți dintre ei visează să lucreze la funcții utilizate de milioane de utilizatori. Sunt încântați când aud că noul UX pe care l-au implementat a crescut retenția cu 15%, de exemplu. Deci, este important să oferiți context despre caracteristica pe care o vor implementa:

• despre ce vorbim? Care parte a produsului? Simțiți-vă liber să adăugați orice istoric al funcției care este util pentru a înțelege situația actuală.
• care este problema actuală? Notă: pot exista mai multe probleme de rezolvat.
• există vreun feedback calitativ / verbatims de la utilizatori pentru a fi citat?
• există date (de exemplu, grafice) care trebuie afișate? În această secțiune, nu ezitați să includeți orice diagrame sau grafice care vor face datele mai ușor de înțeles.
• care este soluția aleasă? (descrie-l pur și simplu, în câteva propoziții)
• a fost luată în considerare vreo altă soluție? Dacă da, de ce a fost pus deoparte?
• a fost deja implementată vreo altă soluție? Cum a fost performante?
• care sunt obiectivele ? Există vreun KPI pe care încercăm să-l influențăm? Acest lucru va ajuta în special echipa software să înțeleagă dacă trebuie să implementeze noi Trackere / etichete / evenimente pentru a colecta corect datele. Am văzut Echipe care se simțeau atât de conduse de proiect încât au luat inițiativa de a configura tablouri de bord pentru a urmări valorile în timp real, fără ca eu sau altcineva să le ceară.

harta arhitecturii

înainte de a intra prea mult în detaliile caracteristicii, este important să oferiți o imagine de ansamblu la nivel înalt a modificărilor și a ceea ce rămâne același în produsul dvs. Și chiar dacă lucrați la un produs complet nou, o hartă de arhitectură va fi în continuare extrem de relevantă pentru a înțelege modul în care este structurat produsul.

„harta arhitecturii” este modul în care numesc o reprezentare diagramă la nivel înalt a caracteristicilor produsului (fluxuri, ecrane și conținut) și modul în care acestea sunt legate între ele. Unii oameni o numesc „arhitectura informației”, „harta fluxului”, „cartografierea UX” etc.

exemplu de o hartă de arhitectură (construită pentru unul dintre clienții mei), cu un cod de culoare „înainte / după”

nu există o metodologie oficială a modului de a desena o hartă de arhitectură. Pe o aplicație mobilă, încerc de obicei să diferențiez fluxurile, ecranele și „părțile unui ecran” (sau „conținutul în pagină”), folosind o formă diferită pentru fiecare dintre acestea, așa cum este detaliat în legenda de mai sus.

De asemenea, poate fi util să jucați pe codul de culoare. În exemplul de mai sus, am folosit 3 culori și, de asemenea, solid vs.linie punctată pentru a explica modul în care arhitectura actuală a informațiilor va fi actualizată cu reînnoirea UX a aplicației la care lucram. (verde: va rămâne așa cum este, portocaliu: va fi actualizat, roșu: va fi șters; solid: va rămâne în același loc, punctat: va fi mutat în altă parte). În acest fel, inginerii au avut o vedere clară asupra părții aplicației care ar putea fi modificată.

un alt sfat pentru a construi o hartă de arhitectură ușor de înțeles este de a distinge în mod clar diferitele părți ale navigației, așa cum se face mai jos cu zone separate pentru fiecare dintre ele.

noua versiune a harta arhitectura construit pentru clientul meu

având o hartă arhitectură va fi extrem de util pentru spec produs; acesta vă va permite să evidențiați ce parte a produsului despre care vorbiți în fiecare dintre poveștile dvs. de utilizator.

ce instrument ar trebui să utilizați pentru a desena o hartă de arhitectură? Există tone de ele disponibile acolo, preferatul meu este capricios (pentru că este vizual plăcut și foarte simplu, nu aglomerat cu atât de multe caracteristici), dar am folosit și Draw.io în trecut — ceea ce este interesant, deoarece este integrat cu Google Drive, deci dacă lucrați cu Google Slides și Google Docs, este plăcut să îl utilizați. Este, de asemenea, integrat cu Jira și Confluence.

dacă doriți să aflați mai multe despre hărțile de arhitectură (do ‘s and don’ ts, ce instrumente să utilizați, câteva exemple etc.), Toptal a venit cu o citire excelentă: ghidul cuprinzător pentru arhitectura informațiilor.

epopeile și poveștile utilizatorilor

descompunerea și explicarea tuturor părților produsului dvs. pot deveni foarte repede destul de haotice. Scrierea specificațiilor produsului în ultimii 5 ani, cel mai bun mod pe care l-am găsit pentru a menține specificațiile organizate și ușor de înțeles este să le descompun în funcție de „poveștile utilizatorilor”.

Ce este o poveste de utilizator? Conform modelării Agile, o poveste de utilizator este ” o definiție la nivel foarte înalt a unei cerințe, care conține doar suficiente informații, astfel încât dezvoltatorii să poată produce o estimare rezonabilă a efortului de implementare a acesteia.”

ideea poveștilor utilizatorilor este de a pune utilizatorii pe primul loc și de a evita utilizarea exclusiv obscură& vocabular tehnic atunci când discutăm caracteristici. Atlassian: „după ce a citit o poveste de utilizator, echipa știe de ce construiesc ceea ce construiesc și ce valoare creează.”

acestea au ca scop construirea unui produs mai bun în cazul în care utilizatorul este în centrul dezbaterilor, contrar bun vechi de dezvoltare a produsului cascadă.

Iată cum ar trebui formulată o poveste de utilizator:

ca< tip de utilizator>, vreau<> astfel încât< un motiv>.

de exemplu, iată cum am putea formula povești de utilizator pentru următoarea subparte a hărții de arhitectură pe care am desenat-o pentru unul dintre clienții mei:

• user story #1: ca angajat în secțiunea profil, vreau să-mi editez profilul pentru a-mi putea actualiza fotografia, prenumele și prenumele.
• povestea utilizatorului # 2: Ca angajat în secțiunea Profil, vreau să accesez setările, astfel încât să îmi pot actualiza parola și să actualizez preferințele de notificare.
• User Story #3: ca angajat în secțiunea de profil, vreau să accesez chatul, astfel încât să pot oferi feedback dezvoltatorilor aplicației

depinde de managerul de produs să decidă ce nivel de detalii doresc să acopere în povestea utilizatorului. Dacă am vrea, am putea merge și cu un nivel mai adânc în povestea utilizatorului # 2, de exemplu:

• povestea utilizatorului #2.a: Ca angajat în Setări, vreau să accesez secțiunea” editați parola ” pentru a-mi putea actualiza parola
• User Story #2.b: ca angajat în Setări, vreau să accesez preferințele de notificări, astfel încât să pot actualiza la ce frecvență primesc fiecare tip de notificări

dar, după cum vedeți, acest lucru este oarecum evident și redundant. Eu personal am ales să acopăr aceste scenarii în” criteriile de acceptare ” (vezi secțiunea următoare) a poveștilor în cauză.

pentru a organiza poveștile utilizatorilor, folosim adesea „epopee”. În termeni agili,” epopeile ” sunt cantități mari de muncă care pot fi împărțite în povești mai mici ale utilizatorilor. Eu personal folosesc epopee pentru a grupa povești care fac parte din aceeași temă sau zonă din produs. De exemplu, am ales să grupez poveștile de mai sus ca parte a epopeii” profil”. Unii oameni aleg să formuleze epopee în același mod ca poveștile utilizatorilor, cu o structură mai simplă (de ex. „Ca utilizator, vreau să-mi accesez profilul”)

criterii de acceptare

pentru a ne asigura că se adaugă suficiente detalii la o poveste de utilizator, folosim” criterii de acceptare „(uneori numite și”condiții de satisfacție”).

conform LeadingAgile.com, „criterii de acceptare „sunt” condițiile pe care un produs software trebuie să le îndeplinească pentru a fi acceptat de un Utilizator, Client sau, în cazul funcționalității la nivel de sistem, Sistemul consumator.”

în criteriile de acceptare, ar trebui să enumerați toate specificitățile funcționale care nu sunt clar explicate de povestea utilizatorului. Exemplu:

User Story

ca angajat în secțiunea Profil, vreau să-mi editez profilul pentru a-mi putea actualiza fotografia, prenumele și prenumele.

criterii de acceptare

• având în vedere că sunt pe ecranul edit profile când fac clic pe pictograma edit first name, atunci ar trebui să treacă la modul edit, să se concentreze pe intrare și să deschidă tastatura (la fel pentru numele de familie)
• având în vedere că sunt pe ecranul edit profile când fac clic pe pictograma edit photo, atunci ar trebui să-mi ceară să aleg între cameră și bibliotecă
• având în vedere că îmi editez prenumele când fac clic pe „save”, atunci ar trebui să mă redirecționeze către modul de citire și apoi ar trebui să mă redirecționeze către modul de citire ar trebui să văd o notificare de succes

etc…

gândiți-vă la criteriile de acceptare ca la lista de verificare care va trebui completată pentru ca produsul să fie expediat. Formatul dat/când / atunci utilizat mai sus este o modalitate bună de a vă ajuta să formulați criteriile de acceptare, dar în unele cazuri poate fi dificil de utilizat.

Design, conținut și traduceri

având modele actualizate în specificațiile produsului

până în prezent, nu am menționat ce instrument folosesc pentru a scrie specificații. În trecut, am trecut între Google Docs, Google Slides și Notion. Mi-a plăcut foarte mult să folosesc Notion pentru toate integrările cool pe care le oferă (în special cele cu InVision și Figma). Dar acum am trecut complet la Google Docs: prefer să am mai multă libertate în modul în care îmi formatez specificațiile produsului. De asemenea, este mai convenabil să utilizați produsele Google atunci când lucrați cu parteneri sau clienți externi.

pentru a vă asigura că identitatea vizuală a produsului dvs. este adusă la viață cu exactitate de echipa de dezvoltare, este important să le oferiți acces la cele mai actualizate ecrane livrate de proiectantul(proiectanții) dvs. Dar, deoarece nu există o integrare reală între Google Docs și instrumente de proiectare precum Figma, InVision sau Zeplin, obișnuiam să export ecrane și să le copiez/lipesc în specificațiile produsului meu.

Acest lucru ar deveni foarte repede o problemă: designerii iterează zilnic pe ecranele lor și chiar și atunci când totul a fost convenit pe un ecran, acesta se poate schimba câteva săptămâni mai târziu din cauza unei componente specifice actualizate în biblioteca de design. Acest lucru ar face ca specificațiile mele să fie depășite de cele mai multe ori.

De aceea astăzi folosesc doar numele ecranelor. De exemplu, în cazul în care o poveste de utilizator despre profil edition este de aproximativ 2 ecrane care au fost proiectate pe Figma, voi scrie doar „Figma nume de ecran: edit-profile-1 și edit-profile-2”.

desigur, acest lucru nu este ideal și constrânge dezvoltatorii sau oricine altcineva citind specificațiile mele pentru a comuta între mai multe instrumente.

dar acest lucru arată că există astăzi ceva ineficient în modul în care scriem specificațiile produsului. Utilizarea mai multor produse ridică întrebări de integrare și sincronizare. Cum să vă asigurați că toate informațiile necesare pentru a construi un produs sunt vizibile într-un singur loc, fără a fi depășite? (De fapt, acest lucru nu se aplică numai desenelor, ci și hărților și conținutului arhitecturii).

dacă vă confruntați și cu această problemă și ați găsit o soluție, aș fi interesat să primesc feedback-ul dvs.!

oferind acces ușor la conținut și traduceri pentru a evita greșelile de tipar

când proiectați ecrane cu o cantitate mare de conținut, este plăcut să oferiți dezvoltatorilor posibilitatea de a-l copia / lipi cu ușurință în loc să trebuiască să-l re-tastați singuri. În caz contrar, s-ar putea termina cu (1) multe greșeli de tipar și (2) dezvoltatorii supărat. Există mai multe modalități prin care le puteți oferi acces la conținut:

• oferindu-le acces la fișierele sursă ale lucrărilor de proiectare pe Sketch, Figma sau Zeplin, de exemplu.
• prin copierea / lipirea conținutului direct în spec (se poate face un pic murdar).

dacă produsul dvs. există în mai multe limbi, acordați și acces la fiecare traducere. De exemplu, puteți utiliza o matrice pentru a afișa traducerea conținutului original în fiecare limbă. Următorul nivel de gestionare a traducerii este să utilizați un instrument de localizare (cum ar fi fraza) și să adăugați doar „cheile de traducere” în specificațiile produsului. Dar, din nou, acest lucru implică un alt înainte și înapoi între specificațiile produsului și un alt instrument.