Aduceți un proces de proiectare mai bun organizației dvs

În calitate de designeri și cercetători în experiența utilizatorului (UX), cea mai frecventă plângere pe care o auzim de la utilizatori este:

„De ce nu se gândesc la ceea ce am nevoie?”

De fapt, multe organizații au echipe dedicate să furnizeze ceea ce au nevoie utilizatorii și clienții. Din ce în ce mai mulți dezvoltatori de software sunt dornici să lucreze cu designeri UX pentru a codifica interfețele pe care clienții le vor folosi și înțelege. Problema este că proiectele software complexe se pot bloca cu ușurință în priorități concurente și confuzie cu privire la ce să facă în continuare.

Rezultatul este un design slab care împiedică productivitatea. De exemplu, eficiența asistenței medicale este îngreunată de dosarele medicale electronice (EMR). Plângerile cu privire la aceste sisteme software sunt numeroase. Dr. Steven Ugent, un dermatolog din Boston și absolvent la Yale Medical School, nu face excepție.

Din 2010, Dr. Ugent a folosit două sisteme EMR: Înainte de 2010, a terminat munca prompt la 5:15 în fiecare zi. Deoarece el și colegii săi au început să folosească EMR-uri, el lucrează de obicei o jumătate de oră suplimentară până la 1,5 ore seara. „Nu cunosc niciun medic care să fie mulțumit de sistemul lor de evidență medicală. Lucrul nebunesc este că eram mult mai eficient când foloseam pix și hârtie.”

Sistemele EMR sunt greoaie, inflexibile și greu de personalizat. Ugent, de exemplu, nu poate încorpora fotografii direct în notele sale de diagramă. În schimb, trebuie să deschidă folderul cu fotografia cârtiței și apoi să deschidă un alt folder pentru a vedea textul. Această configurație este deosebit de greoaie pentru dermatologii care se bazează foarte mult pe fotografii atunci când tratează pacienții.

Ugent rezumă succint problema cu EMR:

„Oamenii care îl proiectează [sistemul EMR] nu înțeleg fluxul meu de lucru. Dacă ar face-o, ar proiecta un alt sistem.”

Medicii nu sunt singuri în frustrarea lor față de software-ul greoi. Consumatorii și profesioniștii din întreaga lume fac plângeri similare:

„De ce nu pot găsi ceea ce am nevoie?”

„De ce fac ei atât de greu?”

„De ce trebuie să creez o autentificare atunci când vreau pur și simplu să cumpăr acest produs. Le dau bani. Nu este suficient?”

Un contributor major la software-ul greoi îl reprezintă procesele de proiectare defecte. În acest articol, vom schița patru probleme ale procesului de proiectare și vom explica cum să le rezolvăm.

1. Complexitate
2. Sindromul de eliberare următoare
3. Timp insuficient pentru iterațiile de proiectare
4. Predarea controlului furnizorilor externi

1. Complexitate

Amploarea, părțile interesate multiple și nevoia de cod sofisticat se numără printre mulți factori care contribuie la complexitatea proiectelor software mari.

Cu toate acestea, uneori sunt trecute cu vederea legile și reglementările complexe. De exemplu, asigurările sunt puternic reglementate la nivel de stat, adăugând un nivel de complexitate pentru companiile de asigurări care operează în mai multe state. Băncile și uniunile de credit sunt supuse reglementărilor, în timp ce utilitățile trebuie să respecte legile de mediu de stat și federale.

Produsele de sănătate și software-ul care fac obiectul reglementărilor FDA oferă o provocare și mai mare. Problema nu este că reglementările sunt nerezonabile. Siguranța este primordială. Problemele sunt timpul, bugetul și planificarea necesară pentru a îndeplini cerințele FDA.

După cum explică Jeff Horvath, Ph.D., un consultant UX cu o experiență vastă în asistența medicală: „Aceste cerințe adaugă câteva ordine de mărime la rigoarea pentru scrierea protocoalelor de testare, configurarea testelor, colectarea datelor, analiză, controale de calitate și obținerea aprobării pentru a efectua cercetarea în primul rând.” De exemplu, o singură rundă de testare a gradului de utilizare trece de la șase săptămâni (un interval de timp rezonabil pentru un test standard de utilizare) la șase luni. Și asta cu o singură rundă de testare a gradului de utilizare . Adesea, sunt necesare două sau mai multe runde de testare.

Acest nivel de rigoare este un semnal de alarmă pentru companiile care au început să lucreze cu FDA. De mai multe ori, Horvath s-a confruntat cu conversații dure cu clienți care nu erau pregătiți pentru termenele extinse și bugetul suplimentar necesar pentru a îndeplini cerințele FDA. Este greu, dar necesar. „Mă plătește să fii minuțios”, spune Horvath. În 2018, FDA a aprobat doar 11% din trimiterile înainte de comercializare.

Cererile de la cercetători, designeri și dezvoltatori sunt mai mari pentru software-ul de asistență medicală care necesită conformitatea FDA decât pentru produsele software tradiționale. De exemplu:

• Un cercetător UX poate efectua doar una sau două sesiuni de testare a gradului de utilizare pe zi, spre deosebire de cele mai comune cinci până la șase sesiuni pe zi pentru software-ul standard.
• Designerii UX trebuie să rămână foarte atenți la fiecare aspect al interacțiunii utilizatorului cu software-ul. Chiar și o interacțiune confuză ar putea determina un clinician să facă o eroare care ar putea pune în pericol sănătatea pacientului. Din același motiv, designerii UI trebuie să deseneze interfețe care să rămână fidele fiecărei interacțiuni.
• Un interval de timp mai lung pentru testarea designului și a utilizabilității înseamnă că eforturile de codare ale dezvoltatorului trebuie planificate cu atenție. Dezvoltatorii calificați și bine intenționați sunt adesea dornici să modifice codul de îndată ce noi informații devin disponibile. În timp ce această abordare poate funcționa în organizații bine practicate în iterare rapidă, ea prezintă riscuri atunci când se proiectează și se codifică sisteme complexe.

Eșecul de a gestiona complexitatea poate avea consecințe fatale, așa cum sa întâmplat atunci când Danielle McCray a fost internată la Spitalul Memorial Tallahassee, când era pe cale să nască. Pentru a-i ușura disconfortul, lucrătorii din domeniul sănătății au conectat-o ​​la un aparat de analgezie controlat de pacient, o pompă de perfuzie programabilă.

Opt ore mai târziu, McCray a fost declarat mort din cauza unei supradoze de morfină. Un factor major în această tragedie a fost designul defectuos al pompei de perfuzie folosită pentru administrarea medicamentelor. Pompa a necesitat 27 de pași de programare. Eșecul de a aborda o astfel de complexitate prin proiectarea unei interfețe de utilizator mai intuitive a contribuit la moartea inutilă.

Soluţie

Soluția este să recunoașteți și să abordați complexitatea. Acest punct sună logic. Cu toate acestea, așa cum sa explicat mai sus, reglementările complicate ale FDA surprind adesea liderii companiei. Negarea nu funcționează. Nerespectarea planificării înseamnă că organizația dvs. va intra probabil în cele 89% dintre cererile înainte de comercializare pe care FDA le-a respins în 2018.

Atunci când efectuează teste de utilizare, cercetătorii în experiența utilizatorului trebuie să facă trei pași pentru a gestiona complexitatea asociată cu reglementările FDA:

1. Moderatorul (persoana care rulează testul de utilizare) trebuie să fie hiperatent. De exemplu, dacă o scanare RMN necesită ca un tehnician să urmeze o secvență strictă de pași în timp ce folosește software-ul asociat, moderatorul trebuie să observe cu atenție pentru a determina dacă participantul urmează instrucțiunile la scrisoare. Dacă nu, sarcina este evaluată ca un eșec, ceea ce înseamnă că atât proiectarea interfeței, cât și documentația asociată vor necesita modificare;
2. Moderatorul trebuie să urmărească, de asemenea, apelurile de închidere. De exemplu, un participant ar putea inițial să efectueze pașii din ordine, să descopere greșeala și să-și revină urmând secvența corespunzătoare. FDA consideră că acest lucru este aproape ratat, iar moderatorul trebuie să îl raporteze ca atare;
3. Moderatorul trebuie să evalueze și cunoștințele participantului. Crede ea că a urmat succesiunea potrivită? Este această credință corectă?

2. Sindromul de eliberare următoare

Un factor în eșecul de a recunoaște complexitatea este o mentalitate de remediere mai târziu, pe care o numim sindromul următoarei lansări. Erorile software nu reprezintă o problemă pentru că „vom repara asta în următoarea ediție”. Accentul pus pe viteză în detrimentul calității și siguranței face prea ușor să amâni rezolvarea problemelor grele.

Oricine este implicat în proiectarea și dezvoltarea produsului trebuie să se lupte cu sindromul următoarei lansări. Două exemple arată ideea:

• Am descoperit defecte serioase de design cu software-ul de urmărire a asistenței medicale al unui client. Compania a ales să lanseze software-ul fără a rezolva aceste probleme. Nu este surprinzător că clienții au fost nemulțumiți.
• Am efectuat teste de utilizare pentru o mare uniune de credit cu sediul în SUA. Participanții au fost consilieri financiari experimentați. Testarea a scos la iveală defecte grave de design, inclusiv pictograme de stare confuze, butoane cu un scop neclar și o legătură aproape ascunsă care împiedică participanții să afișeze date importante. Amintiți-vă, dacă utilizatorul nu îl vede, nu este acolo. Când am raportat constatările, răspunsul a fost: „Vom remedia asta în următoarea ediție”. După cum era de așteptat, aplicația web nu a fost bine primită. Răspunsurile utilizatorilor au inclus: „De ce ne-ați cerut să examinăm aplicația dacă nu ați avut intenția de a face modificări?”

Soluție: respingeți mentalitatea Fix-It-Next-Time

Soluția este să abordăm probleme serioase de proiectare acum. Sună simplu. Dar, cum îi convingeți pe factorii de decizie să schimbe mentalitatea înrădăcinată de „remediere mai târziu”?

Cheia este de a muta conversația despre realizare de la livrarea produsului către valoarea creată. De exemplu, echipele care își iau timp pentru a revizui un design bazat pe cercetarea utilizatorilor sunt susceptibile de a observa reacții mai bune ale clienților și, în timp, de loialitate sporită a clienților.

Consolidați cazul utilizând date cantitative pentru a le arăta factorilor de decizie legătura directă dintre cercetarea utilizatorilor și creșterea veniturilor și o experiență pozitivă a clienților.

Redefinirea valorii este, de fapt, o îmbunătățire a procesului, deoarece stabilește un nou set de priorități care servesc mai bine clienții și interesele pe termen lung ale companiei dumneavoastră. După cum raportează McKinsey în The Business Value of Design: „Companiile de top-quartile îmbrățișează experiența completă a utilizatorului; ele înlătură barierele interne dintre designul fizic, digital și al serviciilor.”

3. Timp insuficient pentru iterațiile de proiectare

Legat de sindromul următoarei lansări este timpul insuficient pentru a repeta designul bazat pe rezultatele cercetării sau pe cerințele în schimbare ale afacerii. „Nu avem timp pentru asta”, este refrenul comun al dezvoltatorilor și proprietarilor de produse. Designerii care lucrează în medii Agile sunt adesea presați să evite să „rețină” echipa de dezvoltare.

Dezvoltarea se accelerează, iar software-ul este lansat. Cu toții am văzut rezultatele de la aplicații confuze pentru telefon, până la software-ul de înregistrări medicale greoaie, la interfața de utilizator greoaie pentru consilierii financiari la care se face referire mai sus.

Soluție: Design Spikes

O soluție vine din lumea codificării. În articolul său „Fitting Big-Picture UX Into Agile Development”, Damon Dimmick oferă ideea unor vârfuri de design, „bule de timp care permit designerilor să se concentreze pe probleme complexe de UX”. Se încadrează în cadrul Scrum luând temporar locul unui sprint obișnuit.

Picurile de design oferă mai multe avantaje:

• Acestea permit echipelor UX să se concentreze asupra problemelor holistice și să evite să se blocheze în probleme granulare de design, care sunt uneori subliniate într-un singur sprint;
• Ele oferă oportunitatea de a explora întrebări complexe UX de la un nivel înalt. Dacă este necesar, echipa de proiectare UX se poate implica, de asemenea, în gândirea centrată pe design în orice moment, pentru a rezolva provocări mai mari de UX;
• Prin adoptarea vârfurilor de design, echipele UX pot profita de aceeași flexibilitate pe care o folosesc echipele de dezvoltare în procesul agil și pot dedica timpul necesar concentrării asupra problemelor de design care nu se potrivesc întotdeauna bine într-un sprint standard de scrum;
• Dezvoltarea puțin probabil să fie afectată de deciziile de proiectare poate continua.

Desigur, iterațiile de design afectează adesea anumite părți ale codului pentru un site, o aplicație sau un produs software. Din acest motiv, în timpul vârfurilor de proiectare, orice cod care va fi probabil afectat de vârful de proiectare nu poate avansa. Dar, așa cum afirmă clar Dimmick, această „întârziere” va economisi probabil timp evitând relucrarea. Pur și simplu nu are sens să scrieți codul acum și apoi să-l rescrieți câteva săptămâni mai târziu, după ce echipa a convenit asupra unui design revizuit. Pe scurt, amânarea unor coduri economisește de fapt timp și buget.

4. Bazându-ne prea mult pe furnizori

Abordarea complexității, rezistența la sindromul următoarei lansări și acordarea timpului pentru iterare sunt esențiale pentru un proces de proiectare eficient. Pentru multe firme, o altă considerație este relația lor cu furnizorii de software. Acești furnizori joacă un rol important, chiar critic, în dezvoltare. Cu toate acestea, acordându-le prea multă pârghie, este dificil să vă controlați propriul produs.

Desigur, ar trebui să tratăm colegii și vânzătorii cu respect și să facem cereri rezonabile. Asta nu înseamnă, totuși, că este necesar să renunț la toate pârghiile, așa cum sa întâmplat în timpul mandatului meu la o mare firmă financiară.

În timp ce lucram la această firmă ca designer UX, am întâlnit frecvent această dinamică:

Manager : „Hei, Eric, poți evalua acest software de revendicare pe care intenționăm să-l cumpărăm? Vrem doar să ne asigurăm că funcționează conform intenției.”

Eu : „Sigur, vă voi trimite constatările mele preliminare până la sfârșitul săptămânii.”

Manager : „Super”

Urmatoarea saptamana:

Manager : „Mulțumesc pentru recenzie. Văd că ați găsit trei probleme serioase: greu de găsit numărul pentru o revendicare existentă, ecrane cu prea mult text greu de citit și dificultatea de a reveni la un ecran anterior atunci când procesați o nouă revendicare. Asta este îngrijorător. Crezi că aceste probleme vor împiedica productivitatea?”

Eu : „Da, cred că aceste probleme vor crește stresul și timpul de procesare în Centrul de reclamații. Sunt destul de îngrijorat pentru că munca mea anterioară cu echipa lui Janet a demonstrat că reprezentanții Centrului de reclamații sunt deja foarte stresați.”

Manager : „Foarte bine de știut. Tocmai am trimis cecul. Îi voi cere vânzătorului să rezolve problemele înainte de a expedia.”

Eu (țipând înăuntru): „Nuuuuuuuuuuuuuuuuuu!”

Acest manager bine intenționat a făcut exact lucrul greșit. A cerut modificări după ce a trimis cecul. Nu este surprinzător că vânzătorul nu a făcut niciodată modificările solicitate. De ce ar face-o? Aveau banii lor.

Nu numai că acest scenariu s-a jucat în mod repetat la acea companie, dar l-am asistat de-a lungul carierei mele UX.

Soluţie

Soluția este clară. Dacă produsul furnizorului nu satisface nevoile clienților și ale afacerii, iar modificările pe care le solicitați se încadrează în domeniul de aplicare, nu plătiți până când vânzătorul face modificările. Este într-adevăr atât de simplu.

Concluzie

În această piesă, am identificat patru bariere comune în calea designului de calitate și a soluțiilor corespunzătoare:

1. Reglementări și standarde complexe
   Soluția este să recunoașteți și să abordați complexitatea prin conceperea unor calendare realiste și a unui buget suficient pentru cercetare și proiectare iterativă.
2. Livrare software cu erori cu promisiunea de a le remedia mai târziu
   Soluția este să evitați sindromul următoarei eliberări și să abordați problemele grave acum. Convingeți factorii de decizie prin redefinirea semnificației valorii în cadrul organizației dvs.
3. Timp insuficient pentru iterații de proiectare
   Soluția este includerea vârfurilor de design în procesul de dezvoltare agilă. Aceste bule de timp iau temporar locul unui sprint și permit designerilor să se concentreze asupra problemelor complexe de UX.
4. Bazându-te prea mult pe vânzători
   Soluția este de a păstra efectul de levier prin reținerea plății finale până când vânzătorul face modificările solicitate, atâta timp cât aceste modificări se încadrează în domeniul inițial al proiectului.

A patra soluție este simplă. Deși primele trei nu sunt ușoare, sunt concrete, deoarece pot fi aplicate direct proceselor de proiectare existente. Implementarea lor nu necesită o reorganizare masivă sau milioane de dolari. Pur și simplu necesită angajament pentru a oferi o experiență mai bună.