Dalam merancang produk yang baik, saya membagi konsep "mudah digunakan" menjadi tiga langkah kunci: visibilitas, penguncian, dan interaksi yang ramah. Pertama, pengguna perlu dapat dengan mudah menemukan fungsi produk. Kedua, sistem harus memberikan respons dalam beberapa ratus milidetik untuk mempertahankan perhatian pengguna. Terakhir, dalam satu atau dua detik setelahnya, jika hasilnya dapat ditampilkan sesuai harapan, pengguna akan bersedia untuk menggunakan dan membagikannya lebih dalam.

Untuk kesalahan yang mungkin terjadi, kita harus memberikan solusi yang jelas, bukan hanya menampilkan informasi kegagalan. Ini bisa termasuk opsi untuk mencoba lagi, pemrosesan tertunda, atau memungkinkan pengguna untuk mengubah parameter. Pendekatan ini secara efektif mengendalikan ketidakpastian dalam batas yang dapat diterima oleh pengguna.

Dalam skenario aplikasi waktu nyata, saya mengamati bahwa ketika desain produk menjadikan peristiwa sebagai sumber sinyal utama dan mengintegrasikan mesin status ke dalam antarmuka pengguna, perasaan cemas pengguna akan berkurang secara signifikan. Demikian pula, ketika tim teknologi menjadikan idempotensi, penghapusan duplikat, pemeriksaan setelah membaca, dan pemulihan otomatis sebagai opsi default, seluruh tim akan lebih percaya diri saat menangani lalu lintas puncak.

Pendekatan yang menekankan pengalaman pengguna ini lebih meyakinkan dibandingkan sekadar mengejar data puncak. Oleh karena itu, saya lebih cenderung untuk bekerja sama dengan tim yang menganggap pengalaman pengguna sebagai "produk publik". Misalnya, mencapai kesepakatan tentang norma kolaborasi dan template komunikasi, serta menggunakan tata bahasa pra-konfirmasi yang seragam untuk mengurangi biaya komunikasi.

Banyak orang beranggapan bahwa respons cepat produk hanyalah masalah teknis, tetapi sebenarnya lebih berkaitan dengan bagaimana menyampaikan informasi kepada pengguna. Jika Anda dapat membuat pengguna memahami tahap mereka saat ini dan apa yang akan terjadi selanjutnya, mereka akan dapat bersabar menunggu waktu pemrosesan satu atau dua detik. Demikian pula, jika pengembang percaya bahwa sistem dapat menangani situasi abnormal secara otomatis dan pulih dengan cepat, mereka akan lebih percaya diri untuk mengoptimalkan jendela pemrosesan batch dan prioritas transaksi.

Sebaliknya, jika kompleksitas sistem langsung diekspos kepada pengguna—seperti ikon pemuatan yang sering muncul, rollback yang tidak terduga, atau situasi yang tidak responsif—bahkan dengan perangkat keras yang paling kuat sekalipun, sulit untuk membangun kembali kepercayaan pengguna. Berdasarkan pengalaman saya, menjadikan "ketentuan" sebagai produk minimal yang layak adalah pilihan yang bijaksana. Dari mesin status hingga bahasa interaksi pengguna, dari template parameter hingga proses ulasan masalah, pertama-tama bangun kerangka dasar ini, kemudian pertimbangkan fitur dan strategi pertumbuhan yang lebih kompleks.

Hanya dengan cara ini, ketika menghadapi puncak permintaan, kita dapat mencapai keadaan "lebih sibuk tetapi teratur", bukan "lebih cepat tetapi kacau". Pendekatan ini tidak hanya dapat meningkatkan kepuasan pengguna, tetapi juga dapat meningkatkan kepercayaan dan efisiensi tim.