Adevărate minciuni ale interfețelor de utilizator optimiste

Trei interfețe de utilizator (UI) merg la un pub. Primul comandă o băutură, apoi mai multe. Câteva ore mai târziu, cere nota de plată și pleacă beat de la cârciumă. A doua interfață comandă o băutură, o plătește în avans, comandă o altă băutură, o plătește și așa mai departe și în câteva ore pleacă beat din cârciuma. A treia interfață de utilizare iese din pub deja beată imediat după ce a intrat - știe cum funcționează pub-urile și este suficient de eficientă pentru a nu pierde timpul. Ai auzit de al treilea? Se numește „interfață de utilizare optimistă”.

Recent, după ce am discutat despre optimizarea performanței psihologice la o serie de conferințe dedicate atât dezvoltării front-end, cât și UX, am fost surprins să văd cât de puțin este abordată în comunitate subiectul designului optimist al UI. Sincer, termenul în sine nu este nici măcar bine definit. În acest articol, vom afla pe ce concepte se bazează și vom analiza câteva exemple și vom trece în revistă fundalul său psihologic. După aceea, vom trece în revistă preocupările și punctele principale cu privire la modul de a menține controlul asupra acestei tehnici UX.

Citiți suplimentare despre SmashingMag:

• Utilizatorul este designerul web anonim
• Proiectarea interfețelor utilizator bazate pe carduri
• Interfețe conversaționale: unde suntem astăzi?
  

Dar înainte de a începe, adevărul să fie spus, niciun lucru nu poate fi numit „interfață de utilizare optimistă”. Mai degrabă, este modelul mental din spatele implementării unei interfețe. Designul optimist al interfeței de utilizare are propria sa istorie și rațiune.

A fost odată ca niciodată

Cu mult timp în urmă – când cuvântul „tweet” se aplica mai ales păsărilor, Apple era în pragul falimentului și oamenii încă puneau numere de fax pe cărțile de vizită – interfețele web erau destul de ascetice. Iar marea majoritate dintre ei nu aveau nici măcar o urmă de optimism. O interacțiune cu un buton, de exemplu, ar putea urma un scenariu similar cu următorul:

1. Utilizatorul face clic pe un buton.
2. Butonul este declanșat într-o stare dezactivată.
3. Un apel este trimis către un server.
4. Un răspuns de la server este trimis înapoi la pagină.
5. Pagina este reîncărcată pentru a reflecta starea răspunsului.

Acest lucru ar putea părea destul de ineficient în 2016; cu toate acestea, destul de surprinzător, același scenariu este încă folosit în multe pagini web și aplicații și este încă o parte a procesului de interacțiune pentru multe produse. Motivul este că este previzibil și mai mult sau mai puțin rezistent la erori: utilizatorul știe că acțiunea a fost solicitată de la server (starea dezactivată a butonului sugerează acest lucru), iar odată ce serverul răspunde, pagina actualizată indică clar sfârşitul acestei interacţiuni client-server-client. Problemele cu acest tip de interacțiune sunt destul de evidente:

• Utilizatorul trebuie să aștepte. Până acum, știm că chiar și cea mai scurtă întârziere a timpului de răspuns al serverului are un efect negativ asupra percepției utilizatorului asupra întregii mărci, nu numai pe această pagină anume.
• De fiecare dată când utilizatorul primește un răspuns la acțiunea sa, acesta este prezentat într-un mod destul de distructiv (se încarcă o pagină nouă, în loc să fie actualizată cea existentă), ceea ce rupe contextul sarcinii utilizatorului și i-ar putea afecta trenul de gândire. Chiar dacă nu vorbim neapărat de multitasking în acest caz, orice schimbare a contextului mental este neplăcută. Deci, dacă o acțiune nu este menită în mod inerent să schimbe contexte (plata online este un exemplu bun de când o schimbare este naturală), schimbarea ar crea un ton neprietenos de dialog între utilizator și sistem.

Zile bune nu prea vechi

Apoi, a sosit așa-numitul Web 2.0 și a oferit noi moduri de interacțiune cu paginile web. Nucleul acestora au fost XMLHttpRequest și AJAX. Aceste noi moduri de interacțiune au fost completate de „spinners”: cea mai simplă formă de indicator de progres, al cărei singur scop a fost acela de a comunica utilizatorului că sistemul este ocupat cu o operațiune. Acum, nu a fost nevoie să reîncărcăm pagina după ce am primit un răspuns de la server; am putea actualiza doar o parte din pagina deja redată. Acest lucru a făcut web-ul mult mai dinamic, permițând în același timp experiențe mai fluide și mai captivante pentru utilizatori. Interacțiunea tipică cu un buton ar putea arăta acum astfel:

1. Utilizatorul face clic pe un buton.
2. Butonul este declanșat într-o stare dezactivată, iar pe buton este afișat un tip de rotitor pentru a indica că sistemul funcționează.
3. Se trimite un apel către server.
4. Un răspuns de la server este trimis înapoi la pagină.
5. Starea vizuală a butonului și a paginii sunt actualizate în funcție de starea răspunsului.

Acest nou model de interacțiune a abordat una dintre problemele menționate anterior ale vechii metode de interacțiune: Actualizarea paginii are loc fără o acțiune distructivă, păstrând contextul pentru utilizator și angajându-l în interacțiune mult mai bine decât înainte.

Acest tip de interacțiune a fost utilizat pe scară largă peste tot în mediile digitale. Dar rămâne o problemă: utilizatorii trebuie încă să aștepte un răspuns de la server. Da, putem face ca serverele noastre să răspundă mai repede, dar oricât am încerca să accelerăm infrastructura, utilizatorii trebuie totuși să aștepte. Din nou, utilizatorilor nu le place să aștepte, pentru a spune ușor. De exemplu, cercetările arată că 78% dintre consumatori simt emoții negative ca urmare a site-urilor web lente sau nesigure. Mai mult decât atât, potrivit unui sondaj realizat de Harris Interactive pentru Tealeaf, 23% dintre utilizatori mărturisesc că au înjurat telefoanele lor, 11% au țipat la ei, iar un întreg 4% și-au aruncat efectiv telefonul atunci când au întâmpinat o problemă cu o tranzacție online. Întârzierile sunt printre aceste probleme.

Chiar dacă afișați un fel de indicator de progres în timp ce utilizatorul așteaptă, cu excepția cazului în care sunteți foarte creativ cu indicatorul, în zilele noastre pur și simplu nu este suficient. În cea mai mare parte, oamenii s-au obișnuit cu spinnerele care indică încetineala unui sistem. Spinnerii sunt acum mai asociați cu așteptarea pur pasivă, când utilizatorul nu are altă opțiune decât să aștepte răspunsul serverului sau să închidă complet fila sau aplicația. Deci, să venim cu un pas pentru a îmbunătăți acest tip de interacțiune; să ne uităm la acest concept de interfață de utilizare optimistă.

Interfață de utilizare optimistă

După cum am menționat, o interfață de utilizare optimistă nu este altceva decât o modalitate de a gestiona interacțiunea om-calculator. Pentru a înțelege ideile principale din spatele acestuia, vom rămâne cu scenariul nostru „utilizatorul face clic pe un buton”. Dar principiul va fi același pentru aproape orice tip de interacțiune pe care ați dori să o faceți optimist. Conform dicționarului englez Oxford:

op-ti-mis-tic , adj. plin de speranță și încrezător în viitor.

Să începem cu partea „încrezătoare în viitor”.

Ce părere aveți: cât de des returnează serverul dvs. o eroare la o acțiune a utilizatorului? De exemplu, API-ul dvs. eșuează des atunci când utilizatorii dau clic pe un buton? Sau poate eșuează mult atunci când utilizatorii dau clic pe un link? Sincer, nu cred. Desigur, acest lucru poate varia în funcție de API-ul, încărcarea serverului, nivelul de tratare a erorilor și alți factori în care tu, ca dezvoltator front-end sau specialist UX, s-ar putea să nu fii dispus să te implici. Dar atâta timp cât API-ul este stabil și previzibil și front-end-ul comunică corect acțiunile legitime în UI, atunci numărul de erori ca răspuns la acțiunile inițiate de utilizator va fi destul de scăzut. Aș merge până acolo încât să afirm că nu ar trebui să treacă niciodată peste 1 până la 3%. Aceasta înseamnă că în 97 până la 99% din cazuri când utilizatorul face clic pe un buton de pe un site web, răspunsul serverului ar trebui să fie de succes, fără erori. Acest lucru merită să fie pus într-o perspectivă mai bună:

Gândiți-vă la asta pentru un moment: dacă am fi siguri în proporție de 97 până la 99% despre un răspuns de succes, am putea fi încrezători în viitorul acestor răspunsuri - ei bine, cel puțin mult mai încrezător în viitor decât era pisica lui Schrodinger. Am putea scrie o poveste cu totul nouă despre interacțiunea butoanelor:

1. Utilizatorul face clic pe un buton.
2. Starea vizuală a butonului este declanșată instantaneu în modul de succes.

Asta e! Cel puțin din punctul de vedere al utilizatorului, nu mai este nimic în plus - fără așteptare, fără să te uiți la un buton dezactivat și nu încă un alt rotisor enervant. Interacțiunea este fără întreruperi, fără ca sistemul să intervină grosolan pentru a reaminti utilizatorului despre sine.

Din punctul de vedere al dezvoltatorului, ciclul complet arată astfel:

1. Utilizatorul face clic pe un buton.
2. Starea vizuală a butonului este declanșată instantaneu în modul de succes.
3. Apelul este trimis către server.
4. Răspunsul de la server este trimis înapoi la pagină.
5. În 97 până la 99% din cazuri, știm că răspunsul va fi de succes și, prin urmare, nu trebuie să deranjăm utilizatorul.
6. Doar în cazul unei cereri eșuate, sistemul va vorbi. Nu vă faceți griji pentru acest lucru pentru moment - vom ajunge la acest punct mai târziu în articol.

Să ne uităm la câteva exemple de interacțiuni optimiste. Probabil că sunteți familiarizat cu butoanele de „like”, așa cum se găsesc pe Facebook și Twitter. Să aruncăm o privire la acesta din urmă.

Începe, evident, cu apăsarea butonului. Dar rețineți starea vizuală a butonului atunci când utilizatorul nu mai apasă sau nu mai trece cu mouse-ul peste buton. Trece instantaneu la starea de succes!

Să vedem ce se întâmplă în fila „Rețea” a instrumentelor de dezvoltare ale browserului nostru chiar în acest moment.

Fila „Rețea” arată că cererea de server a fost trimisă, dar este încă în curs. Numărul contorului de „like” nu a fost încă incrementat, dar odată cu schimbarea culorii, interfața comunică clar succesul utilizatorului, chiar înainte de a primi un răspuns de la server.

După ce se primește un răspuns de succes de la server, contorul este actualizat, dar tranziția este mult mai subtilă decât schimbarea instantanee a culorii. Acest lucru oferă utilizatorului o experiență lină, neîntreruptă, fără nicio așteptare percepută.

Un alt exemplu de interacțiune optimistă se vede pe Facebook, cu propriul buton de like. Scenariul este destul de similar, cu excepția faptului că Facebook actualizează contorul instantaneu, împreună cu culoarea de succes a butonului, fără a aștepta răspunsul serverului.

Un lucru de remarcat aici, totuși. Dacă ne uităm la timpul de răspuns al serverului, vom vedea că este puțin peste 1 secundă . Având în vedere că modelul RAIL recomandă 100 de milisecunde ca timp optim de răspuns pentru o interacțiune simplă, acest lucru ar fi în mod normal mult prea lung. Cu toate acestea, utilizatorul nu percepe niciun timp de așteptare în acest caz din cauza naturii optimiste a acestei interacțiuni. Grozav! Acesta este un alt exemplu de optimizare a performanței psihologice .

Dar să recunoaștem: există încă 1 până la 3% șanse ca serverul să returneze o eroare. Sau poate că utilizatorul este pur și simplu offline. Sau, mai probabil, poate că serverul returnează ceea ce din punct de vedere tehnic este un răspuns de succes, dar răspunsul conține informații care trebuie procesate în continuare de către client. Drept urmare, utilizatorul nu va primi un indicator de eșec, dar nici nu putem considera răspunsul un succes. Pentru a înțelege cum să tratăm astfel de cazuri, ar trebui să înțelegem de ce și cât de optimiste funcționează psihologic interfețele de utilizator.

Psihologia din spatele interfețelor de utilizare optimiste

Până acum, nu am auzit pe nimeni să se plângă de interacțiunile optimiste menționate mai sus pe principalele rețele de socializare. Deci, să spunem că aceste exemple ne-au convins că interfețele de utilizator optimiste funcționează. Dar de ce funcționează pentru utilizatori? Ei lucrează pur și simplu pentru că oamenii urăsc așteptarea. Asta e, oameni buni! Puteți sări la următoarea parte a articolului.

Dar dacă încă mai citești, atunci probabil că ești interesat să știi de ce este așa. Deci, haideți să pătrundem puțin mai adânc în temeiul psihologic al acestei abordări.

O interfață de utilizare optimistă are două ingrediente de bază care merită analizate psihologice:

• răspunsul rapid la acțiunea utilizatorului;
• gestionarea defecțiunilor potențiale pe server, pe rețea și în alte părți.

Răspuns rapid la acțiunea utilizatorului

Când vorbim despre design optimist al UI, vorbim despre un timp optim de răspuns în interacțiunea om-calculator. Și recomandările pentru acest tip de comunicare există încă din 1968. Pe atunci, Robert B. Miller a publicat piesa sa fundamentală „Response Time in Man-Computer Conversational Transactions” (PDF), în care definește până la 17 diferite tipuri de răspunsuri pe care un utilizator le poate obține de la un computer. Unul dintre acele tipuri pe care Miller îl numește „răspuns la activarea controlului” - întârzierea dintre apăsarea unei taste și feedback-ul vizual. Chiar și în 1968, nu ar fi trebuit să depășească 0,1 până la 0,2 secunde. Da, modelul RAIL nu este primul care recomandă acest lucru – sfatul există de aproximativ 50 de ani. Miller notează, totuși, că chiar și această scurtă întârziere în feedback ar putea fi mult prea lentă pentru utilizatorii calificați. Aceasta înseamnă că, în mod ideal, utilizatorul ar trebui să primească o confirmare a acțiunii sale în 100 de milisecunde . Aceasta se încadrează în gama uneia dintre cele mai rapide acțiuni inconștiente pe care corpul uman le poate efectua - o clipire. Din acest motiv, intervalul de 100 de milisecunde este de obicei perceput ca fiind instantaneu. „Cei mai mulți oameni clipesc de aproximativ 15 ori pe minut și o clipire durează în medie 100 până la 150 de milisecunde”, spune Davina Bristow, de la Institutul de Neurologie al University College London, adăugând că acest lucru „înseamnă că în general petrecem cel puțin 9 zile pe an clipind. ”

Datorită răspunsului său vizual instantaneu (chiar înainte ca cererea reală să se termine), o interfață de utilizare optimistă este unul dintre exemplele tehnicilor de finalizare timpurie utilizate în optimizarea performanței psihologice. Dar faptul că oamenilor le plac interfețele care răspund într-o clipă nu ar trebui să fie o surpriză pentru majoritatea dintre noi, într-adevăr. Și nici nu este greu de realizat. Chiar și pe vremuri, dezactivam butoanele imediat după ce erau apăsate, iar acest lucru era de obicei suficient pentru a confirma intrarea utilizatorului. Dar o stare dezactivată într-un element de interfață înseamnă așteptare pasivă: utilizatorul nu poate face nimic în acest sens și nu are control asupra procesului. Și acest lucru este foarte frustrant pentru utilizator. De aceea, omitem cu totul starea dezactivată într-o interfață de utilizare optimistă - comunicăm un rezultat pozitiv în loc să-l facem pe utilizator să aștepte.

Gestionarea eșecului potențial

Să ajungem la al doilea aspect psihologic interesant al designului optimist al interfeței de utilizare - gestionarea potențialului eșec. În general, sunt disponibile o mulțime de informații și articole despre cum să gestionați erorile UI în cel mai bun mod posibil. Cu toate acestea, deși vom vedea cum să gestionăm eșecul mai târziu în acest articol, ceea ce contează cel mai mult într-o interfață de utilizare optimistă nu este modul în care gestionăm erorile, ci când o facem.

Oamenii își organizează în mod natural activitatea în aglomerări, încheiate prin îndeplinirea unui scop sau subscop ​​definit subiectiv. Uneori, ne referim la aceste aglomerări drept „un tren de gândire”, un „flux de gândire” (PDF) sau pur și simplu un „flux”. Starea de flux este caracterizată prin plăcere maximă, concentrare energetică și concentrare creativă. În timpul unui flux, utilizatorul este complet absorbit de activitate. Un tweet al lui Tammy Everts ilustrează frumos acest lucru:

Pe web, duratele unor astfel de grupuri de activitate sunt mult mai scurte. Să revedem pentru un moment munca lui Robert B. Miller. Tipurile de răspuns pe care le citează includ:

• un răspuns la o întrebare simplă a informațiilor enumerate;
• un răspuns la o întrebare complexă sub formă grafică;
• un răspuns la „Sistem, mă înțelegi?”

El le leagă pe toate acestea de același interval de 2 secunde în care utilizatorul ar trebui să obțină tipul relevant de răspuns. Fără a săpă mai adânc, ar trebui să remarcăm că acest interval depinde și de memoria de lucru a unei persoane (referindu-se la intervalul de timp în care o persoană poate păstra o anumită cantitate de informații în cap și, mai important, poate să o manipuleze). Pentru noi, ca dezvoltatori și specialiști UX, asta înseamnă că în 2 secunde de la interacțiunea cu un element, utilizatorul va fi într-un flux și se va concentra asupra răspunsului pe care îl așteaptă. Dacă serverul returnează o eroare în acest interval, utilizatorul va fi în continuare în „dialog” cu interfața, ca să spunem așa. Este similar cu un dialog între două persoane, în care spui ceva și cealaltă persoană nu este ușor de acord cu tine. Imaginați-vă dacă cealaltă persoană a petrecut mult timp dând din cap în acord (echivalentul indicației noastre privind starea de succes în UI), dar apoi v-a spus „nu”. Incomod, nu-i așa? Deci, o interfață de utilizare optimistă trebuie să comunice eșecul utilizatorului în cele 2 secunde ale fluxului.

Înarmați cu psihologia cum să gestionăm eșecul într-o interfață de utilizare optimistă, să ajungem în sfârșit la acele 1 până la 3% dintre solicitările eșuate.

Partea pesimistă a designului UI optimist

De departe, cea mai comună remarcă pe care o aud este că designul optimist al interfeței de utilizare este un fel de model negru - trișare, dacă vrei. Adică, utilizând-o, ne mințim utilizatorii cu privire la rezultatul interacțiunii lor. Din punct de vedere legal, orice instanță ar susține probabil acest punct. Totuși, consider tehnica o predicție sau o speranță. (Îți amintești de definiția termenului „optimist”? Aici permitem puțin spațiu pentru partea „de speranță” a acestuia.) Diferența dintre „mințiune” și „prevăzare” este în modul în care tratezi acele 1 până la 3% dintre cererile eșuate. Să vedem cum se comportă offline butonul optimist „Like” al Twitter.

În primul rând, în conformitate cu modelul optimist al interfeței de utilizare, butonul trece la starea de succes imediat după ce a fost făcut clic - din nou, fără ca utilizatorul să mai apese sau să treacă peste buton, exact așa cum se comportă butonul atunci când utilizatorul este online.

Dar, deoarece utilizatorul este offline, cererea eșuează.

Deci, cât mai curând posibil în fluxul utilizatorului, eșecul ar trebui comunicat. Din nou, 2 secunde este de obicei durata unui astfel de flux. Twitter comunică acest lucru în cel mai subtil mod posibil, pur și simplu prin revenirea stării butonului.

Cititorul conștiincios de aici ar putea spune că această gestionare a erorilor ar putea fi dusă cu un pas mai departe, notificând efectiv utilizatorul că solicitarea nu a putut fi trimisă sau că a apărut o eroare. Acest lucru ar face sistemul cât mai transparent posibil. Dar există o captură – sau, mai degrabă, o serie de probleme:

• Orice fel de notificare care apare brusc pe ecran ar schimba contextul utilizatorului, determinându-l să analizeze motivul din spatele eșecului, motiv care ar fi probabil prezentat în mesajul de eroare.
• Ca și în cazul oricărui mesaj de eroare sau notificare, acesta ar trebui să ghideze utilizatorul în acest nou context, oferind informații utile.
• Acea informație acționabilă ar stabili un alt context.

OK, până acum suntem cu toții de acord că acest lucru devine puțin complicat. Deși această gestionare a erorilor ar fi rezonabilă pentru, să zicem, o formă mare pe un site web, pentru o acțiune la fel de simplă precum a face clic pe un buton de like, este exagerată - atât în ​​ceea ce privește dezvoltarea tehnică necesară, cât și memoria de lucru a utilizatorilor.

Deci, da, ar trebui să fim deschiși în privința eșecului într-o interfață de utilizare optimistă și ar trebui să-l comunicăm cât mai curând posibil, astfel încât optimismul nostru să nu devină o minciună. Dar ar trebui să fie proporțional cu contextul. Pentru un like eșuat, revenirea subtilă a butonului la starea inițială ar trebui să fie suficientă - adică, cu excepția cazului în care utilizatorului îi place statutul celuilalt semnificativ, caz în care lucrul mai bine funcționează tot timpul.

Pesimism extrem

Ar putea apărea o altă întrebare: ce se întâmplă dacă utilizatorul închide fila browser imediat după ce a primit un indicator de succes, dar înainte ca răspunsul să fie returnat de la server? Cel mai neplăcut caz ar fi dacă utilizatorul închide fila înainte ca o solicitare să fie trimisă către server. Dar dacă utilizatorul nu este extrem de agil sau are capacitatea de a încetini timpul, acest lucru este greu de posibil.

Dacă o interfață de utilizare optimistă este implementată corect și interacțiunile sunt aplicate numai acelor elemente care nu așteaptă niciodată mai mult de 2 secunde pentru un răspuns de la server, atunci utilizatorul ar trebui să închidă fila browserului în acea fereastră de 2 secunde. Acest lucru nu este deosebit de dificil cu o apăsare a tastei; totuși, după cum am văzut, în 97 până la 99% din cazuri, cererea va avea succes, indiferent dacă fila este activă sau nu (doar că un răspuns nu va fi returnat clientului).

Deci, această problemă ar putea apărea numai pentru cei 1 până la 3% care primesc o eroare de server. Apoi, din nou, câți dintre aceștia se grăbesc să închidă fila în 2 secunde? Cu excepția cazului în care sunt într-o competiție de viteză de închidere a filelor, nu cred că numărul va fi semnificativ. Dar dacă simțiți că acest lucru este relevant pentru proiectul dvs. particular și ar putea avea consecințe negative, atunci folosiți câteva instrumente pentru a analiza comportamentul utilizatorului; dacă probabilitatea unui astfel de scenariu este suficient de mare, atunci limitați interacțiunea optimistă la elemente necritice.

Nu am menționat în mod intenționat cazuri în care o cerere este amânată artificial; acestea nu se încadrează în general sub umbrela unui design optimist al UI. Mai mult decât atât, am petrecut mai mult decât suficient timp pe partea pesimistă a lucrurilor, așa că haideți să rezumam câteva puncte principale despre implementarea unei bune interfețe de utilizare optimiste.

Regulile generale

Sper din tot sufletul că acest articol v-a ajutat să înțelegeți unele dintre conceptele principale din spatele unui design optimist al UI. Poate că ești interesant să încerci această abordare în următorul tău proiect. Dacă da, iată câteva lucruri de reținut înainte de a începe:

• O condiție prealabilă pentru tot ceea ce am vorbit până acum: asigurați-vă că API-ul pe care vă bazați este stabil și returnează rezultate previzibile. Destul spus.
• Interfața ar trebui să detecteze potențiale erori și probleme înainte ca o solicitare să fie trimisă la server. Mai bine, eliminați total orice ar putea duce la o eroare din API. Cu cât un element UI este mai simplu, cu atât mai simplu va fi să-l faci optimist.
• Aplicați modele optimiste elementelor simple asemănătoare binare pentru care nu se așteaptă decât un răspuns de succes sau eșec. De exemplu, dacă un clic pe buton presupune un răspuns al serverului, cum ar fi „da”, „nu” sau „poate” (toate acestea pot reprezenta succes în diferite grade), un astfel de buton ar fi mai bine fără un model optimist.
• Aflați timpii de răspuns ale API-ului dvs. Acest lucru este crucial. Dacă știți că timpul de răspuns pentru o anumită solicitare nu scade niciodată sub 2 secunde, atunci este probabil cel mai bine să vă presărați mai întâi optimism asupra API-ului. După cum am menționat, o interfață de utilizare optimistă funcționează cel mai bine pentru timpi de răspuns al serverului de mai puțin de 2 secunde. A depăși acest lucru ar putea duce la rezultate neașteptate și la mulți utilizatori frustrați. Consideră-te avertizat.
• O interfață de utilizare optimistă nu se referă doar la clicurile pe butoane. Abordarea ar putea fi aplicată la diferite interacțiuni și evenimente din timpul ciclului de viață al unei pagini, inclusiv la încărcarea paginii. De exemplu, ecranele schelete urmează aceeași idee: preziceți că serverul va răspunde cu succes pentru a completa substituenți pentru a le arăta utilizatorului cât mai curând posibil.

Designul optimist al UI nu este cu adevărat o noutate pe web și nici nu este o tehnică deosebit de avansată, așa cum am văzut. Este doar o altă abordare, un alt model mental, care să te ajute să gestionezi performanța percepută a produsului tău. Fiind întemeiat pe aspectele psihologice ale interacțiunii om-calculator, designul optimist al interfeței de utilizare, atunci când este utilizat în mod inteligent, vă poate ajuta să construiți experiențe mai bune și mai perfecte pe web, în ​​timp ce necesită foarte puțin pentru implementare. Dar, pentru a face modelul cu adevărat eficient și pentru a împiedica produsele noastre să mintă utilizatorii, trebuie să înțelegem mecanica designului optimist al UI.

Resurse

• „Timpul de răspuns în tranzacțiile conversaționale om-calculator” (PDF), Robert B. Miller, Fall Joint Computer Conference, 1968
• „Prezentarea RAIL: Un model centrat pe utilizator pentru performanță”, Paul Irish, Paul Lewis, Smashing Magazine, 2015
• „Mobile Web Stress: The Impact of Network Speed ​​on Emotional Engagement and Brand Perception”, Tammy Everts, Radware Blog, 2013
• Aplicații ale fluxului în dezvoltarea umană și educație , Mihaly Csikszentmihalyi, 2014
• „Detalii de design mobil: evitați cel care învârte”, Luke Wroblewski, 2013
• „De ce contează performanța, partea 2: managementul percepției”, Denys Mishunov, Smashing Magazine, 2015