Kebohongan Sejati Dari Antarmuka Pengguna yang Optimis

Tiga antarmuka pengguna (UI) pergi ke sebuah pub. Yang pertama memesan minuman, lalu beberapa lagi. Beberapa jam kemudian, ia meminta tagihan dan meninggalkan pub dalam keadaan mabuk. UI kedua memesan minuman, membayarnya di muka, memesan minuman lagi, membayarnya, dan seterusnya, dan dalam beberapa jam meninggalkan pub dalam keadaan mabuk. UI ketiga keluar dari pub yang sudah mabuk segera setelah masuk — ia tahu cara kerja pub dan cukup efisien untuk tidak kehilangan waktu. Pernah dengar yang ketiga ini? Ini disebut "UI yang optimis."

Baru-baru ini, setelah membahas optimasi kinerja psikologis di sejumlah konferensi yang didedikasikan untuk pengembangan front-end dan UX, saya terkejut melihat betapa sedikit topik desain UI yang optimis dibahas di komunitas. Terus terang, istilah itu sendiri bahkan tidak didefinisikan dengan baik. Dalam artikel ini, kita akan mengetahui konsep apa yang mendasarinya, dan kita akan melihat beberapa contoh serta meninjau latar belakang psikologisnya. Setelah itu, kami akan meninjau kekhawatiran dan poin utama tentang cara mempertahankan kontrol atas teknik UX ini.

Bacaan Lebih Lanjut tentang SmashingMag:

• Pengguna Adalah Perancang Web Anonim
• Merancang Antarmuka Pengguna Berbasis Kartu
• Antarmuka Percakapan: Di Mana Kita Saat Ini?
  

Tapi sebelum kita mulai, sejujurnya, tidak ada satu hal pun yang bisa disebut sebagai "UI yang optimis." Sebaliknya, ini adalah model mental di balik implementasi antarmuka. Desain UI yang optimis memiliki sejarah dan alasannya sendiri.

Pada suatu ketika

Dahulu kala — ketika kata “tweet” sebagian besar digunakan untuk burung, Apple berada di ambang kebangkrutan dan orang-orang masih memasukkan nomor faks pada kartu nama mereka — antarmuka web cukup asketis. Dan sebagian besar dari mereka bahkan tidak memiliki sedikit pun optimisme. Interaksi dengan tombol, misalnya, dapat mengikuti skenario yang mirip dengan berikut ini:

1. Pengguna mengklik tombol.
2. Tombol dipicu ke keadaan nonaktif.
3. Panggilan dikirim ke server.
4. Respons dari server dikirim kembali ke halaman.
5. Halaman dimuat ulang untuk mencerminkan status tanggapan.

Ini mungkin terlihat sangat tidak efisien di tahun 2016; namun, cukup mengejutkan, skenario yang sama masih digunakan di banyak halaman web dan aplikasi dan masih menjadi bagian dari proses interaksi untuk banyak produk. Alasannya adalah dapat diprediksi dan kurang lebih tahan kesalahan: Pengguna mengetahui bahwa tindakan telah diminta dari server (kondisi tombol yang dinonaktifkan mengisyaratkan hal ini), dan setelah server merespons, halaman yang diperbarui dengan jelas menunjukkan akhir dari interaksi klien-server-klien ini. Masalah dengan interaksi semacam ini cukup jelas:

• Pengguna harus menunggu. Sekarang, kita tahu bahwa penundaan terpendek dalam waktu respons server memiliki efek negatif pada persepsi pengguna terhadap seluruh merek, tidak hanya pada halaman khusus ini.
• Setiap kali pengguna mendapat respons atas tindakan mereka, itu disajikan dengan cara yang cukup merusak (halaman baru dimuat, alih-alih yang sudah ada diperbarui), yang memecah konteks tugas pengguna dan mungkin memengaruhi jalan pemikiran mereka. Meskipun kita tidak harus berbicara tentang multitasking dalam kasus ini, perubahan konteks mental apa pun tidak menyenangkan. Jadi, jika suatu tindakan tidak secara inheren dimaksudkan untuk mengalihkan konteks (pembayaran online adalah contoh yang baik ketika peralihan itu alami), peralihan akan membentuk nada dialog yang tidak ramah antara pengguna dan sistem.

Hari-hari yang Tidak Terlalu Lama

Kemudian, apa yang disebut Web 2.0 tiba dan menyediakan mode interaksi baru dengan halaman web. Inti dari ini adalah XMLHttpRequest dan AJAX. Mode interaksi baru ini dilengkapi dengan "pemintal": bentuk paling sederhana dari indikator kemajuan, yang satu-satunya tujuan adalah untuk mengomunikasikan kepada pengguna bahwa sistem sedang sibuk melakukan beberapa operasi. Sekarang, kami tidak perlu memuat ulang halaman setelah mendapat respons dari server; kami hanya dapat memperbarui bagian dari halaman yang sudah dirender. Hal ini membuat web jauh lebih dinamis, sekaligus memungkinkan pengalaman yang lebih lancar dan lebih menarik bagi pengguna. Interaksi khas dengan tombol sekarang dapat terlihat seperti ini:

1. Pengguna mengklik tombol.
2. Tombol dipicu ke keadaan nonaktif, dan semacam pemintal ditampilkan pada tombol untuk menunjukkan sistem bekerja.
3. Panggilan dikirim ke server.
4. Respons dari server dikirim kembali ke halaman.
5. Status visual tombol dan halaman diperbarui sesuai dengan status respons.

Model interaksi baru ini mengatasi salah satu masalah yang disebutkan di atas dari metode interaksi lama: Pembaruan halaman terjadi tanpa tindakan merusak, menjaga konteks bagi pengguna dan melibatkan mereka dalam interaksi jauh lebih baik daripada sebelumnya.

Pola interaksi semacam ini telah banyak digunakan di mana-mana di media digital. Tetapi satu masalah tetap ada: Pengguna masih harus menunggu tanggapan dari server. Ya, kami dapat membuat server kami merespons lebih cepat, tetapi tidak peduli seberapa keras kami mencoba untuk mempercepat infrastruktur, pengguna masih harus menunggu. Sekali lagi, pengguna tidak suka menunggu, secara halus. Misalnya, penelitian menunjukkan bahwa 78% konsumen merasakan emosi negatif sebagai akibat dari situs web yang lambat atau tidak dapat diandalkan. Selain itu, menurut survei yang dilakukan oleh Harris Interactive untuk Tealeaf, 23% pengguna mengaku memaki ponsel mereka, 11% berteriak pada mereka, dan 4% keseluruhan benar-benar melempar ponsel mereka ketika mengalami masalah dengan transaksi online. Keterlambatan adalah salah satu masalah itu.

Bahkan jika Anda menunjukkan semacam indikator kemajuan saat pengguna menunggu, kecuali Anda sangat kreatif dengan indikator tersebut, saat ini itu tidak cukup. Untuk sebagian besar, orang sudah terbiasa dengan pemintal yang menunjukkan kelambatan sistem. Pemintal sekarang lebih terkait dengan menunggu pasif murni, ketika pengguna tidak memiliki pilihan selain menunggu respons server atau menutup tab atau aplikasi sama sekali. Jadi, mari datang dengan langkah untuk meningkatkan interaksi semacam ini; mari kita lihat konsep UI yang optimis ini.

UI Optimis

Seperti disebutkan, UI yang optimis tidak lebih dari cara menangani interaksi manusia-komputer. Untuk memahami ide utama di baliknya, kami akan tetap menggunakan skenario "pengguna mengklik tombol" kami. Tetapi prinsipnya akan sama untuk hampir semua jenis interaksi yang mungkin ingin Anda buat optimis. Menurut Kamus Bahasa Inggris Oxford:

op-ti-mis-tic , adj. penuh harapan dan keyakinan tentang masa depan.

Mari kita mulai dengan bagian "yakin tentang masa depan".

Bagaimana menurut Anda: Seberapa sering server Anda mengembalikan kesalahan pada beberapa tindakan pengguna? Misalnya, apakah API Anda sering gagal saat pengguna mengklik tombol? Atau mungkin sering gagal ketika pengguna mengklik tautan? Terus terang, saya tidak berpikir begitu. Tentu saja, ini mungkin berbeda berdasarkan API, beban server, tingkat penanganan kesalahan, dan faktor lain yang Anda, sebagai pengembang front-end atau spesialis UX, mungkin tidak mau terlibat. Tetapi selama API stabil dan dapat diprediksi dan ujung depan mengomunikasikan tindakan yang sah dengan benar di UI, maka jumlah kesalahan dalam menanggapi tindakan yang dimulai oleh pengguna akan cukup rendah. Saya akan melangkah lebih jauh dengan menyatakan bahwa mereka tidak boleh melebihi 1 hingga 3%. Ini berarti bahwa dalam 97 hingga 99% kasus ketika pengguna mengklik tombol di situs web, respons server seharusnya berhasil, tanpa kesalahan. Ini layak untuk diletakkan dalam perspektif yang lebih baik:

Pikirkan sejenak: Jika kita yakin 97 hingga 99% tentang respons yang sukses, kita bisa yakin tentang masa depan respons tersebut — yah, setidaknya jauh lebih yakin tentang masa depan daripada kucing Schrodinger. Kita bisa menulis cerita baru tentang interaksi tombol:

1. Pengguna mengklik tombol.
2. Status visual tombol dipicu ke mode sukses secara instan.

Itu dia! Setidaknya dari sudut pandang pengguna, tidak ada yang lebih dari itu — tidak menunggu, tidak menatap tombol yang dinonaktifkan, dan tidak ada pemintal yang mengganggu lainnya. Interaksinya mulus, tanpa sistem secara kasar masuk untuk mengingatkan pengguna tentang dirinya sendiri.

Dari sudut pandang pengembang, siklus lengkapnya terlihat seperti ini:

1. Pengguna mengklik tombol.
2. Status visual tombol dipicu ke mode sukses secara instan.
3. Panggilan dikirim ke server.
4. Respons dari server dikirim kembali ke halaman.
5. Dalam 97 hingga 99% kasus, kami tahu bahwa responsnya akan berhasil, jadi kami tidak perlu mengganggu pengguna.
6. Hanya dalam kasus permintaan yang gagal, sistem akan berbicara. Jangan khawatir tentang hal ini untuk saat ini — kita akan sampai pada titik ini nanti di artikel.

Mari kita lihat beberapa contoh interaksi optimis. Anda mungkin akrab dengan tombol "suka", seperti yang ditemukan di Facebook dan Twitter. Mari kita lihat yang terakhir.

Ini dimulai, cukup jelas, dengan mengklik tombol. Namun perhatikan status visual tombol saat pengguna tidak lagi menekan atau mengarahkan kursor ke tombol. Ini beralih ke status sukses secara instan!

Mari kita lihat apa yang terjadi di tab "Jaringan" pada alat pengembang browser kami saat ini.

Tab "Jaringan" menunjukkan bahwa permintaan server telah dikirim tetapi masih dalam proses. Jumlah penghitung "suka" belum bertambah, tetapi dengan perubahan warna, antarmuka jelas mengkomunikasikan keberhasilan kepada pengguna, bahkan sebelum mendapat tanggapan dari server.

Setelah respons yang berhasil diterima dari server, penghitung diperbarui, tetapi transisinya jauh lebih halus daripada perubahan warna instan. Ini memberi pengguna pengalaman yang mulus dan tanpa gangguan, tanpa menunggu apa pun.

Contoh lain dari interaksi optimis terlihat di Facebook, dengan tombol sukanya sendiri. Skenarionya cukup mirip, kecuali Facebook memperbarui penghitung secara instan, bersama dengan warna sukses tombol, tanpa menunggu respons server.

Satu hal yang perlu diperhatikan di sini. Jika kita melihat waktu respons server, kita akan melihat bahwa itu sedikit di atas 1 detik . Mempertimbangkan bahwa model RAIL merekomendasikan 100 milidetik sebagai waktu respons optimal untuk interaksi sederhana, ini biasanya akan terlalu lama. Namun, pengguna tidak merasakan waktu tunggu dalam kasus ini karena sifat optimis dari interaksi ini. Bagus! Ini adalah contoh lain dari optimasi kinerja psikologis .

Tapi mari kita hadapi itu: Masih ada kemungkinan 1 hingga 3% bahwa server akan mengembalikan kesalahan. Atau mungkin pengguna hanya offline. Atau, lebih mungkin, mungkin server mengembalikan apa yang secara teknis merupakan respons sukses tetapi respons tersebut berisi informasi yang harus diproses lebih lanjut oleh klien. Akibatnya, pengguna tidak akan mendapatkan indikator kegagalan, tetapi kami juga tidak dapat menganggap respons tersebut berhasil. Untuk memahami bagaimana menangani kasus seperti itu, pertama-tama kita harus memahami mengapa dan bagaimana UI yang optimis bekerja secara psikologis.

Psikologi Dibalik UI Optimis

Sejauh ini, saya belum pernah mendengar ada yang mengeluh tentang interaksi optimis yang disebutkan di atas di jejaring sosial utama. Jadi, katakanlah contoh-contoh ini meyakinkan kita bahwa UI yang optimis berhasil. Tetapi mengapa mereka bekerja untuk pengguna? Mereka bekerja hanya karena orang tidak suka menunggu. Itu saja, teman-teman! Anda dapat melompat ke bagian artikel selanjutnya.

Tetapi jika Anda masih membaca, maka Anda mungkin tertarik untuk mengetahui mengapa demikian. Jadi, mari kita menggali lebih dalam dasar psikologis dari pendekatan ini.

UI yang optimis memiliki dua bahan dasar yang layak untuk dianalisis secara psikologis:

• respon cepat terhadap tindakan pengguna;
• penanganan potensi kegagalan di server, di jaringan dan di tempat lain.

Respon Cepat terhadap Tindakan Pengguna

Ketika kita berbicara tentang desain UI yang optimis, kita berbicara tentang waktu respons yang optimal dalam interaksi manusia-komputer. Dan rekomendasi untuk jenis komunikasi ini telah ada sejak tahun 1968. Saat itu, Robert B. Miller menerbitkan karya mani "Response Time in Man-Computer Conversational Transactions" (PDF), di mana ia mendefinisikan sebanyak 17 berbagai jenis tanggapan yang dapat diperoleh pengguna dari komputer. Salah satu jenis yang disebut Miller sebagai "respons untuk mengontrol aktivasi" — penundaan antara penekanan tombol dan umpan balik visual. Bahkan pada tahun 1968, seharusnya tidak melebihi 0,1 hingga 0,2 detik. Ya, model RAIL bukanlah yang pertama merekomendasikan hal ini — saran tersebut telah ada selama sekitar 50 tahun. Namun, Miller mencatat bahwa penundaan umpan balik yang singkat ini mungkin terlalu lambat bagi pengguna yang terampil. Ini berarti, idealnya, pengguna harus mendapatkan pengakuan atas tindakan mereka dalam waktu 100 milidetik . Ini masuk ke dalam kisaran salah satu tindakan bawah sadar tercepat yang dapat dilakukan tubuh manusia — kedipan mata. Untuk alasan ini, interval 100 milidetik biasanya dianggap instan. “Kebanyakan orang berkedip sekitar 15 kali per menit dan kedipan berlangsung rata-rata 100 hingga 150 milidetik,” kata Davina Bristow, dari Institut Neurologi Universitas College London, menambahkan bahwa ini “berarti bahwa secara keseluruhan kita menghabiskan setidaknya 9 hari per tahun untuk berkedip. ”

Karena respons visualnya yang instan (bahkan sebelum permintaan yang sebenarnya selesai), UI yang optimis adalah salah satu contoh teknik penyelesaian awal yang digunakan dalam pengoptimalan kinerja psikologis. Tetapi fakta bahwa orang-orang menyukai antarmuka yang merespons dalam sekejap mata seharusnya tidak mengejutkan sebagian besar dari kita, sungguh. Dan untuk mencapainya juga tidak sulit. Bahkan di masa lalu, kami menonaktifkan tombol secara instan setelah diklik, dan ini biasanya cukup untuk mengakui input pengguna. Tetapi keadaan dinonaktifkan dalam elemen antarmuka berarti menunggu pasif: Pengguna tidak dapat melakukan apa-apa dan tidak memiliki kendali atas prosesnya. Dan ini sangat membuat frustasi bagi pengguna. Itu sebabnya kami melewatkan status nonaktif sama sekali dalam UI yang optimis — kami mengomunikasikan hasil positif alih-alih membuat pengguna menunggu.

Menangani Potensi Kegagalan

Mari masuk ke aspek psikologis menarik kedua dari desain UI yang optimis — penanganan potensi kegagalan. Secara umum, banyak informasi dan artikel tersedia tentang cara menangani kesalahan UI dengan cara terbaik. Namun, sementara kita akan melihat cara menangani kegagalan nanti di artikel ini, yang paling penting dalam UI yang optimis bukanlah bagaimana kita menangani kesalahan, tetapi kapan kita melakukannya.

Manusia secara alami mengatur aktivitas mereka menjadi rumpun, diakhiri dengan penyelesaian tujuan atau sub-tujuan yang ditentukan secara subyektif. Terkadang kita menyebut rumpun ini sebagai "kereta pemikiran", "aliran pemikiran" (PDF) atau hanya "aliran". Keadaan aliran ditandai dengan kenikmatan puncak, fokus energik dan konsentrasi kreatif. Selama aliran, pengguna benar-benar terserap dalam aktivitas. Sebuah tweet oleh Tammy Everts dengan baik menggambarkan ini:

Di web, durasi rumpun aktivitas semacam itu jauh lebih pendek. Mari kita meninjau kembali karya Robert B. Miller sejenak. Jenis respons yang dia kutip meliputi:

• tanggapan atas pertanyaan sederhana atas informasi yang terdaftar;
• tanggapan terhadap pertanyaan kompleks dalam bentuk grafik;
• tanggapan untuk "Sistem, apakah Anda mengerti saya?"

Dia mengikat semua ini ke interval 2 detik yang sama di mana pengguna harus mendapatkan jenis respons yang relevan. Tanpa menggali lebih dalam, kita harus mencatat bahwa interval ini juga tergantung pada memori kerja seseorang (mengacu pada rentang waktu di mana seseorang dapat menyimpan sejumlah informasi di kepala mereka dan, yang lebih penting, dapat memanipulasinya). Bagi kami, sebagai pengembang dan spesialis UX, ini berarti bahwa dalam 2 detik berinteraksi dengan suatu elemen, pengguna akan mengalir dan fokus pada respons yang mereka harapkan. Jika server mengembalikan kesalahan selama interval ini, pengguna masih akan "berdialog" dengan antarmuka, sehingga untuk berbicara. Ini mirip dengan dialog antara dua orang, di mana Anda mengatakan sesuatu dan orang lain sedikit tidak setuju dengan Anda. Bayangkan jika orang lain menghabiskan waktu lama untuk mengangguk setuju (setara dengan indikasi kami tentang status sukses di UI) tetapi akhirnya berkata "tidak" kepada Anda. Canggung, bukan? Jadi, UI yang optimis harus mengomunikasikan kegagalan kepada pengguna dalam 2 detik alur.

Berbekal psikologi tentang cara menangani kegagalan di UI yang optimis, akhirnya mari kita selesaikan 1 hingga 3% dari permintaan yang gagal itu.

Sisi Pesimis Dari Desain UI Optimis

Sejauh ini, komentar paling umum yang saya dengar adalah bahwa desain UI yang optimis adalah semacam pola hitam — curang, jika Anda mau. Artinya, dengan menggunakannya, kami berbohong kepada pengguna kami tentang hasil interaksi mereka. Secara hukum, pengadilan mana pun mungkin akan mendukung poin ini. Tetap saja, saya menganggap teknik ini sebagai prediksi atau harapan. (Ingat definisi "optimis"? Di sinilah kami memberikan ruang untuk bagian "berharap" darinya.) Perbedaan antara "berbohong" dan "memprediksi" adalah bagaimana Anda memperlakukan 1 hingga 3% dari permintaan yang gagal. Mari kita lihat bagaimana tombol "suka" Twitter yang optimis berperilaku offline.

Pertama, sejalan dengan pola UI optimis, tombol beralih ke status sukses tepat setelah diklik — sekali lagi, tanpa pengguna menekan atau mengarahkan kursor ke tombol lagi, persis seperti perilaku tombol saat pengguna online.

Namun karena pengguna sedang offline, permintaan tersebut gagal.

Jadi, sesegera mungkin dalam alur pengguna, kegagalan harus dikomunikasikan. Sekali lagi, 2 detik biasanya durasi aliran seperti itu. Twitter mengomunikasikan ini dengan cara yang paling halus, cukup dengan mengembalikan status tombol.

Pembaca yang teliti di sini mungkin mengatakan bahwa penanganan kegagalan ini dapat diambil satu langkah lebih jauh, dengan benar-benar memberi tahu pengguna bahwa permintaan tidak dapat dikirim atau telah terjadi kesalahan. Ini akan membuat sistem setransparan mungkin. Tapi ada masalah — atau, lebih tepatnya, serangkaian masalah:

• Segala jenis pemberitahuan yang muncul tiba-tiba di layar akan mengubah konteks pengguna, mendorong mereka untuk menganalisis alasan di balik kegagalan, alasan yang mungkin akan ditampilkan dalam pesan kesalahan.
• Seperti halnya pesan kesalahan atau pemberitahuan, yang satu ini harus memandu pengguna dalam konteks baru ini dengan memberikan informasi yang dapat ditindaklanjuti.
• Informasi yang dapat ditindaklanjuti itu akan menetapkan konteks lain.

Oke, sekarang kita semua bisa sepakat bahwa ini menjadi sedikit rumit. Meskipun penanganan kesalahan ini masuk akal untuk, katakanlah, formulir besar di situs web, untuk tindakan sesederhana mengklik tombol suka, itu berlebihan — baik dalam hal pengembangan teknis yang diperlukan dan memori kerja pengguna.

Jadi, ya, kita harus terbuka tentang kegagalan dalam UI yang optimis, dan kita harus mengkomunikasikannya sesegera mungkin agar optimisme kita tidak menjadi kebohongan. Tapi itu harus proporsional dengan konteksnya. Untuk suka yang gagal, mengembalikan tombol ke keadaan semula secara halus sudah cukup — yaitu, kecuali jika pengguna menyukai status orang penting mereka, dalam hal ini hal itu berfungsi lebih baik setiap saat.

Pesimisme Ekstrim

Satu pertanyaan lain mungkin muncul: Apa yang terjadi jika pengguna menutup tab browser tepat setelah mendapatkan indikator sukses tetapi sebelum respons dikembalikan dari server? Kasus yang paling tidak menyenangkan adalah jika pengguna menutup tab bahkan sebelum permintaan dikirim ke server. Tetapi kecuali pengguna sangat gesit atau memiliki kemampuan untuk memperlambat waktu, ini hampir tidak mungkin.

Jika UI optimis diterapkan dengan benar, dan interaksi hanya diterapkan pada elemen yang tidak pernah menunggu lebih dari 2 detik untuk respons server, maka pengguna harus menutup tab browser dalam jendela 2 detik tersebut. Itu tidak terlalu sulit dengan penekanan tombol; namun, seperti yang telah kita lihat, dalam 97 hingga 99% kasus, permintaan akan berhasil, baik tab aktif atau tidak (hanya saja respons tidak akan dikembalikan ke klien).

Jadi, masalah ini mungkin muncul hanya untuk 1 hingga 3% yang mendapatkan kesalahan server. Kemudian lagi, berapa banyak dari mereka yang terburu-buru untuk menutup tab dalam 2 detik? Kecuali mereka dalam kompetisi kecepatan penutupan tab, saya tidak berpikir jumlahnya akan signifikan. Tetapi jika Anda merasa ini relevan dengan proyek khusus Anda dan mungkin memiliki konsekuensi negatif, gunakan beberapa alat untuk menganalisis perilaku pengguna; jika probabilitas skenario seperti itu cukup tinggi, maka batasi interaksi optimis ke elemen non-kritis.

Saya sengaja tidak menyebutkan kasus di mana permintaan tertunda secara artifisial; ini umumnya tidak berada di bawah payung desain UI yang optimis. Selain itu, kami telah menghabiskan lebih dari cukup waktu di sisi pesimistis, jadi mari kita rangkum beberapa poin utama tentang penerapan UI optimis yang baik.

aturan praktis

Saya sangat berharap artikel ini membantu Anda memahami beberapa konsep utama di balik desain UI yang optimis. Mungkin Anda tertarik untuk mencoba pendekatan ini di proyek Anda berikutnya. Jika demikian, berikut adalah beberapa hal yang perlu diingat sebelum Anda mulai:

• Prasyarat untuk semua yang telah kita bicarakan sejauh ini: Pastikan API yang Anda andalkan stabil dan mengembalikan hasil yang dapat diprediksi. Cukup kata.
• Antarmuka harus menangkap potensi kesalahan dan masalah sebelum permintaan dikirim ke server. Lebih baik lagi, hilangkan sepenuhnya apa pun yang dapat menyebabkan kesalahan dari API. Semakin sederhana elemen UI, semakin sederhana untuk membuatnya optimis.
• Terapkan pola optimis ke elemen seperti biner sederhana yang diharapkan tidak lebih dari respons sukses atau gagal. Misalnya, jika klik tombol mengasumsikan respons server seperti “ya”, “tidak”, atau “mungkin” (semuanya mungkin mewakili keberhasilan hingga tingkat yang berbeda), tombol seperti itu akan lebih baik tanpa pola optimis.
• Ketahui waktu respons API Anda. Ini sangat penting. Jika Anda tahu bahwa waktu respons untuk permintaan tertentu tidak pernah kurang dari 2 detik, maka menaburkan optimisme pada API Anda terlebih dahulu mungkin adalah yang terbaik. Seperti yang disebutkan, UI optimis bekerja paling baik untuk waktu respons server kurang dari 2 detik. Melampaui itu dapat menyebabkan hasil yang tidak terduga dan banyak pengguna yang frustrasi. Anggap diri Anda telah diperingatkan.
• UI yang optimis bukan hanya tentang klik tombol. Pendekatan ini dapat diterapkan pada interaksi dan peristiwa yang berbeda selama siklus hidup halaman, termasuk pemuatan halaman. Misalnya, layar kerangka mengikuti ide yang sama: Anda memperkirakan bahwa server akan merespons dengan sukses untuk mengisi tempat penampung untuk ditampilkan kepada pengguna sesegera mungkin.

Desain UI yang optimis bukanlah hal baru di web, juga bukan teknik yang sangat canggih, seperti yang telah kita lihat. Ini hanyalah pendekatan lain, model mental lain, untuk membantu Anda mengelola kinerja yang dirasakan dari produk Anda. Didasarkan pada aspek psikologis interaksi manusia-komputer, desain UI yang optimis, bila digunakan secara cerdas, dapat membantu Anda membangun pengalaman web yang lebih baik dan mulus, sementara penerapannya sangat sedikit. Namun, untuk membuat pola tersebut benar-benar efektif dan menjaga produk kami agar tidak membohongi pengguna, kami harus memahami mekanisme desain UI yang optimis.

Sumber daya

• "Waktu Respons dalam Transaksi Percakapan Manusia-Komputer" (PDF), Robert B. Miller, Konferensi Komputer Bersama Musim Gugur, 1968
• “Memperkenalkan RAIL: Model Kinerja yang Berpusat pada Pengguna,” Paul Irish, Paul Lewis, Smashing Magazine, 2015
• “Tekanan Web Seluler: Dampak Kecepatan Jaringan pada Keterlibatan Emosional dan Persepsi Merek,” Tammy Everts, Blog Radware, 2013
• Aplikasi Arus dalam Pembangunan Manusia dan Pendidikan , Mihaly Csikszentmihalyi, 2014
• “Detail Desain Seluler: Hindari Pemintal,” Luke Wroblewski, 2013
• “Mengapa Kinerja Penting, Bagian 2: Manajemen Persepsi,” Denys Mishunov, Majalah Smashing, 2015