Hacks pentru designul produsului: o colecție de sfaturi și trucuri pe care le-am învățat de la echipa de design de la Nubank.

Am fost dezorganizat – o mizerie, de fapt – înainte de a descoperi puterea câtorva trucuri simple de proiectare. Sper că scriu acest articol este că aceste hack-uri de design de produs, pe care le-am învățat de la ceilalți designeri uimitori de la Nubank, vă vor ajuta la fel de mult cum m-au ajutat.

Oricum, fără alte îndemnuri, să intrăm.

<

1. Cum să începeți cercetarea de birou (un șablon!)

De ce l-ați folosi: Aveți informații provenind de pretutindeni și nu știți cum să organizați gândurile și opiniile tuturor.

Cine m-a ajutat în acest sens: João Rios și Leticia Ratkiewicz

De ce veți avea nevoie: o pagină kanban (eu folosesc Notion).

V-ați găsit vreodată într-o situație în care erau multe informații provenind din multe locuri diferite? Managerul dvs. de produs are un anumit context, managerul dvs. are un alt context, iar echipa de cercetare a făcut deja cercetări despre asta acum 5 ani …

Ei bine, acest șablon Desk Research este pentru dvs. Este doar un mod simplu de a organiza gândurile și opiniile tuturor, criteriile de referință, datele utile, faptele întâmplătoare … și orice altceva credeți că este necesar. Iată cum o fac:

Coloanele sunt: ​​

Și puteți adăuga câte coloane doriți, cum ar fi „ipoteze”, „rezultate” sau „idei aleatorii”. Asigurați-vă că nu durează prea mult!

2. Cum se scrie ipoteze (un cadru simplu!)

De ce l-ați folosi: Echipa dvs. dorește să testeze totul „doar pentru a-l testa”, dar puteți utiliza acest cadru pentru a-i ajuta să testeze lucrurile corecte.

Cine m-a ajutat în acest sens: João Rios (tipul ăsta mă ajută cu toate).

De ce veți avea nevoie: O pagină goală (serios).

Un manager de produs care îmi place foarte mult, Teresa Torres, a spus odată că Testarea totul nu funcționează.

În cuvintele ei: „Nu spun că nu experimentați. Spun că nu mai experimentați la întâmplare. ” Și pentru a vă ajuta pe dvs. și echipa dvs., există un cadru care se concentrează pe scrierea ipotezelor pe care le puteți construi pe cont propriu.

Ipoteza problemei

Credem că … {aici scrieți problema}

pentru … {cine se confruntă cu acea problemă}

va atinge … {rezultatul dorit}

pentru că … {justificare și dovezi}

<

Vom face … {ușor / rapid / mare încredere / soluție}

pentru … {parametrii țintă pentru experiment}

și vom ști că ipoteza este valabilă atunci când / dacă … {valoare care va dovedi rezultatul dorit atins}

Aflați & amp; Construi

Dacă ipoteza este adevărată, vom … {Ar trebui să fie clar cum arată succesul}

Dacă nu, vom … {scrierea acestui lucru vă va ajuta să vă definiți următorii pași}

Știu că sună mult la scriere la început, dar credeți-mă, merită efortul. Și dacă aveți atâtea idei de testat că scrierea acestui lucru este copleșitoare, atunci știți că încercați să testați prea mult.

„Cantitatea corectă” de ipoteze pe care ar trebui să le scrieți depinde de atât de multe aspecte ale produsului, dar acest articol din copacul de oportunități (de asemenea, de la Teresa Torres) vă poate ajuta să găsiți răspunsul.

3. Cum să începeți prototipul (desenați interacțiunile înainte de a le prototipa pe computer)

De ce l-ați folosi: sunteți nou în lumea prototipurilor.

Cine m-a ajutat în acest sens: Pedro Murad (un geniu Framer).

De ce veți avea nevoie: un pix și o hârtie (sau un iPad).

Acesta este mai degrabă un sfat decât un „truc” sau un cadru, dar vă va ajuta dacă învățați cum să faceți prototip – sau dacă nu știți nici măcar de unde să începeți cu o interacțiune. Iar cea mai bună parte este că este atât de ușor de făcut și te obligă să gândești ca un dezvoltator / inginer.

4. Cum să vă organizați paginile pe Figma.

De ce l-ați folosi: titlul vorbește de la sine. Dar, într-adevăr … fișierul dvs. Figma nu trebuie să fie extrem de perfect, dar un pic de organizare merge mult.

Cine m-a ajutat în acest sens: Camila Son – cea mai tânără și talentată designeră pe care o cunosc.

De ce veți avea nevoie: un fișier Figma / Sketch.

La fel ca sfatul numărul 3, acesta nu este un cadru, ci mai degrabă o mentalitate. A avea pagini numite „Final” sau „Aproape terminat” este echivalentul a avea documente .psd cu numele „final” -v2 ”. Așa cum am spus la început, nu trebuie să fiți extrem de organizat și nu spun că ar trebui să numiți fiecare strat (pentru că este aproape imposibil pentru un designer, dar sunt mândru de aceștia cine o poate face). Tot ceea ce spun este: încercați să vă denumiți paginile așa cum ar face un dezvoltator: versiunea + ceea ce creați.

Camila Son, designerul care a venit cu această metodă de denumire a paginilor, mi-a spus odată: „Mereu cred că trebuie să predăm fluxurile mele finale inginerilor, așa că încerc să spun o poveste foarte liniară și completă despre cum se potrivește acel flux / ecran în acel moment. De asemenea, știind că oamenii din alte echipe vor ajunge probabil să întrebe despre proiect la un moment dat, încerc să scriu un pic de context despre fiecare iterație diferită & quot ;.

Și atât. Deocamdată.

Dacă aveți un alt truc pe care ar trebui să-l adaug la această listă, vă rugăm să comentați mai jos și poate următorul meu articol va fi „O colecție de sfaturi și trucuri pe care le-am învățat din comentariile medii din prima mea postare mediană”.