La bază, sunt specializat în publicitate, dar lucrez în Enterprise IT de peste 13 ani ca designer de produse digitale pentru multe firme de renume. Dacă în publicitate motto-ul este "Mișcă-te repede. Strică lucrurile." ("Move fast, Break things"), în Enterprise motto-ul ar trebui spus pe dos. Aceasta a fost prima mea lecție. Dacă dorești să schimbi ceva, în mod radical, va fi greu sau aproape imposibil, dar fezabil pe termen lung.
Când mă gândesc la un produs Enterprise, îmi imaginez ceva mare, ocupă spațiu și e greu precum un camion cu 18 roți. Aceste camioane fac curba încet, greu, dintr-un motiv bun. Dacă vrei să virezi la dreapta la 100 km/h, cel mai probabil vei ajunge într-un șanț. Lucrurile stau la fel și cu produsele Enterprise care se mișcă greoi din mai multe motive. Acestea sunt aplicații complexe aflate sub o structură de management dispusă pe mai multe nivele, și ele complexe.
Chiar și așa, în ciuda nivelelor și a complexității, există multe oportunități de a îmbunătăți lucrurile, ținând cont de faptul că nu putem repara chiar totul. Adevărul este că domeniile Enterprise sunt toate așa, iar a lucra pentru Enterprise înseamnă a-ți asuma că vei avea în față un maraton.
Câteva dintre întrebările esențiale vizând Enterprise pot fi:
Ce anume face ca UX Enterprise să fie un domeniu extraordinar?
De ce utilizatorii noștri nu pot gestiona schimbările bruște și ce putem face în această privință?
Anul trecut, 5.6 miliarde de oameni au intrat online, ceea ce înseamnă că au folosit software, că au folosit sau au dezvoltat produse.
Consumatorii au spațiul lor de manevră și de interacțiune. Avem multe lucruri grozave de la Airbnb la Instagram sau Grinder. Dacă sunteți norocoși, puteți lucra la ceva foarte special. Dar cât de mult poți îmbunătăți modul în care te prezinți sau în care postezi online?
Dacă ne uităm în curtea Enterprise, vom vedea că încă se folosesc versiuni vechi de Windows, de Outlook, pe care oamenii le folosesc fără probleme. Este vorba de oameni obișnuiți. Sunt rudele noastre, oameni pe care îi știm, dar care folosesc aplicații, software dezvoltat de noi 40 de ore pe săptămână, ceea ce este mult!
Imaginați-vă ce impact incredibil puteți avea în viețile lor dacă îmbunătățiți modul în care ei lucrează și interacționează cu alții și cu aplicațiile. Deținem multe responsabilități și multă putere. Trebuie să realizăm că în calitate de programatori, designeri, manageri de produs, putem schimba viețile oamenilor.
Mai întâi, să vedem de ce utilizatorii noștri nu pot gestiona schimbările bruște. Voi da un exemplu drag mie pe care mi-l amintesc din vremurile când lucram în publicitate, anume cazul Coca Cola.
Nu știu câți țineți minte perioada când Coca Cola nu o ducea grozav. Se descurcau, dar erau amenințați de Pepsi. Coca Cola a zis: "Bine, avem o bază stabilă, hai să ieșim puțin din zona de confort", apoi au continuat: "Hai să încercăm asta, New Coke!" Au făcut totul ca la carte, au efectuat aproximativ 200 000 de teste pe gustul băuturii și tuturor le-a plăcut noua rețetă!
Totuși, când produsul a ieșit pe piață, nimeni nu prea putea consuma o doză întreagă. Gustul era bun, dar nu puteau bea toată doza.
Așa stau lucrurile și cu utilizatorii noștri. Faptul că noi testăm ceva într-un mediu bine structurat și controlat nu înseamnă că soluția este scalabilă. Când schimbăm ceva la software, ar trebui să ne gândim la ce impact va avea acest lucru asupra utilizatorilor. Utilizatorii nu stau să se gândească la ceea ce vrem noi să schimbăm. Au propriile probleme, propriile vieți. Fiecare schimbare va avea un impact cert în interacțiunea lor zilnică. Doar pentru că ceva este bine testat nu înseamnă că este și ceva bun pentru utilizatori.
Acum ceva timp, lucram la un produs folosit de foarte multe firme mari, care urma să genereze rapoarte foarte tehnice pentru oameni foarte tehnici care trebuiau să le revizuiască. Trebuia să simplificăm procesul pentru cei care nu aveau cunoștințe tehnice, astfel încât să poată și ei genera astfel de rapoarte.
Hai s-o facem! Era vorba de o structură complexă pe care am transpus-o într-un wizard ce ghida totul pas cu pas. Ne-am asigurat că eliminăm jargonul tehnic, că totul merge natural, intuitiv. Când produsul a ajuns pe mâinile asistenților personali ai inginerului, aceștia nu știau cum să folosească programul. Ceea ce noi interpretaserăm ca fiind piedici în înțelegere și jargon nejustificat era exact ceea ce ei stăpâneau cel mai bine după mulți ani de experiență. Era plasa lor de siguranță, indiciile care făceau lucrurile bine.
Eliminând toate acele lucruri, am obținut un produs cu o curbă rapidă de învățare pentru utilizatorii noi, dar vechii utilizatori s-au simțit pierduți. Ne-am dat seama că, de fapt, nu am știut ce este mai bine pentru utilizatori. Aveam ipoteze de lucru, făcusem cercetare, iar cercetarea ne indica că totul ar fi trebuit să fie bine primit. Din păcate, nu a fost o garanție. Deoarece postul lor de muncă depinde de produsul software pe care îl folosesc, trebuie să tratăm oamenii cu empatie. Să ne gândim la memoria musculară! Cel mai greu lucru este să te dezveți.
Știind toate acestea despre utilizatorii noștri, ce putem face?
În primul rând, să luăm în calcul faptul că trebui să facem re-design. Astfel, este mai ușor pentru voi și echipă să vă gândiți la toate problemele, la tot ce puteți îmbunătăți și la tot ceea ce este posibil. După ce ați luat această decizie, identificați grupul țintă de utilizatori. Sunt utilizatori noi sau existenți?
Dacă este vorba de utilizatori noi, ați putea adăuga funcționalități noi. Dacă este vorba de utilizatori existenți, ați putea să rezolvați lucrurile care sunt dificile pentru ei în acest moment. Începeți cu cele mai mari probleme. Țineți cont că nu puteți repara totul, identificați problemele și faceți o listă de priorități. După ce știți la ce veți lucra, cu cine veți lucra și care sunt problemele de rezolvat, puteți pilota sistemul pe ceva specific.
Începeți cu un grup țintă mic, creați un MVP pentru problemele ce le doriți rezolvate. Le arătați noutățile în etape și monitorizați tichetele de la suport și feedbackul. Asigurați-vă că știți ce urmează, ce probleme ar putea apărea, care sunt plângerile lor, ce anume le place.
Pe baza acestui feedback, creați un șablon pe care să îl repetați la fiecare stadiu de dezvoltare. Analizați cum se adaptează utilizatorii și cum se simt. De aici, puteți apoi să vă dezvoltați și în alte direcții.
Dar ce se întâmplă în cadrul organizației noastre? De ce nu putem gestiona schimbările repede? De obicei, aveți câte un produs legacy care funcționează bine. E acolo, dar uneori vă gândiți că ar putea fi și mai bun și vă doriți să faceți această viziune realitate. De asemenea, știți că nu puteți pur și simplu eradica produsul și să începeți de la zero, deoarece este un produs vital care aduce 35% din venituri.
Faceți modificări mici, dar pe termen lung. Nu grăbiți lucrurile inutil, utilizatorii nu vor face față și nici organizația nu va putea face față.
Când aveam 7 sau 8 ani, bunicul meu s-a confruntat cu o problemă medicală, iar tatăl meu a încercat să îmi explice ce se întâmplă, iar ceea ce mi-a spus mi-a rămas în minte. Când apare o problemă, o infecție, trebuie să tai până la os, să scoți problema și să te asiguri că nu rămâne nimic și că nu există evoluție negativă.
Folosesc acest sfat în viața de zi cu zi. De multe ori, apar lucruri neprevăzute și trebuie să ne întrebăm dacă putem rezolva problemele, dacă trebuie să facem totul de la zero, dacă trebuie să renunțăm la ceva. Ne dezvoltăm astfel reziliența și devenim mai buni la gestionarea schimbării. Trebuie să promovăm securitate și siguranță, structură, viziune, autoritate.
Trebuie să iterăm, iar asta înseamnă a face compromisuri. Dacă dorim schimbări la nivel Enterprise, trebuie să vă mișcați lent și contează să puteți să vă puneți în genunchi și să vă schimbați atitudinea. Ce putem face la nivel de organizație?
Când am ajuns să lucrez în domeniul Enterprise, am avut primele interacțiuni cu dezvoltarea de produse în diverse faze, ceea ce corespunde metodologiei Waterfall. E în regulă. Poate funcționa foarte bine pentru mulți și presupune că cereți mulți bani, creați produsul, livrați produsul, oferiți mentenanță, iar, după doi ani, treceți la faza următoare. E în regulă, dar prietenii noștri din ecosistemul start-up ne spun că putem să facem lucrurile să meargă mai bine de atât. Deci, în loc să facem mentenanță și a avea o echipă cu un singur PM și doi programatori, veți avea o șansă de a face totul mai bine, dacă aveți un UX designer în permanență cu voi.
Nu înseamnă că această persoană va lucra 40 de ore pe săptămână, ci că va lucra câte o jumătate de zi pe săptămână. Dacă lucrați mereu la UX, veți face alocări mai inteligente. Veți reacționa mai rapid dacă ceva este greșit. Riscul scade lucrând săptămânal. Prin urmare, veți cere mai puțini bani în faza a doua, deoarece aveți lucruri mai puține de schimbat. Cum arată acest lucru în realitate?
Ca designer, vă oferiți pe voi și serviciile voastre ca ajutor real. Dacă sunteți PM, puteți solicita un designer care să lucreze cu voi săptămânal. Ca programator și tester, puteți face acest lucru.
Să zicem că aveți deja un designer care lucrează o jumătate de zi pe săptămână. Lucrați cu un PM la o listă de priorități. Ca designer puteți lucra în paralel la mai multe proiecte, în funcție de priorități. Puteți revizui tichetele de suport, puteți evalua designul lor, puteți promova inovații.
După ce aveți listele, începeți munca efectivă. Veți lucra lunar și veți livra rezultate lunar. Vrem să facem produsul mai bun, nu vrem să demonstrăm că ceva este bun sau rău, vrem să facem produsul mai bun.
Apoi, puneți accent pe colaborarea în echipe, arătați ce ați descoperit, arătați ce a descoperit echipa, ca să știți cum puteți evolua. Dacă cineva spune "Știu ce își dorește utilizatorul, lista mea de priorități e clară" invocați calul troian UX.
Calul troian UX presupune efectuarea testelor de folosire efectivă, pentru a demonstra cât de importantă este cercetarea cu utilizatori reali. Va fi un aspect eficient în dialogul cu factorii decizionali reticenți.
Este posibil ca factorii decizionali să știe deja ce se dorește "Hai să nu implementăm acea funcționalitate", dar tu poți spune "Dragă PM, am tot lucrat la interacțiunea aceasta, dar am dificultăți în a alege culoarea, textele. De aceea, aș vrea totuși să fac niște teste pentru a ne asigura că facem lucrurile bine."
Este foarte posibil să vi se răspundă: "Ok, fă testele." Creați scenarii în care să includeți și alte priorități din listă.
Când se va vedea că utilizatorul nu se descurcă foarte bine cu o funcționalitate netestată sau necercetată, vor constata că presupunerile lor sunt greșite sau învechite. Sunt câteva idei ca să determinați organizația să facă schimbări inteligent.
După cum spuneam anterior, Enterprise UX este un domeniu grozav, deoarece oferă posibilitatea introducerii de schimbări pozitive în viața cuiva. Da, utilizatorii nu pot gestiona schimbările bruște, dar îi putem ghida, ascultându-i și fiind empatici.
Organizația voastră nu poate gestiona schimbările rapide, dar puteți avansa lucrurile încet. Da, înseamnă a face și compromisuri. Puteți să vă schimbați atitudinea, dacă nu puteți schimba lucrurile.
de Ovidiu Mățan
de Alin Bobeica
de Daniel Pavăl
