O mai bună documentare și comunicare în echipă cu documentele de design de produs

Procesul tipic de lucru ca designer de produs într-o companie sau startup vă poate fi familiar: se dezvoltă un nou produs pentru care să ofere o soluție de proiectare. Apoi lucrezi la unele propuneri de design și le prezinți în fața a 1-3 persoane pentru a aduna feedback.

Uneori, acest proces funcționează bine, dar alteori nu. De exemplu, unii oameni sunt ocupați să acorde atenție să-și termine propriile sarcini și nu petrec suficient timp pentru a oferi feedback clar și concis pentru propunerea dvs. de proiectare.

De asemenea, se poate întâmpla ca, deși procesul dvs. este bun, să doriți totuși să formalizați procesul notând deciziile, ținând evidența iterațiilor și a procesului de proiectare în general, mai ales în vremurile actuale în care ne aflăm lucrând de la distanță din cauza COVID19.

Documentarea procesului are multe beneficii. De exemplu, vă face munca mai vizibilă, creează oportunități de a obține feedback de la mai mulți oameni, îmbunătățește comunicarea generală și oferă o imagine clară a modului în care a fost proiectată o funcție, cu tot contextul și considerațiile din jur.

Căderea Designerului Erou

În jurul anului 2018, lucram ca designer de produs la distanță din Madrid într-o companie care operează în America Latină, implicând în acest proces și alte echipe din Mexic și Sao Paulo, Brazilia.

Înainte de a începe să lucrez la această companie, am avut o mulțime de experiențe diferite în cariera mea, lucrând în medii mici și mari din multe sectoare diferite, cum ar fi mass-media de știri, studiouri de design, o rețea socială, un sistem de operare mobil, am fondat un startup de e-grocery. , și chiar a făcut niște concerte freelance cu alte startup-uri mici.

În acei ani în care am urmat aceeași abordare, ai niște oameni care stau în aceeași cameră, îți prezinți soluția, oferi niște ecrane, fluxuri, primești feedback și o prezinți din nou. După câteva iterații, munca ta va fi gata să ajungă în faza de dezvoltare.

Cu toate acestea, aceeași abordare a încetat să funcționeze. La scurt timp după ce m-am alăturat echipei, mi-am dat seama că doar să-mi prezint design-urile la un apel video nu era suficient. Cream o mulțime de propuneri, dar nu am putut ajunge la aprobarea finală din partea părților interesate și a colegilor mei. Eram confuz și mă tot întrebam: Ce se întâmplă? Nu proiectam eu cea mai bună soluție posibilă? Nu făceam o muncă de bună calitate? Fiecare dintre acele întrebări mă făcea să-mi pierd încrederea în mine. Problema era că trebuia să îmi adaptez procesul la acest mediu.

De îndată ce mi-am dat seama că procesul meu nu funcționează, am început să citesc o mulțime de articole despre cum să lucrezi ca designer de la distanță, efectul de pescăruș (când cineva intră în munca ta, o critică aspru și apoi zboară), cum alte companii se apropiau de colaborarea de la distanță și modul în care și-au oficializat procesul notându-l. După ce am citit tot acest material, m-am întrebat cum se confruntă dezvoltatorii cu această problemă? Cum colaborează ei în medii îndepărtate într-o manieră aproape asincronă? Cum ajung ei la acorduri finale? Am descoperit că, de fapt, comunitatea de dezvoltatori are deja un proces care funcționează destul de bine pentru ei: se numește pull requests.

Solicitările de extragere vă permit să introduceți modificări într-o bază de cod mai mare, documentându-le și validând deciziile cu feedbackul altor persoane. În acest fel, modificările pe care le introduceți se amestecă perfect cu toate standardele și conexiunile pe care codul le are deja în vigoare. Este exact ceea ce trebuia să obțin, dar bineînțeles într-o abordare design-modă. Permiteți-mi să vă prezint documentul de design de produs.

The Product Design Doc

Un document de design de produs (PDD) este un document care convertește problemele pe care doriți să le rezolvați, contextul și soluția finală într-o abordare bazată pe iterații sau pe etape.

Aceasta înseamnă că vă puteți documenta întregul proces de proiectare într-un singur document care poate fi partajat cu oricine din compania dvs. și va trăi ca bază de cunoștințe pentru deciziile pe care le luați despre produse. Sună cool, nu? Să pătrundem în detalii.

Concepte generale

Un PDD poate fi descris în 4 concepte majore: Metadate, Context, Etape și Feedback .

• Metadatele sunt doar informații utile despre document, cum ar fi titlul, data, starea și așa mai departe.

  

• Contextul este ceea ce alți oameni trebuie să citească, pentru a înțelege propunerile de design pe care le faci, gândește-te la el ca descrierea, problema, abstractul sau obiectivele a ceea ce trebuie să realizezi.

• Etapele sunt diferitele iterații ale designului dvs., de obicei, începând cu concentrarea pe soluția mai largă și în fiecare etapă concentrându-se pe detalii mai specifice. Fiecare etapă se bazează pe cea anterioară și se adresează feedback-ului primit. Aceasta este o modalitate structurată de a ajunge la un punct final în care problemele rezolvate nu pot apărea din nou.

• Feedback -ul se referă la toate opiniile, comentariile, solicitările și recomandările pe care le adunați de la alte persoane. Puteți aduna feedback de la părțile interesate sau de la membrii echipei.

Cu aceste patru concepte, puteți crea diferite variante de PDD pentru a se potrivi nevoilor dvs., fiecare companie/proiect este diferită și ceea ce a funcționat pentru mine nu trebuie să funcționeze în același mod pentru dvs. Dar dacă acoperiți aceste 4 concepte principale în PDD, va funcționa probabil în aproape orice situație.

Exemplu de structură

După ce am înțeles conceptele principale, vă voi împărtăși structura pe care am folosit-o în timpul petrecut în acea companie. Are următoarele secțiuni:

• Titlul ar trebui să fie concis, clar și ușor de distins de alte titluri PDD pe care le aveți deja.
• Starea indică în ce etapă se află documentul dvs. chiar acum:
• Proiect
  Încă lucrăm la definirea Contextului. Nu este pregătit pentru feedback.
• S30, S60, S90
  Diferitele etape (30%, 60%, 90%) ale soluției dvs. (mai multe detalii despre etapele mai târziu).
• Complet
  Toate Feedback-urile au fost abordate și nu lipsesc puncte. PDD-ul este terminat.
• Rezumatul este descrierea problemei pentru care trebuie să proiectați, de obicei leagă la alte lecturi utile pe care le puteți avea.
• Obiectivele sunt punctele cheie asupra cărora trebuie să se concentreze soluția dvs., aceasta este o listă de verificare pe care o veți revizui în mod constant pentru a vă asigura că sunteți pe drumul cel bun.
• S30 (sau Stage 30% ) este prima propunere pe care o faci pe baza abstractului și a obiectivelor, concentrându-se pe soluția mai largă în loc de detalii, poate prin furnizarea unui cadru de fidelitate scăzut sau a unei tehnici similare. Aceasta este etapa în care soluția propusă ar putea adopta o abordare total diferită și este de așteptat să aibă loc un feedback major.
• S60 (sau Etapa 60% ) este soluția dvs. la 60% de completitudine și aplică feedback-ul de la S30. Are mai puține detalii decât S90, dar indică clar intenția soluției tale. Oferiți un cadru fir de înaltă fidelitate cu mai multe cazuri implicate și câteva definiții de flux. Este posibil să primiți un fel de feedback care se concentrează în principal pe cazuri ratate și mici scenarii neașteptate.
• S90 (sau Etapa 90% ) este etapa care are soluția la 90% de completitudine și aplică feedback-ul de la S60. Această etapă se concentrează pe cele mai fine detalii ale designului dvs., inclusiv toate scenariile diferite, carcasele de colț, designul vizual și chiar prototipurile. Se așteaptă să aibă un fel de feedback minor.

S-ar putea să vă întrebați, trebuie să urmez aceeași ordine și convenție de denumire a etapelor? Ei bine, nu, nu. Puteți redenumi etapa din S30, S60 și S90 doar în: Explorare, Propunere, Soluție.

De asemenea, puteți modifica ordinea, astfel încât lucrarea cea mai rafinată (S90, Soluție) să ajungă în partea de sus a documentului și fluxul de citire să treacă de la etapa finală la cea inițială (S30, Explorare).

Șabloane

Începeți rapid cu unul dintre șabloanele furnizate pentru cele mai comune platforme de scriere. Rețineți: convențiile de denumire ale secțiunilor sunt complet personalizabile. Dacă nu vă place Rezumatul , utilizați doar Brief , About sau orice altceva care se potrivește nevoilor dvs. Conceptul principal pe care va trebui să-l păstrați este despre crearea diferitelor iterații pentru a vă concentra pe fiecare etapă, puteți doar să redenumiți S30 prin Explorare, S60 prin Propunere și S90 prin Soluție.

• Hârtie
• Noţiune
• documente Google
• Exemplu din viața reală

Beneficiile cheie ale utilizării PDD

1. Fiecare decizie este documentată.
   Înseamnă că, chiar și atunci când părăsești compania/proiectul (și asta se va întâmpla mai devreme sau mai târziu), toate cunoștințele generate în jur vor rămâne în companie pentru totdeauna, astfel încât alți oameni să se poată uita la el și să repete de unde ai plecat.

2. Îmbunătățește comunicarea.
   Aducerea diferiților oameni din echipa ta pe PDD pentru a oferi feedback îi ajută pe toți să rămână pe aceeași pagină și să fie conștienți de deciziile luate.

3. Limitează schimbările nesfârșite din partea părților interesate.
   Fiecare etapă se concentrează pe un unghi diferit al problemei, mergând de la soluții mai largi la cele înguste. Acest lucru permite oamenilor să se concentreze pe o singură problemă la un moment dat, ajutându-i în etapele finale.

4. Produsul este construit în colaborare.
   În loc ca părțile interesate să definească soluții specifice, lăsăm echipele de inginerie, proiectare și alte echipe să se implice cu soluția, făcându-le parte din aceasta.

Note finale

Încheind povestea despre această companie la distanță, am ajuns să lucrez acolo încă câteva luni și am putut implementa Product Design Docs cel puțin pe 5 proiecte diferite. Frustrarea mea s-a redus foarte mult și am reușit să ajung la un consens asupra propunerilor mele de design, astfel încât produsul a continuat să evolueze. De atunci, compania a crescut foarte mult și o parte din munca pe care am făcut-o în timpul meu este încă folosită.

PS: Am început să scriu acest articol în 2019, apoi în 2021 am văzut că Abstract creează un produs pentru documentarea procesului de proiectare, așa că am decis să revin pe drumul cel bun și să-l termin. Se pare că este încă un subiect destul de relevant.

Bibliografie

• Cum să rulezi exerciții de design într-o echipă de la distanță de Hannah Hearth
• Evitați efectul pescăruş: cadrul 30/60/90 pentru feedback de Lauren Moon
• Cum proiectați un document de design? de John Saito
• Puterea documentului de design de Brendan Fagan
• Vă prezentăm caietele de Matt Colyer