Construiește o echipă de proiectare a produsului, construiește un produs pe care îl iubesc utilizatorii

În iulie 2016, am fost invitat la bordul celui mai ambițios proiect din OutSystems Engineering: să mă alătur unui grup de pasionați de UX și să formez ceea ce este cunoscut astăzi drept echipa de design de produse. Această echipă a influențat modul în care ingineria construiește produsul, până în momentul în care experiența utilizatorului devine înrădăcinată în cultura noastră. Permiteți-mi să vă povestesc cum am ajuns aici.

Povestea mea

Sunt un inginer software care s-a alăturat OutSystems Engineering încă din 2007. De atunci fac și învăț o mulțime de lucruri tehnice. Am devenit șef de echipă și, pe parcurs, am descoperit practicile de utilizare și design. Am fost întotdeauna unul dintre acei oameni cărora le pasă cu adevărat de utilizatorii noștri, tipul care a experimentat lucrul cu machetele și prototipurile și care a făcut teste de utilizare înainte de expedierea produsului.

Ianuarie 2015: Un client a fost atât de mulțumit de munca echipei mele,
că ne-au trimis o scrisoare de Anul Nou fericit.

Cu toate acestea, dacă doriți să construiți un produs excelent, nu este suficient să aveți câteva persoane care le pasă de experiența utilizatorului. Compania și-a dat seama de asta și a încercat (și nu a reușit) să creeze și să mențină un UX sau o echipă de proiectare centralizată. Deci, de ce am fost invitat să construiesc această echipă ?? Ei bine, după cum veți vedea, motivul a fost că, de data aceasta, urma să facem lucrurile altfel. După o probă de succes desfășurată într-o echipă existentă, conducerea a acceptat propunerea noastră de a construi o echipă de design nou.

O regulă de bază pentru această echipă a fost aceea că aceasta trebuia să fie multidisciplinară: contrar iterațiilor anterioare, ea trebuia să fie compusă atât de designeri UI / UX, cât și de ingineri cu un puternic fond de dezvoltare de software. De ce a fost important acest lucru?

OutSystems oferă o platformă cu cod scăzut pentru construirea de aplicații mobile și web. Scopul nostru final este de a îmbunătăți viața dezvoltatorilor, făcând dezvoltarea mai rapidă și mai ușoară. Pentru a înțelege acești dezvoltatori, a le descoperi nevoile și a proiecta și a valida cele mai bune soluții, avem nevoie atât de ingineri cât și de designeri UI / UX. Aș fi inginer și, de asemenea, șeful echipei pentru această echipă nouă, iar asta a fost o provocare majoră!

Noiembrie 2016 - Echipa de proiectare a produselor.

Etapele timpurii: definirea scopului și viziunii noastre

Prima decizie importantă pe care am luat-o a fost să denumim echipa „Design de produs”. Am vrut să ne despărțim de echipele anterioare doar pentru design. Din păcate, acestea au fost limitate la etapele ulterioare ale proiectelor, lucrând doar la designul vizual (imagini și icoane) și la alte chestii de design pe care inginerii nu le pot face, cum ar fi tricourile și cănile și alte mute uimitoare.

Am vrut să modelăm viitorul produsului nostru și să nu fim o idee ulterioară am fi implicați de la sol.

Echipa de proiectare a produsului ar influența modul în care Ingineria proiectează produsul sub diferite aspecte. Am influența funcționalitatea, capacitatea de utilizare și utilitatea produsului și, da, și aspectele vizuale ale produsului.

Cu aceasta am determinat viziunea noastră inspirată:

Viziunea echipei de proiectare a produsului.

În continuare, am definit un set de obiective pe care le aplicăm fiecărui proiect la care lucrăm. Aceste obiective ne îndrumă spre viziunea noastră: oferim unui produs utilizatorii se vor îndrăgosti la prima vedere și vor continua să iubească pentru totdeauna:

  1. Faceți produsul ușor de utilizat.
  2. Faceți produsul frumos și de dorit.
  3. Ajută-i utilizatorii să înțeleagă valoarea produsului.

În retrospectivă, obiectivele noastre nu sunt atât de diferite de cele ale echipelor de proiectare anterioare și eram conștienți că există întotdeauna riscul de a eșua așa cum au făcut echipele respective.

Rulează un Premortem

În trecut, am aplicat cu succes o tehnică utilă, numită premortem (mai multe aici), care ne ajută să prognozăm riscul în proiectele noastre. Într-o premortem, ne imaginăm un eșec viitor ipotetic al proiectului. Rugăm fiecare persoană implicată în proiect să sublinieze ce riscuri ar fi putut contribui la acest eșec. Apoi, ne adaptăm planurile, pentru a evita aceste riscuri ipotetice și evităm eșecul. Atât de simplu și puternic, nu? Este; crede-mă!

Proiectul Premortem

Deci, am decis să organizăm un premortem pentru echipă. Cadrul ipotetic a fost acela că, după un an, echipa a eșuat spectaculos. Am solicitat tuturor celor din echipă să identifice posibilele motive ale eșecului. Din aceste ipoteze, am identificat preocupări comune și am definit elemente de acțiune pentru a le evita. Unele dintre aceste elemente de acțiune au fost executate în timpul bootstrapping-ului echipei, iar altele sunt încă executate până în zilele noastre, doar pentru a ne asigura că nu cădem de pe stâncă. :)

Evaluarea abilităților noastre

Unul dintre riscurile pe care le-am identificat a fost natura multidisciplinară a echipei noastre. Complementarea diverselor noastre abilități ar putea fi dificilă și, în acel moment, s-ar putea să nu avem abilitățile necesare pentru a face munca noastră. Am acceptat provocările ca o mare oportunitate pentru a crește! Și toți am ajuns atât de departe.

Am analizat definiția produsului. Am găsit acest lucru:

Proiectarea produsului identifică, investighează și validează problema și, în final, meșteșugurile, proiectările, testele și livrează soluția.

Am adaptat această definiție la nevoile noastre specifice și am început să modelăm ce înseamnă să fii proiectant de produse în OutSystems Engineering. De asemenea, am creat o diagramă a principalelor abilități de care am avea nevoie în calitate de proiectanți de produse.

Diagrama care demonstrează abilitățile echipei de proiectare a produsului pentru 2016.

În continuare, fiecare dintre noi a făcut o autoevaluare a abilităților, am discutat și despre abilitățile pe care am dori să le dezvoltăm sau unde le-am putea antrena pe altele. Acest lucru ne-a oferit idei utile despre locul în care echipa a avut nevoie de pregătire sau mai mulți membri ai echipei.

De asemenea, ne-a ajutat să definim o altă regulă de bază pentru echipă: ar trebui să lucrăm întotdeauna în perechi, unind abilitățile noastre de inginerie și proiectare pentru a completa munca excelentă a altora și a învăța unul de la celălalt.

Încă mai facem acest exercițiu din când în când și de la prima iterație, am continuat să ne evaluăm abilitățile. Drept urmare, am adaptat diagrama pentru a cuprinde modificările noastre. Iată diagrama noastră din 2018:

Diagrama care demonstrează abilitatea echipei de proiectare a produselor setată pentru 2018.

Lucrul cu echipele de produse

Cu echipa în loc, viziunea și obiectivele stabilite și abilitățile noastre determinate și clare, cum putem influența de fapt viitorul produsului? Ingineria OutSystems are mai multe echipe de produse, una pentru fiecare zonă a produsului: front-end, back-end, ciclul de viață al aplicației și așa mai departe.

Un alt risc pe care l-am identificat a fost acela că echipele de produse ar putea decide să nu mai funcționeze cu noi dacă procesele noastre interferează cu agilitatea lor. Deci, stabilim câteva reguli de bază pentru echipa noastră:

  1. Lucrăm cu echipele, nu pentru echipe
  2. Ne propunem întotdeauna să adăugăm la maxim echipele valoarea maximă și cea mai mică.

Aveam nevoie de un proces bine definit, pentru ca echipele să știe când pot conta pe noi. Am cercetat mai multe sisteme de proiectare, am citit cărți și articole și am adunat inspirație de la alte companii. Există o mulțime de procese de proiectare acolo, dar a trebuit să adaptăm un proces la nevoile noastre specifice.

Am definit un proces cu patru etape: descoperire, prototip, livrare și modificare.

Cele patru etape ale proiectării produsului

Etapa Descoperă

În această etapă, scopul este de a înțelege totul despre problemă. Intervievăm, adunăm feedback din mai multe surse, facem teste de utilizare cu soluția actuală, analizăm concurența și executăm un proces de idei pentru a veni cu cât mai multe soluții. Am efectuat câteva experimente cu adevărat interesante pe parcursul procesului de idei, iar astăzi rulăm o variantă a proiectării Google Sprint pe care o numim „Sesiune de proiectare”. Aceasta este una dintre cele mai importante etape ale procesului, în principal pentru că aliniază toată lumea cu problema. încercăm să rezolvăm.

Noiembrie 2016: Încercarea sprint-ului Google Design.Decembrie 2016 - Produsul primei noastre sesiuni de design, pentru Debuggerul vizual Full-Stack.

Etapa prototipului

În această etapă, prototipăm soluții pentru problemă, le testăm cu utilizatori țintă și apoi le iterăm. Prototipurile pot cuprinde mai multe niveluri de fidelitate, de la hârtie la software. La sfârșitul acestei etape, vom fi testate mai multe prototipuri, astfel încât știm ce funcționează și ce nu funcționează. Lucrăm îndeaproape cu echipele de produse care vor implementa soluția, iar la final, ei decid ce soluții să implementeze.

Ianuarie 2017: prototipuri Full-Stack Visual Debugger.Martie 2017: Un prototip de hârtie Styles Editor.

Etapa de livrare

În această etapă, echipele de produse construiesc software-ul și designul produsului furnizează resurse vizuale, examinează software-ul implementat de la capăt la sfârșit și execută teste de utilizare. Testarea cu software-ul de lucru ne oferă o perspectivă suplimentară asupra problemelor de utilizare și suntem deschiși să adaptăm soluții în acest stadiu și, dacă este necesar, putem proteja alternative. La sfârșitul etapei de livrare, produsul este livrat și sărbătorim acest lucru împreună cu echipa!

Martie 2017: Unul dintre membrii echipei a livrat un copil, uau!Septembrie 2017 - Interfața de utilizare finală a dialogului de instalare a dispozitivelor mobile a Debuggerului Visual Stack Full

Etapa Tweak

Această etapă începe odată ce feedback-ul utilizatorilor noștri se lansează. În această etapă, analizăm parametrii pentru a regla soluția livrată. Scopul este de a identifica ceea ce funcționează și ce nu, de a efectua remedieri rapide sau de a planifica îmbunătățiri viitoare. În imaginea următoare, puteți vedea analiza noastră a valorilor editorilor de stiluri. În urma analizei, am identificat câte moduri diferite au accesat utilizatorii de funcționalități și care a fost cel mai popular.

Aceste informații ne ajută să simplificăm designul.

Decembrie 2017: - Analiza valorilor de utilizare pentru Styles Editor.

Se rumeneste, se clateste, se repeta

Trecem prin toate aceste etape cu echipele noastre de produse, astfel încât toată lumea este implicată în procesul de proiectare, din prima zi până când clienții folosesc cu fericire ceea ce am construit împreună. Procesul este adaptabil și iterativ; îl putem rula de mai multe ori în timpul unui proiect. Suntem mereu deschiși să adaptăm procesul la noile tehnici, cerințele noi și l-am modificat în timpul experimentelor noastre.

Unde suntem azi; Unde ne îndreptăm?

Astăzi avem o echipă constantă, puternică și performantă de proiectare a produselor și ne-am dovedit valoarea în mai multe proiecte, unele deja livrate. Am lucrat cu majoritatea echipelor de produse, iar astăzi toată tehnica OutSystems înțelege valoarea practicii noastre. Experiența utilizatorului devine o parte a culturii noastre.

Avem încă multe provocări înainte: trebuie să facem o scară a echipei pentru a influența mai multe proiecte, trebuie să continuăm să lucrăm la viziunea noastră pentru viitor, trebuie să ne îmbunătățim sincronizarea cu managerii de produse și proprietarii de produse, etc. Sunt multe de făcut, așa că haideți să ne înălțăm mânecile și să ne ocupăm!

Înapoi la povestea mea

Acesta este de departe cel mai provocator și plin de satisfacție proiect în care am fost implicat în timpul meu la OutSystems. Provocările sunt constante; echipa este uimitoare! Vă mulțumim, OutSystems, pentru o astfel de oportunitate extraordinară.

Echipa de proiectare a produselor în 2018