Blog Metlivi

Apa yang Membuat Obrolan Teks AI Terasa Alami: Kecepatan Mengetik atau Ritme Interaksi?

Untuk obrolan teks AI, interaksi yang meyakinkan tidak terlalu bergantung pada seberapa cepat huruf muncul, melainkan pada apakah setiap tahapan percakapan masuk akal: pengguna dapat mengetahui sistem telah menerima pesan, balasan tiba dalam bagian-bagian yang mudah dibaca, serta penyelesaian atau gangguan tersampaikan dengan jelas. Animasi mengetik saja tidak dapat menciptakan ritme tersebut. Rancanglah antarmuka dengan berpusat pada umpan balik yang bermanfaat dan kendali pengguna, serta perlakukan simulasi mengetik sebagai efek visual opsional, bukan sebagai bukti adanya manusia di sisi lain.

30 September 20267 min readMembaca, seni, dan budayaOleh Metlivi Editorial Team
Bagian 1

Animasi mengetik adalah sinyal, bukan percakapan itu sendiri

Tanda elipsis yang berkedip atau label “mengetik” dapat menunjukkan bahwa balasan sedang disiapkan. Panduan desain obrolan Visa menjelaskan indikator pengetikan sebagai cara untuk memberi sinyal respons aktif, dan membedakannya dari indikator progres yang digunakan selama proses AI generatif berjalan. Perbedaan itu sangat berguna: “mengetik” memberi kesan seseorang sedang menyusun pesan; “memproses” atau “menghasilkan” menggambarkan proses sistem secara lebih lugas. Untuk asisten AI, pilihlah kata-kata yang secara akurat menyebutkan statusnya alih-alih mengisyaratkan identitas manusia atau pola mengetik manusia. (Visa Product Design System: Chat)

Jeda waktu tetap yang diikuti oleh simulasi pemunculan karakter per karakter mungkin membuat antarmuka terlihat seperti aplikasi perpesanan, tetapi hal itu tidak memberi tahu pengguna apakah permintaan telah diterima, apakah sistem masih memproses, atau apakah respons sudah selesai. Hal ini juga dapat membuat jawaban yang singkat dan sederhana terasa tertunda tanpa alasan. Pertanyaan desain yang berguna bukanlah “Berapa milidetik yang diperlukan untuk setiap karakter?” melainkan “Apa yang perlu diketahui pengguna saat menunggu, membaca, atau memutuskan apa yang harus dilakukan selanjutnya?”

Bagian 2

Mulailah dengan tugas pengguna dan konsekuensi dari menunggu

Pertama, kenali beban kerja di balik pesan tersebut. Jawaban singkat untuk pertanyaan sederhana mungkin hanya memerlukan tanda pemrosesan cepat dan balasan lengkap. Respons yang memerlukan operasi lebih lama, seperti memeriksa dokumen yang diberikan, dapat terbantu dengan status yang lebih deskriptif dan perkiraan waktu yang jujur jika tersedia. Jika durasinya tidak diketahui, gunakan indikator yang tidak terbatas (indeterminate) dan jangan mengarang hitungan mundur. Panduan progres dari Apple membedakan antara progres terukur (determinate), di mana durasi atau kemajuan dapat diukur, dari aktivitas tidak terukur (indeterminate), serta menyarankan umpan balik progres yang akurat dan cara untuk menghentikan proses jika memungkinkan. (Apple Human Interface Guidelines: Progress Indicators)

Urutan yang praktis adalah mengonfirmasi penerimaan, menunjukkan bahwa proses sedang berjalan jika ada jeda tunggu yang terasa, lalu menyajikan jawaban saat sudah siap. Ini adalah status yang terpisah, meskipun antarmuka yang ringkas menggabungkan beberapa di antaranya. Status “Terkirim” mengonfirmasi tindakan pengguna; tanda aktivitas menyampaikan proses tunggu; pesan yang dihasilkan memuat hasilnya. Hindari membiarkan indikator tetap berada di layar setelah pekerjaan selesai, atau menghapusnya tanpa memperjelas bahwa jawaban telah tuntas. Jika permintaan gagal, jelaskan apa yang terjadi dan tawarkan langkah tindak lanjut yang dapat dilakukan, seperti mencoba lagi. Panduan obrolan Visa juga merekomendasikan pesan kesalahan yang jelas dan opsi kirim ulang saat pesan gagal dikirim. (Visa Product Design System: Chat)

Bagian 3

Gunakan pemotongan pesan (chunks) untuk membantu orang membaca

Menampilkan kata atau frasa secara bertahap (streaming) saat tersedia dapat membuat respons terlihat sebelum seluruh proses pembuatan teks selesai. Ini berbeda dengan menganimasikan jawaban yang sudah jadi menggunakan kecepatan mengetik buatan: streaming mencerminkan tibanya keluaran secara bertahap, sedangkan animasi pemunculan teks dapat menambah penundaan setelah teks tersebut sebenarnya sudah ada. Referensi streaming OpenAI Responses mendokumentasikan serangkaian peristiwa (events) untuk pembuatan respons, pembaruan teks, dan teks yang selesai. Peristiwa-peristiwa tersebut menggambarkan perbedaan antarmuka yang penting antara respons yang sedang berlangsung dan teks yang sudah selesai; mereka tidak memaksakan kecepatan tampilan atau ukuran potongan teks yang seragam. (OpenAI API Reference: Streaming events)

Untuk percakapan yang nyaman dibaca, tampilkan potongan kalimat atau frasa yang koheren jika memungkinkan, pertahankan jeda paragraf, dan hindari membuat tata letak pesan melompat-lompat saat konten baru muncul. Ini adalah rekomendasi desain yang berorientasi pada kemudahan membaca, bukan aturan baku yang kaku tentang panjang potongan teks yang ideal. Jika jawabannya panjang, kalimat pembuka yang singkat atau bagian bermanfaat pertama dapat ditampilkan lebih awal, lalu bagian sisanya menyusul dalam tata letak yang stabil. Jangan memecah teks terlalu agresif hingga pembaca melihat rentetan fragmen yang berkedip cepat, atau menahan jawaban lengkap yang sudah tersedia hanya demi meniru cara mengetik manusia. Pastikan kontrol seperti hentikan atau buat ulang mudah ditemukan jika antarmuka mendukungnya.

Bagian 4

Buat umpan balik penantian akurat dan proporsional

Ketika suatu proses memakan waktu, indikator harus menggambarkan apa yang benar-benar diketahui oleh sistem. Gunakan bilah terukur atau persentase hanya jika progres dapat diukur secara bermakna. Jika tidak, indikator aktivitas sederhana sudah cukup untuk menyampaikan bahwa pekerjaan terus berjalan tanpa berpura-pura memprediksi waktu penyelesaian. Apple merekomendasikan agar laporan progres tetap akurat, menjelaskan jika terjadi kemacetan proses, dan memungkinkan orang menghentikan pemrosesan jika memungkinkan. Prinsip yang sama berlaku dalam obrolan: jika proses macet, ubah status “memproses” yang beranimasi tanpa henti menjadi pesan yang bermanfaat seperti “Respons terhenti. Coba lagi.”

Hindari mengubah teks status berulang kali hanya untuk menciptakan kesan adanya aktivitas. Urutan seperti “Sedang berpikir…”, “Masih berpikir…”, dan “Hampir selesai…” hanya bermanfaat jika setiap pesan mencerminkan status yang nyata dan membantu pengguna menentukan langkah selanjutnya. Jika tidak, satu status yang jelas akan lebih minim distraksi. Khususnya, jangan katakan “hampir selesai” kecuali sistem memiliki dasar yang andal untuk pernyataan tersebut. Tanda yang singkat dan jujur bisa terasa lebih penuh pertimbangan daripada animasi yang ramai tetapi tidak informatif.

Bagian 5

Perlakukan penyelesaian sebagai status nyata

Pengguna perlu tahu kapan respons telah selesai, terutama jika mereka ingin menyalinnya, mengajukan pertanyaan lanjutan, atau menyela keluaran yang sedang berjalan. Hapus atau ganti tanda aktivitas saat proses selesai, dan pastikan pesan akhir tetap stabil sebagai pesan yang dapat dibaca dan diajak berinteraksi oleh pengguna. Jika keluaran terhenti dalam kondisi tidak lengkap atau dibatalkan, komunikasikan status tersebut daripada menampilkan jawaban parsial seolah-olah sudah selesai. Referensi API streaming membedakan pembaruan teks dari peristiwa penyelesaian, dan mencatat bahwa peristiwa penyelesaian juga dapat menyertai respons yang terputus atau tidak lengkap; oleh karena itu, antarmuka harus mencerminkan hasil akhir yang sebenarnya diterima. (OpenAI API Reference: Streaming events)

Penyelesaian juga harus dapat dirasakan oleh orang yang tidak melihat animasi visual. Panduan W3C menjelaskan bahwa pesan status dapat mengomunikasikan penantian, progres, keberhasilan, atau kesalahan tanpa memindahkan fokus pengguna, dan bahwa pembaruan ini harus dapat diidentifikasi secara terprogram untuk teknologi asistif. Panduan live-region MDN menjelaskan pemberitahuan yang sopan (polite announcements) untuk pembaruan penting yang tidak mendesak, serta mengingatkan bahwa pengumuman tegas (assertive) yang terlalu sering dapat mengganggu pengguna. Dalam praktiknya, umumkan perubahan status yang bermakna—seperti respons yang telah tersedia atau permintaan yang gagal—tanpa menjadikan setiap token teks atau bingkai animasi sebagai pembaruan yang dibacakan suara. (W3C WAI: Understanding Status Messages; MDN: ARIA live regions)

Bagian 6

Beri pengguna kendali atas ritme interaksi

Interaksi yang terasa alami memberikan ruang bagi pengguna untuk bertindak. Izinkan orang menghentikan respons jika memungkinkan, dan jelaskan apakah tindakan berhenti tersebut mengakhiri pembuatan teks atau hanya menjeda tampilannya. Jika respons ditampilkan secara streaming, jaga agar teks yang terlihat tetap mudah dibaca dan biarkan pengguna terus menavigasi percakapan. Jika jawaban lengkap sudah siap dengan cepat, hindari memaksakan jeda teatrikal; jika pemrosesan nyata membutuhkan waktu lebih lama, jelaskan bahwa pekerjaan masih berlangsung. Tujuannya adalah mendukung ritme pengguna, bukan mengarahkan mereka untuk menunggu lebih lama.

Hal ini juga membantu membedakan gaya percakapan antarmuka dari klaim palsu tentang siapa atau apa yang merespons. Sistem AI dapat menggunakan pilihan kata yang ringkas, ramah, dan penyajian berbentuk pesan sembari tetap mengidentifikasi dirinya secara akurat. “Menyiapkan respons” menggambarkan aktivitas sistem; “Saya sedang mengetik” dapat dipahami sebagai seseorang yang sedang mengetik. Pilihlah label dengan mempertimbangkan kemungkinan interpretasi pengguna, terutama pada produk di mana pengguna mungkin salah mengira indikator tersebut berasal dari partisipan manusia.

Bagian 7

Aturan keputusan sederhana untuk memilih pola

Gunakan animasi bergaya mengetik hanya jika hal itu menambahkan tanda yang jelas dan singkat serta tidak mengesankan adanya operator manusia. Gunakan indikator progres ketika sistem melakukan pekerjaan yang melampaui tindakan langsung pengguna. Tampilkan potongan pesan yang mudah dibaca secara bertahap saat menampilkan hasil awal membantu tugas tersebut, dan tandai penyelesaian saat respons benar-benar telah selesai. Tambahkan kontrol ketika interupsi memungkinkan dan berguna. Untuk setiap perubahan status yang penting, pastikan hal itu dapat dirasakan tanpa hanya bergantung pada gerakan atau warna semata.

Evaluasi desain cepat dapat mengajukan empat pertanyaan: Apa yang dipicu oleh tindakan pengguna? Apa status sistem yang sebenarnya? Apa yang dapat dilakukan pengguna saat menunggu? Bagaimana pengguna tahu hasilnya sudah selesai—atau bahwa ada masalah? Jika jawabannya jelas, interaksi dapat terasa responsif tanpa memalsukan ritme mengetik manusia. Kualitas interaksi berasal dari umpan balik yang terkoordinasi, penyampaian yang mudah dibaca, dan kendali, bukan dari kecepatan titik-titik yang bergerak.

Bacaan terkait

Lanjutkan topik ini