Enkripsi yang Mudah Digunakan: Moxie Marlinspike tentang UX dan Keamanan

Saat sistem aman gagal: orang mencari jalan pintas

Sebuah sistem bisa saja "aman di atas kertas" namun tetap tidak aman dalam kehidupan nyata. Banyak desain mengasumsikan perilaku sempurna: semua orang membaca peringatan, mengikuti setiap langkah, dan tak pernah membuat kesalahan. Orang nyata berperilaku sebaliknya ketika mereka sibuk, stres, atau sedang menyelesaikan pekerjaan.

Kesenjangan itulah tempat keamanan runtuh secara diam-diam. Jika membuka pesan terenkripsi butuh lima langkah yang membingungkan, orang tidak menjadi lebih hati-hati. Mereka mencari jalan pintas yang terasa andal, meski melemahkan perlindungan.

Jalan pintas ini sering terlihat tidak berbahaya, tetapi mereka menggagalkan tujuan enkripsi. Orang mengirim tangkapan layar alih-alih menggunakan viewer aman, menempelkan rahasia ke catatan atau chat "sebentar saja", menggunakan kembali kata sandi yang sama antar alat, mematikan fitur yang "selalu mengganggu", atau berbagi akun karena kontrol akses terasa terlalu lambat.

Enkripsi yang mudah digunakan bukan soal mengajari pengguna kriptografi. Ini soal membuat jalur aman menjadi jalur termudah, dengan lebih sedikit keputusan dan lebih sedikit kemungkinan terjebak. Ketika orang bisa menyelesaikan tugas dengan cepat dan percaya diri, mereka tidak butuh jalan pintas.

Pelajaran Moxie Marlinspike: keamanan yang bisa dipakai orang

Karya Moxie Marlinspike terus menunjuk pada satu kebenaran sederhana: keamanan hanya bekerja ketika cocok dengan perilaku manusia nyata. Orang sibuk, mudah terganggu, dan sering berada di bawah tekanan. Jika alur aman menambah gesekan, mereka akan mencari jalan lebih cepat, meski tanpa sadar merusak perlindungan yang ingin Anda berikan.

Itu sebabnya pola lama "pengguna adalah musuh" menghasilkan produk yang buruk. Pendekatan itu memandang perilaku normal sebagai sabotase. Hasilnya desain yang bergantung pada menghardik dan menghukum: aturan kompleks, popup menakutkan, dan pesan "jangan lakukan ini." Pilihan itu melatih orang untuk mengklik terus, berbagi kata sandi, menggunakan kembali kode, atau mematikan fitur. Anda tidak mendapat hasil yang lebih aman, hanya kegagalan yang lebih sunyi.

Pesan terenkripsi menunjukkan ini tanpa masuk ke teknis. Ketika orang harus membandingkan fingerprint panjang, mengelola kunci secara manual, atau menafsirkan peringatan keamanan yang ambigu, banyak yang melewatkan pengecekan. Alat terasa "aman" di atas kertas, tetapi keamanan itu tidak bertahan dalam pemakaian sehari-hari.

Enkripsi yang mudah digunakan bukan enkripsi yang lemah. Ini enkripsi yang dibungkus dalam alur yang bisa diselesaikan orang dengan benar, setiap saat.

Dalam praktik, "mudah digunakan" sering merujuk pada empat sifat:

• Mudah dipahami: aplikasi menjelaskan apa yang terjadi dengan kata-kata sederhana pada saat itu penting.
• Cepat: pilihan yang aman juga merupakan pilihan termudah.
• Memaafkan: kesalahan kecil tidak menyebabkan kerusakan tak bisa diperbaiki.
• Dapat dipulihkan: jika ponsel hilang atau sesi kedaluwarsa, orang bisa mendapatkan kembali akses dengan aman tanpa panik.

Bayangkan seseorang berganti ke ponsel baru. Jika satu-satunya jalur pemulihan adalah "temukan perangkat lama dan ekspor kunci," banyak orang akan mengambil tangkapan layar kode, menyimpan rahasia di catatan, atau kembali ke saluran yang tidak aman. Desain yang mudah digunakan mengantisipasi momen itu dan membuat jalur aman menjadi jelas.

Mengapa kegunaan merusak enkripsi di dunia nyata

Enkripsi biasanya gagal pada momen-momen di mana orang nyata menyentuhnya. Bukan karena mereka tidak suka privasi, tetapi karena "biaya keamanan" muncul ketika mereka sibuk, stres, atau mencoba membantu orang lain.

Titik-titik sakit itu dapat diprediksi: setup pertama kali yang meminta pilihan yang tak mereka mengerti, alur masuk yang menambah langkah tanpa menjelaskan kenapa, berganti perangkat dan tiba-tiba kehilangan akses, mencoba berbagi cepat dan menemui izin yang membingungkan, serta pemulihan setelah perangkat hilang atau lupa kata sandi.

Begitu gesekan tinggi, orang melakukan apa yang berhasil. Mereka menggunakan ulang kata sandi, membiarkan sesi tetap masuk selamanya, mematikan pemeriksaan ekstra, atau memindahkan percakapan "aman" ke aplikasi yang lebih cepat.

Beban kognitif adalah pendorong besar. Banyak produk aman menanyakan hal seperti "Kunci mana yang ingin Anda percayai?" atau "Anda ingin enkripsi lokal atau sisi-server?" Sebagian besar orang tidak punya model mental untuk itu, jadi mereka menebak. Jika UI menambah peringatan menakutkan, tebakan berubah jadi panik.

Beberapa pola peringatan hampir pasti membuat orang mengakali:

• Terlalu banyak opsi tanpa default yang jelas
• Jargon seperti "kunci", "sertifikat", atau "fingerprint" tanpa penjelasan sederhana
• Banner merah yang terdengar bencana tetapi tidak mengatakan langkah selanjutnya
• Prompt yang sering terasa seperti mengganggu

Tekanan waktu memperburuk keadaan. Jika kode kedaluwarsa saat seseorang hendak bergabung rapat, mereka memilih kecepatan daripada keamanan. Tekanan sosial menyelesaikannya: ketika rekan berkata "Kirim saja sekarang," berbagi aman menjadi perlombaan, bukan kebiasaan.

Prinsip desain untuk UX enkripsi (sederhana dan praktis)

Keamanan rusak ketika orang merasa dipaksa menebak. UX enkripsi yang baik menghilangkan tebak-tebakan dengan membuat jalur aman menjadi jalur termudah. Jika pilihan aman membutuhkan membaca halaman bantuan atau bertanya ke IT, banyak pengguna akan memilih yang lain.

Mulailah dengan mengurangi keputusan. Sebagian besar layar harus menawarkan satu opsi yang jelas direkomendasikan dan satu alasan singkat mengapa itu direkomendasikan. Pengaturan lanjutan boleh ada, tetapi tidak muncul di alur utama sampai seseorang benar-benar membutuhkannya.

Buat risiko terlihat, tapi tetap tenang. Ganti peringatan menakutkan dengan hasil nyata yang bisa dibayangkan orang. "Siapa pun dengan tautan ini dapat melihat file" lebih berguna daripada "Berbagi publik tidak aman." Orang bertindak berdasarkan konsekuensi, bukan label.

Rancang untuk kesalahan sebagai kasus normal. Dalam enkripsi yang mudah digunakan, pemulihan adalah bagian dari keamanan, bukan fitur tambahan. Asumsikan seseorang akan berbagi hal yang salah, kehilangan perangkat, atau mengirim ke orang yang keliru.

Sekelompok prinsip singkat bertahan di produk nyata:

• Default ke mode teraman yang masih bekerja untuk kebanyakan pengguna.
• Jelaskan tindakan sensitif dalam satu kalimat, gunakan kata sehari-hari.
• Tambahkan batalkan, cabut akses, dan status jelas seperti "dibagikan dengan 3 orang."
• Ungkapkan detail hanya saat pengguna meminta, atau ketika risiko benar-benar berubah.

Pengungkapan progresif membantu menghindari kelelahan "dinding pengaturan." Tunjukkan hanya yang diperlukan untuk menyelesaikan langkah saat ini, dan tunda sisanya. Ketika detail tambahan penting, sajikan sebagai pilihan dengan konteks, bukan kejutan.

Anggap kebingungan sebagai permukaan serangan. Jika dukungan sering mendengar "Saya tidak tahu ini artinya apa," orang akan mengakali fitur dengan mengirim salinan tidak terenkripsi lewat email, mengambil tangkapan layar, atau menggunakan kata sandi lemah. Perbaikan tercepat biasanya bukan lebih banyak peringatan, melainkan alur yang lebih sederhana dan default yang lebih aman.

Pola otentikasi yang tidak akan dilawan pengguna

Banyak sistem "aman" gagal di pintu depan. Jika masuk terasa menyakitkan, orang menggunakan ulang kata sandi lemah, menonaktifkan perlindungan, atau memilih jalan pintas tercepat. Untuk enkripsi yang mudah digunakan, otentikasi harus sulit untuk dilanggar dan mudah dijalani.

Hapus kata sandi bila memungkinkan. Passkey dan opsi tanpa kata sandi lain sering mengurangi risiko phishing dan memotong beban dukungan kredensial terlupakan. Tetap, Anda perlu fallback untuk momen ketika jalur mudah gagal (perangkat baru, ponsel hilang, akun terkunci). Fallback itu harus dapat dipahami, bukan labirin pertanyaan keamanan.

Sesi harus cukup singkat untuk membatasi kerusakan, tetapi tidak begitu singkat sehingga pengguna harus masuk setiap jam. Jalan tengah yang baik adalah sesi normal untuk pekerjaan rutin, plus re-auth tenang untuk tindakan sensitif. Pengguna menerima re-auth ketika terkait alasan yang jelas.

Gunakan step-up authentication untuk tindakan yang mengubah cerita keamanan, seperti mengekspor data atau kode sumber, mengundang anggota baru, mengubah izin berbagi, mengedit pengaturan admin (penagihan, peran, metode pemulihan), menambahkan perangkat baru, atau menyetujui deployment dan perubahan domain.

Two-factor bisa efektif tanpa berubah jadi hukuman harian. Biarkan orang menandai perangkat tepercaya dan tantang lagi hanya saat risiko berubah (lokasi baru, browser baru, perilaku tidak biasa). Jika Anda harus menantang sering, buat cepat.

Hindari pemaksaan perubahan kata sandi berkala. Itu melatih orang membuat pola yang dapat diprediksi dan menyimpan kata sandi di tempat yang tidak aman. Fokuslah pada deteksi kompromi dan pemulihan: beri notifikasi saat masuk baru, tampilkan sesi aktif, dan biarkan pengguna mencabut akses di satu tempat.

Di platform seperti Koder.ai, itu mungkin berarti menjaga masuk cepat untuk pekerjaan pembangunan normal, tetapi meminta re-auth baru saat seseorang mengekspor kode sumber, mengubah domain kustom, atau mengedit peran tim - momen di mana satu sesi yang dicuri bisa merusak nyata.

Manajemen kunci yang tidak terasa seperti jebakan

Manajemen kunci yang baik punya tiga tujuan yang bisa dimengerti pengguna: menjaga data privat, membiarkan orang yang tepat masuk, dan memastikan Anda bisa kembali masuk saat sesuatu salah. Jika salah satu terasa goyah, orang akan membuat jalan pintas sendiri, seperti menyimpan rahasia di catatan atau berbagi tangkapan layar.

Untuk kebanyakan pengguna, kunci harus ditangani otomatis. Produk bisa menghasilkan kunci, menyimpannya di penyimpanan aman perangkat, dan merotasinya bila perlu. Pengguna tidak boleh diminta menyalin string panjang, menamai file, atau memilih antara format yang membingungkan.

Pengguna ahli dan tim kadang butuh kontrol, jadi wajar menawarkan jalur "lanjutan" untuk ekspor atau kunci yang dikelola admin. Kuncinya bukan memaksa semua orang masuk ke mode itu.

Perubahan perangkat adalah tempat kepercayaan mudah rusak. Buat hasilnya dapat diprediksi sebelum terjadi. Jika ponsel hilang, pengguna harus sudah tahu apakah pemulihan mungkin, apa yang mereka perlukan, dan apa yang akan hilang selamanya. Jangan sembunyikan ini di balik peringatan menakutkan setelah fakta.

Model mental yang membantu: masuk membuktikan siapa Anda, mendekripsi membuka data. Anda bisa menjaga layar sederhana, tapi jangan memberi kesan bahwa kata sandi saja selalu bisa memulihkan segalanya. Jika dekripsi tergantung pada hal kedua (seperti perangkat tepercaya atau kode pemulihan), katakan dengan jelas.

Gunakan nama yang dikenali orang, dan jaga konsistensi. "Kode pemulihan", "perangkat tepercaya", dan "perangkat hilang" lebih jelas daripada campuran istilah teknis yang berubah dari layar ke layar.

Contoh: seseorang mengganti ponsel. Setelah masuk, mereka melihat "Setujui di perangkat tepercaya" atau "Gunakan kode pemulihan." Jika mereka tidak punya keduanya, aplikasi menyatakan: "Kami bisa mereset akun Anda, tetapi data terenkripsi lama tidak dapat dipulihkan." Kebenaran yang jelas mencegah jalan pintas berisiko.

Pola berbagi aman yang tidak bergantung pada peringatan

Berbagi adalah tempat keamanan sering kalah. Jika opsi aman terasa lambat atau membingungkan, orang mengirim tangkapan layar, meneruskan file ke email pribadi, atau menempelkan rahasia ke chat. Enkripsi yang mudah digunakan berarti alur berbagi aman secara default, bukan popup menakutkan.

Mulailah dengan alur undangan, bukan tautan mentah. Undangan bisa terkait ke orang atau tim, dengan peran yang jelas dan tanggal kedaluwarsa. Pertahankan pilihan sederhana dan konkret: "Dapat melihat", "Dapat mengedit", dan "Dapat mengelola akses." Batas waktu harus normal untuk item sensitif, seperti akses kontraktor yang berakhir setelah seminggu.

Buat pencabutan cepat dan jelas. Tempatkan akses di satu tempat, dengan satu tindakan untuk menghapus seseorang, merotasi kunci bila perlu, dan membatalkan sesi lama. Jika orang harus mencari di pengaturan, mereka akan menghindari berbagi aman berikutnya.

Kejelasan mengalahkan peringatan. Gunakan label sederhana yang cocok niat: bagikan dengan akun untuk akses berkelanjutan, bagikan ke perangkat tertentu untuk satu orang di satu mesin, dan bagikan melalui tautan hanya bila benar-benar perlu.

Tambahkan pembatas untuk tindakan berisiko tanpa mengganggu. Jika berbagi ke luar organisasi, minta alasan dan batas waktu. Untuk tautan publik, tunjukkan pratinjau apa yang menjadi publik. Untuk ekspor, tunjukkan apa yang termasuk (data, rahasia, riwayat) dan tawarkan alternatif yang lebih aman.

Terakhir, tunjukkan riwayat aktivitas yang bisa dibaca orang: "Ava membuka ini", "Ben mengubah izin", "Tautan publik dibuat", dengan siapa, apa, dan kapan. Jika Anda membangun aplikasi di Koder.ai, ide yang sama berlaku untuk berbagi deployment, ekspor sumber, atau snapshot: buat akses terlihat, berbatas waktu, dan mudah dibatalkan.

Langkah demi langkah: merancang alur aman yang bisa dipakai

Tulis perjalanan pengguna sebagai cerita sederhana, bukan diagram. Sertakan momen yang biasanya merusak keamanan: pendaftaran, kali pertama seseorang berbagi sesuatu yang sensitif, menambahkan perangkat baru, dan apa yang terjadi setelah ponsel atau laptop hilang. Jika Anda tidak bisa menjelaskan setiap momen dalam satu atau dua kalimat, pengguna juga tidak akan bisa.

Lalu cari titik bypass: tempat di mana orang normal akan mengambil jalan pintas karena jalur aman terasa lambat atau membingungkan. Tangkapan layar kode "sementara", menyalin rahasia ke catatan, menggunakan satu kata sandi di mana-mana, atau mengirim file di luar aplikasi "hanya sekali" adalah semua sinyal. Anggap bypass sebagai masukan tentang desain, bukan kegagalan pengguna.

Urutan pembangunan yang praktis:

• Tentukan default aman terlebih dulu: berbagi prinsip least-privilege, timeout sesi yang masuk akal, dan langkah paling sedikit yang masih melindungi data.
• Rancang alur dengan microcopy bahasa sehari-hari sebelum menyelesaikan UI. Jika perlu jargon seperti "sertifikat", tulis ulang.
• Buat prototipe jalur penuh, termasuk kasus tepi (perangkat baru, offline, jaringan lemah).
• Tambahkan jalur pemulihan lebih awal: pergantian perangkat, pemulihan akun, dan fitur batalkan di tempat yang penting.

Pemulihan dan rollback pantas mendapat perhatian ekstra karena mereka menentukan apakah orang mempercayai sistem. Alur "tidak ada jalan kembali" mendorong pengguna ke jalan pintas yang tidak aman. Jika sebuah share dikirim ke orang yang salah, bisakah dicabut? Jika perangkat hilang, dapatkah akses diputus tanpa mengunci pemilik asli selama berhari-hari?

Jika produk Anda mendukung snapshot dan rollback (seperti Koder.ai), terapkan pola yang sama pada tindakan keamanan: buat langkah yang tidak dapat dibalik jarang dan jelas berlabel, dan buat "batalkan" mudah ketika aman dilakukan.

Akhirnya, uji dengan pengguna non-teknis dan perhatikan di mana mereka terhenti. Jangan tanya, "Apakah Anda akan melakukan X?" Beri tujuan dan diam.

Perhatikan tempat mereka ragu, membaca ulang teks, beralih aplikasi (catatan, kamera, email), menebak salah dan menyalahkan diri, atau meninggalkan jalur aman. Catat momen itu, perbaiki alur, dan uji lagi.

Perangkap UX umum yang membuat pengguna mengakali keamanan

Keamanan paling sering gagal ketika jalur aman terasa membingungkan, lambat, atau berisiko. Orang tidak bangun dengan niat melanggar kebijakan. Mereka hanya ingin menyelesaikan tugas, dan memilih opsi yang terlihat pasti.

Perangkap umum yang mendorong jalan pintas tidak aman:

• Popup menakutkan dan peringatan teknis: Jika setiap aksi memicu modal tentang sertifikat, fingerprint, atau "kunci tidak terverifikasi", pengguna belajar satu kebiasaan: klik terus.
• Pemulihan tersembunyi sampai bencana terjadi: Jika "atur pemulihan" muncul hanya setelah ponsel hilang atau laptop terhapus, itu sudah terlambat.
• Identitas tercampur dengan perangkat: Orang memahami "ini Alex." Mereka kesulitan dengan "ini adalah kunci perangkat Alex dari 14 hari lalu."
• Berbagi aman lebih lambat daripada berbagi tidak aman: Jika mengirim file terenkripsi butuh lima langkah tapi berbagi biasa satu langkah, jalur satu langkah menang saat tekanan.
• Terlalu banyak pengaturan, tanpa default aman: Halaman pengaturan panjang mengundang "coba-coba." Pengguna mengubah opsi sampai peringatan hilang.

Contoh sederhana: seorang manajer perlu membagikan kontrak ke kontraktor baru saat rapat. Jika menambahkan kontraktor mengharuskan memindai kode, membandingkan string panjang, dan membaca peringatan tentang "identitas tidak dikenal," mereka kemungkinan besar akan mengirim file lewat email atau menempelkannya di chat. Alat aman tidak kalah karena kripto lemah. Ia kalah karena terasa tidak dapat diandalkan.

Perbaikan biasanya bukan lebih banyak edukasi. Ini satu jalur jelas dan cepat yang aman secara default, dengan pemulihan dan keputusan kepercayaan ditunjukkan sejak awal, dalam bahasa yang mudah dimengerti.

Daftar periksa cepat untuk UX enkripsi yang mudah digunakan

Perlakukan enkripsi yang mudah digunakan seperti alur pembayaran: ukur waktunya, amati orang nyata menggunakannya, dan anggap mereka akan melewati apa pun yang terasa membingungkan.

Setup dan pemulihan

Pengguna baru harus menyelesaikan setup aman dalam waktu kurang dari dua menit tanpa membaca dokumen atau mencari opsi tersembunyi. Jika alur Anda bergantung pada "simpan kode ini di tempat yang aman" tanpa bantuan, harapkan orang membuat tangkapan layar, kehilangannya, atau mengabaikannya.

Berganti perangkat tidak boleh memicu kepanikan. Jelaskan apa yang akan terjadi sebelum mereka konfirmasi: data apa yang berpindah, apa yang tidak, dan bagaimana membatalkannya. Hindari momen kejutan "Anda tidak akan pernah mendapatkan ini kembali."

Kontrol dan berbagi

Sebelum rilis, periksa beberapa hal dasar:

• Bisakah pengguna melihat semua sesi dan perangkat aktif di satu layar, dengan nama jelas dan waktu terakhir digunakan?
• Bisakah mereka mencabut perangkat atau sesi dengan satu tindakan, dan apakah itu benar-benar menghentikan akses segera?
• Bisakah mereka berbagi dengan orang atau peran tertentu, dan mengubah keputusan nanti?
• Apakah ekspor sensitif memerlukan step-up auth (kata sandi, biometrik, atau setara)?

Setelah ekspor, tinggalkan jejak jelas di riwayat aktivitas: apa yang diekspor, kapan, dan dari perangkat mana. Ini bukan soal menyalahkan. Ini membantu pengguna menangkap kesalahan cepat dan membangun kepercayaan.

Bacakan pesan kesalahan Anda dengan keras. Jika mengandung jargon seperti "kunci tidak valid" atau "handshake gagal," tulis ulang sebagai tindakan: apa yang terjadi, apa artinya untuk pengguna, dan langkah aman berikutnya.

Contoh skenario: tim yang butuh keamanan tapi juga kecepatan

Sebuah agensi tiga orang menangani kontrak klien dan file desain. Mereka bekerja dari laptop di rumah dan ponsel saat bepergian. Mereka juga butuh cara sederhana untuk saling mengirim pesan ketika klien minta perubahan larut malam.

Mereka mencoba setup "aman" yang bagus di atas kertas tapi terasa lambat. Semua orang harus mengetik kata sandi panjang setiap saat, aplikasi sering keluar, dan berbagi folder mengharuskan menyalin string kunci dari satu perangkat ke perangkat lain. Setelah seminggu, jalan pintas muncul: satu kata sandi dipakai di mana-mana, dibuat akun bersama "agar tidak terkunci keluar", dan konten sensitif berakhir di tangkapan layar karena lebih cepat daripada mengekspor dan mengenkripsi ulang file.

Sekarang tulis ulang alur dengan enkripsi yang mudah digunakan.

Alice mengundang Ben dan Priya berdasarkan identitas, dengan nama tim dan klien yang jelas. Setiap orang menerima di perangkat tepercaya. Peran jelas secara default: Priya kontraktor dengan akses terbatas, Ben anggota, Alice admin. Perangkat tepercaya mengurangi login konstan, dan re-auth hanya untuk aksi berisiko tinggi seperti menambah perangkat, mengekspor data, atau mengubah pemulihan.

Pemulihan sesuai kehidupan nyata: setiap anggota menyimpan kode pemulihan sekali saat setup, dengan penjelasan sederhana kapan diperlukan. Berbagi tetap cepat: "Bagikan ke klien" membuat ruang klien terpisah dengan label jelas dan opsi kedaluwarsa.

Sebulan kemudian, Priya keluar. Alice mencabut akses Priya. Sistem mencabut kepercayaan perangkat, mengakhiri sesi aktif, dan merotasi kunci ruang klien yang bisa dibaca Priya. Ben dan Alice mendapat konfirmasi singkat dengan cap waktu sehingga mereka tidak bertanya-tanya apakah itu berhasil.

Detil kecil mencegah jalan pintas: nama yang sesuai cara orang berbicara ("Acme - Kontrak"), default aman (akses paling sedikit terlebih dulu), dan timing yang menghindari gangguan (setup sekali, lalu selesai).

Langkah berikutnya: bangun, uji, dan iterasi tanpa merusak kepercayaan

Pilih satu alur berisiko tinggi dan perbaiki secara menyeluruh. Login, berbagi, dan pemulihan akun adalah tempat orang terjebak, dan tempat mereka paling mungkin menempelkan rahasia ke catatan, memakai ulang kata sandi, atau menonaktifkan perlindungan hanya untuk menyelesaikan tugas.

Ukur di mana rasa sakit itu, bukan di mana Anda kira ada. Lacak langkah yang diulang orang, tempat mereka meninggalkan alur, dan momen mereka membuka bantuan atau mengontak dukungan. Itu adalah hotspot bypass keamanan Anda.

Lalu tulis ulang kata-kata di layar agar sesuai dengan tujuan pengguna. Microcopy yang baik menjelaskan apa yang orang coba lakukan, bukan bagaimana kripto bekerja. "Konfirmasi bahwa ini benar Anda untuk menjaga akun tetap aman" lebih jelas daripada "Verifikasi kunci Anda."

Siklus yang bekerja:

• Rancang ulang satu alur penuh (layar, kesalahan, pemulihan) sebelum pindah ke yang lain.
• Instrumenkan gesekan: pengulangan langkah, putus hubungan, jeda lama, dan permintaan dukungan.
• Ganti peringatan dengan panduan: satu pilihan jelas, satu konsekuensi jelas.
• Uji dengan 5 sampai 7 pengguna non-teknis dan amati apa yang mereka lakukan.

Jika Anda membangun aplikasi dan ingin cara cepat mem-prototype alur ini, Koder.ai dapat membantu Anda mengiterasi otentikasi dan berbagi dalam mode perencanaan, lalu memanfaatkan snapshot dan rollback saat Anda menguji UX yang lebih aman dengan pengguna nyata.