Evaluarea unui sistem colaborativ are cu siguranță o complexitate suplimentară față de procesul de evaluare a unui sistem cu care fiecare utilizator interacționează independent. Unele metode de evaluare utilizează [2]:
- Euristici,
- scenarii,
- modele specifice sau framework-uri,
- modele bazate pe sarcini de grup, etc.
În contextul unui sistem colaborativ, „sarcina” tipică pe care o folosim pentru a testa într-un protocol cu un utilizator trebuie modificată pentru a lua în considerare contextul muncii în echipă [2].
Dacă faci parte dintr-o echipă de design sau dezvoltare care planifică reproiectarea unui sistem colaborativ, ai cel puțin patru surse complementare de soluții de evaluare, pe care le poți folosi în funcție de contextul proiectului:
- Testarea rapidă cu costuri reduse, de tip testare gherilă,
- evaluarea cu experți folosind euristici și/sau scenarii,
- metodele bazate pe cercetare etnografică,
- alte metode specifice.
Conform lui Guy [2], spre deosebire de evaluarea clasică (când un singur utilizator interacționează cu sistemul) pentru sistemele colaborative este fundamental să ai o viziune holistică, să dezvolți modelarea, abstractizarea și reprezentativitatea.
Este evident că nimic din cele de mai sus nu se poate baza pe un singur format de evaluare și că, pentru a avea o viziune holistică, este necesar să înțelegi foarte bine relațiile care se stabilesc între oameni și să cunoști contextul muncii colaborative, pe lângă evaluarea unui sistem pentru a-l reproiecta.
Fără îndoială, Google Drive este unul dintre produsele vedetă ale Google, motiv pentru care îmbunătățirea continuă este atât o prioritate, cât și un teritoriu sensibil pentru designerii săi.
Atunci când se fac modificări într-un sistem cu atât de mulți utilizatori, este fundamental să se mențină controlul și să se evite „aversiunea față de schimbare”, sau rezistența utilizatorilor frecvenți la modificarea unei interfețe.
În „Minimizing change aversion for the Google Drive launch” [3], lucrare prezentată la CHI 2013, echipa Google relatează cât de important este să se ia în considerare curba de învățare în utilizarea unui sistem.
În special, obișnuința cu un sistem face ca, chiar și în fața unei schimbări care ar trebui să-i îmbunătățească experiența, utilizatorul familiarizat poate prezenta o rezistență puternică la schimbare.
În acest sens, echipa de design Google se bazează pe teorii psihologice, explorează tipare de aversiune față de schimbare și analizează datele lansărilor de design anterioare pentru a pregăti noua lansare în producție a unei modificări de interfață.
Ca rezultat, propun următorul cadru de lucru, care poate fi cu siguranță foarte util pentru orice echipă care lucrează la reproiectarea unui sistem:
- Planificarea etapelor lansării.
- Evaluarea impactului asupra utilizatorului înainte de lansare.
- Pregătirea utilizatorilor pentru schimbarea planificată.
- Explicarea beneficiilor schimbării.
- Oferirea de sprijin în tranziție și suport.
- Permiterea utilizatorului să treacă de la versiunea nouă la cea veche. Notă: Acest punct este probabil unul dintre cele mai complexe, deoarece este dificil să faci să coexiste două interfețe, mai ales dacă există modificări tehnologice în spate.
- Monitorizarea și gestionarea schimbării în timp.
- Permiterea utilizatorilor să trimită feedback direct.
- Gestionarea rapidă a problemelor utilizatorilor.
- Informarea utilizatorului despre îmbunătățirile aduse.
Aceste sfaturi mi se par fundamentale pentru orice echipă care planifică o schimbare majoră într-o interfață. În munca mea, atât la Movistar, cât și la Sura, era o întrebare constantă: „Cum îmbunătățim experiența tuturor fără a genera frustrări pentru unii?”
Pe lângă aceasta, exista, evident, problema satisfacției. În acest sens, îmi amintesc și problema ridicată de directorii unui sistem ERP care ne-au spus că o simplă schimbare de buton, care ar fi trebuit să simplifice accesul la informații pentru directorii de servicii ai unei companii client, ar putea genera o creștere substanțială a apelurilor către serviciul de suport.
De ce? Directorii erau obișnuiți să facă 5 clicuri pentru a ajunge la un ecran și o făceau aproape robotic.
Prin schimbarea interfeței și punerea la dispoziție a acelorași informații în 4 clicuri, directorii se pierdeau și nu mai găseau informațiile. Frustrați, apelau serviciul de suport al platformei.
Acum, întrebarea este: ar trebui să faci o listă de verificare, să lipești aceste 10 sfaturi pe birou și să le urmezi cu strictețe? Depinde.
Google tinde să proiecteze servicii excepționale, iar echipa sa are, evident, experiența necesară pentru a face acest lucru. În realitatea locală, ca utilizator și ca manager, te întâlnești adesea cu servicii digitale învechite care necesită cu siguranță îmbunătățiri sau, literalmente, reproiectări și regândiri de la zero.
În cazurile extreme, decalajul dintre ceea ce există și ceea ce se așteaptă utilizatorul sau media a ceea ce suntem obișnuiți să vedem pe piață este atât de mare, încât aplicarea cu strictețe a fiecărui pas ar fi probabil inutilă.
Tocmai am primit un e-mail de la o companie financiară care anunța o schimbare în interfața sa digitală. Ca utilizatoare, mi-ar fi plăcut să văd mai întâi schimbările.
Pentru un sistem care are 5 până la 7 ani sau mai mult fără îmbunătățiri concrete, mai bine investești în testare și reproiectare decât în campanii de comunicare pentru a explica ce se va schimba, și ar fi trebuit să se schimbe acum 5 ani.
Dimpotrivă, atunci când se observă o preocupare constantă pentru experiența utilizatorului și se percep schimbări minore în mod recurent, se apreciază primirea unei comunicări care anunță o nouă funcționalitate sau una care va fi eliminată.
Ai participat la proiecte de reproiectare a sistemelor colaborative? Spune-ne experiența ta.
[1] El-Khawaga, G. H., Galal Hassan Galal-Edeen, G.H., Riad, A.M. (2013). Quality Attributes and Software Architectures Emerging Through Agile Development: Pursuit or Overlooking? International Journal of Software Engineering (IJSE), Volume (4) : Issue (1).
[2] Guy, E. (2005). “…real, concrete facts about what works …”: Integrating Evaluation and Design Through Patterns. Proceedings of GROUP’05, November 6–9, 2005, Sanibel Island, Florida, USA. Copyright 2005 ACM.
[3] Sedley, A.Müller, H. (2013). Minimizing change aversion for the Google Drive launch. En Proceedings: CHI’13 Extended Abstracts on Human Factors in Computing Systems, ACM, New York, NY, USA(2013), pp. 2351-2354.
De 
