Ditulis oleh Cathy Pearl, Head of Conversation Design Outreach
Ilustrasi oleh Kimberly Harvey

Halo semua! Saya Cathy Pearl, head of conversation design outreach di Google. Saya telah cukup lama mem-build sistem percakapan, mulai dengan IVR (sistem ponsel) dan beralih menuju pengalaman multi-modal. Saya juga penulis buku Designing Voice User Interfaces yang diterbitkan O'Reilly. Hari ini, saya ingin memperkenalkan desainer dan developer ke praktik terbaik desain percakapan kami sehingga Actions akan memberikan pengalaman pengguna sebaik mungkin. Hari ini, saya akan berbicara tentang langkah pertama yang fundamental ketika berpikir tentang membuat Action: menulis contoh dialog.

Jadi, Anda punya ide keren untuk Actions on Google yang ingin Anda build. Anda telah mempelajari Dialogflow, melakukan beberapa codelabs, dan menemukan API yang ingin digunakan. Anda siap memulai coding bukan?
Tidak secepat itu!
Membuat Action harus selalu dimulai dengan merancang sebuah Action. Jangan panik; ini tidak akan memperlambat Anda. Merencanakan desain terlebih dahulu akan menghemat waktu dan menghindarkan Anda dari kesulitan nantinya, dan akan menghasilkan pengalaman yang lebih baik dan berguna.
Dalam postingan ini, saya akan berbicara tentang komponen pertama dan paling penting untuk merancang sistem percakapan yang baik: contoh dialog. Contoh dialog adalah alur percakapan potensial yang mungkin digunakan pengguna saat berbicara dengan Action Anda. Mereka sangat mirip dengan skrip film, dengan pertukaran dialog antara Action Anda dan pengguna. (Dan, seperti skrip film, mereka harus dibacakan dengan keras!) Menulis contoh dialog dilakukan sebelum menulis kode, bahkan sebelum membuat alur.
Ketika saya berbicara dengan orang-orang tentang pentingnya contoh dialog, saya mendapatkan banyak anggukan dan persetujuan. Tetapi ketika saya kembali lagi sesudahnya dan berkata, "Hai, tunjukkan kepadaku contoh dialogmu," Saya sering mendapat senyum malu-malu dan alasan mengapa mereka tidak ditulis. Alasan yang biasa dipakai adalah:
  • "Saya hanya mem-build prototipe, saya bisa melewatkannya."
  • "Saya tidak mengkhawatirkan kata-kata itu sekarang—saya bisa menyempurnakannya nanti."
  • "Bagian yang sulit adalah semua hal yang berhubungan dengan integrasi backend! Menyusun kata-kata adalah bagian yang mudah."
Yang pertama, ada kesalahpahaman bahwa "desain percakapan" (atau desain antarmuka pengguna dengan suara) hanyalah lapisan teratas dari pengalaman: kata-kata, dan mungkin urutan kata-kata, yang akan dilihat/didengar pengguna.
Namun sebenarnya desain percakapan jauh lebih dalam dari hal tersebut. Ia menggerakkan struktur dasar pengalaman, yang meliputi:
  • Panggilan backend apa yang kita lakukan?
  • Apa yang terjadi ketika sesuatu gagal?
  • Data apa yang kita minta dari pengguna?
  • Apa yang kita ketahui tentang pengguna?
  • Kendala teknis apa yang kita alami, apakah dengan teknologi itu atau ekosistem kita sendiri?
Pada akhirnya, semuanya ini bermanifestasi sebagai kata-kata, tentu saja. Tetapi menganggapnya sebagai "hal yang bisa Anda khawatirkan nanti" akan membuat Anda berada di jalur kegagalan ketika tiba waktunya pengguna berinteraksi dengan Action Anda. Misalnya, tanpa contoh dialog, Anda mungkin tidak menyadari bahwa semua prompt yang dimulai dengan kata "Berikutnya", membuatnya terdengar seperti robot dan kaku. Contoh dialog juga akan menunjukkan kepada Anda ketika Anda membutuhkan "perekat" kata seperti "pertama" dan "omong-omong".
Google telah menyusun panduan desain untuk mem-build sistem percakapan. Mereka berisi pengenalan untuk contoh dialog dan mengapa mereka penting:
Contoh dialog akan membuat Anda merasakan secara sekilas dan cepat dari "suara-dan-rasa" interaksi yang sedang Anda rancang. Mereka menyampaikan alur yang benar-benar akan dialami pengguna, tanpa gangguan teknis notasi kode, diagram alur kompleks, masalah pengenalan tata bahasa, dsb.
Dengan menulis contoh dialog, Anda bisa secara informal bereksperimen dengan dan mengevaluasi berbagai strategi desain, seperti cara mempromosikan visibilitas fitur baru atau cara mengonfirmasi permintaan pengguna (misalnya: apakah sebaiknya Anda menggunakan konfirmasi implisit, konfirmasi eksplisit, atau tanpa konfirmasi sama sekali?).
Lihat contoh dialog Action untuk Google I/O 2018 untuk melihat contohnya. (Anda juga bisa melihat kode Action untuk Google I/O 2018.)
Masih tidak yakin apakah Anda benar-benar membutuhkannya? Mari kita dengar dari developer yang mengerjakan Actions, Jessica Dene Earley-Cha, yang mengatakan dalam postingan Medium terbarunya:
Mari kita bahas bagaimana ini di-build. Sebelum coding apa pun dilakukan, kita harus mem-build Desain Percakapan. Saya awalnya melewatkan langkah ini karena saya berpikir bahwa saya bisa mem-build struktur terlebih dahulu dan kemudian mengisi kontennya (seperti mem-build situs web). Namun, strukturnya ternyata terikat dengan konten. Saya menyadarinya ketika saya terbentur dinding penghalang yang saya pikir teknis, tetapi masalah itu ada di sana karena saya tidak memiliki desain.
Dia menunjukkannya dengan jelas bahwa merancang sistem percakapan berbeda dari merancang web. Dengan antarmuka percakapan, konten itu sendiri adalah bagian dari struktur, sehingga desain menjadi semakin penting.
Jadi sekarang setelah Anda (semoga) yakin, mari kita bahas empat kesalahan umum yang bisa dihindari developer dengan menggunakan contoh dialog:

KESALAHAN #1: Membanjiri pengguna dengan terlalu banyak informasi


Misalkan Anda menulis sebuah Action untuk toko sepeda: Action itu bisa membuat janji perbaikan dan layanan, memberitahukan jam buka toko, dan daftar transaksi terbaru. Kita mungkin tergoda untuk mulai mencantumkan opsi sehingga pengguna mengetahui semua yang bisa mereka lakukan. Mari kita lihat seperti apa contoh dialognya menggunakan strategi ini:
PENGGUNA
Hai Google, bicara dengan Alyssa's Bike Shop.
ACTION
Hai! Selamat datang di Alyssa's Bike Shop. Apakah Anda ingin membuat janji perbaikan, membatalkan janji, mengetahui jam buka toko, mengetahui tawaran minggu ini, atau mengetahui tawaran bulan depan?
Jika Anda membaca prompt ini dengan keras kepada orang lain, langsung terlihat jelas bahwa terlalu banyak informasi yang disajikan. Manusia memiliki kapasitas terbatas dalam mendengarkan suara, terutama jika suara itu baru pertama kali mereka dengar.
Akan lebih baik kalau seperti ini:
PENGGUNA
Hai Google, bicara dengan Alyssa's Bike Shop.
ACTION
Hai! Selamat datang di Alyssa's Bike Shop. Saya bisa membantu Anda membuat atau membatalkan janji, memberitahukan jam buka toko, atau memberi tahu penawaran terbaru. Mana yang Anda sukai?
Tips pro: bila menginginkan pengalaman yang lebih baik, tinggalkan opsi "batal" jika pengguna tidak memilikinya.

KESALAHAN #2: Tidak menunjukkan apa yang bisa dilakukan oleh Action Anda


Berikut adalah contoh dialog yang merepresentasikan kesalahan umum dalam banyak pengalaman percakapan. Dalam contoh ini, pengguna kembali ke Action yang sudah mereka coba sebelumnya:
PENGGUNA
Hai Google, bicara dengan Cathy's Astronomy Trivia Game.
ACTION
Ini Cathy's Astronomy Trivia Game. Selamat datang kembali!
PENGGUNA
Uhhh... apa yang bisa saya lakukan??
Ketika kita terlalu tenggelam dalam desain, kita sering lupa bahwa pengguna mungkin datang ke Action tanpa pengetahuan latar belakang yang kita miliki. Apa yang bisa dilakukannya tidak selalu jelas.
Akan lebih baik kalau seperti ini:
PENGGUNA
Hai Google, bicara dengan Cathy's Astronomy Trivia Game.
ACTION
Ini Cathy's Astronomy Trivia Game. Anda bisa bermain sendiri, atau bergabung dengan tim. Mana yang ingin Anda pilih?
PENGGUNA
Uh, saya akan bergabung dengan tim.
Ingat, Anda tidak perlu mencantumkan semua opsi di depan. Sebagai gantinya, cobalah untuk memandu pengguna melewati proses dengan cara yang jelas, dan akhiri dengan ajakan bertindak.

KESALAHAN #3: Tidak mengajak pengguna Anda berbicara


Masalah umum lainnya adalah tidak memperjelas ketika tiba saatnya giliran pengguna berbicara. Sebagai manusia, kita memiliki banyak cara untuk memberi tahu seseorang bahwa sekaranglah saatnya giliran mereka bicara: kata-kata, intonasi, pandangan mata, dan bahasa tubuh. Untuk sesuatu seperti Asisten, sangatlah penting untuk mengakhiri giliran bicara dengan pertanyaan atau instruksi yang jelas. Berikut adalah contoh jawaban Action yang menggantung pengguna:
PENGGUNA
Oke Google, bicara dengan Cool Animal Facts.
ACTION
Selamat Datang di Cool Animal Facts! Hewan apa yang ingin kamu ketahui?
PENGGUNA
Saya suka penguin!
ACTION
Keren, penguin. Apakah Anda ingin mengetahui tentang habitatnya, atau apa yang suka mereka makan?
PENGGUNA
Oh, apa yang suka mereka makan!
ACTION
Penguin bisa memakan hingga 13 pon ikan, kril, dan cumi setiap harinya! Dan tahukah kamu penguin jantan mengerami telur?
PENGGUNA
Oh, oke...
ACTION
Sementara itu, penguin betina pergi mencari ikan.
PENGGUNA
(berpikir) Tunggu dulu.. apa saya harus mengatakan sesuatu?
Dalam contoh ini kita melihat dua masalah. Pertama, Action mengajukan pertanyaan retoris. Ketika pengguna mencoba menjawabnya, Action mengabaikannya dan terus berbicara.
Masalah kedua adalah setelah fakta diberikan, tidak ada yang terjadi. Tidak ada petunjuk apa pun tentang apa yang harus dilakukan pengguna berikutnya.
Akan lebih baik kalau seperti ini:
ACTION
Penguin bisa memakan hingga 13 pon ikan, kril, dan cumi setiap harinya! Omong-omong, penguin jantan menghabiskan waktu mengerami telur, sementara penguin betina pergi mencari ikan. Sekarang, apakah kamu ingin mendengar lebih banyak tentang penguin, atau bertanya tentang hewan lain?
PENGGUNA
Saya sudah selesai, terima kasih.
ACTION
Sama-sama, terima kasih telah berbicara dengan Cool Animal Facts. Selamat tinggal!
Tips pro: Pengguna kerap kali mengharapkan pertanyaan sebelum keluar dan menjawabnya secara eksplisit, seperti mengucapkan "selamat tinggal".
Tips pro 2: Perkuat tata bahasa Anda! Untuk pertanyaan "Apakah kamu ingin mendengar lebih banyak tentang penguin, atau bertanya tentang hewan lain?" bersiaplah untuk menangani jawaban seperti "ya", "tidak", dan nama hewan.

KESALAHAN #4: Membuat satu prompt error untuk semua kondisi


Menangani percakapan dengan apik ketika ada sesuatu yang salah sangatlah penting untuk setiap sistem percakapan. Menulis beberapa prompt error untuk setiap giliran percakapan terasa sangat merepotkan. Menggunakan prompt default "Maaf, saya tidak mengerti" tidak akan membantu pengguna. Sebagai gantinya, hal tersebut harus berdasarkan pada apa yang telah terjadi hingga saat itu dan di mana posisi pengguna saat ini. Untuk mempermudahnya, tuliskan contoh dialog untuk kondisi error, yang akan semakin memperjelas apa yang seharusnya ada dalam prompt.
PENGGUNA
Oke Google, bicara dengan Zombie Quiz.
ACTION
Saatnya Zombie Quiz! Pertanyaan pertama: apa yang harus kamu lakukan jika dikejar zombie: kunci pintu; lari ke bukit, atau menanam di kebun?
PENGGUNA
(berpikir)
ACTION
Maaf, saya tidak mengerti jawabanmu. Mana yang kamu pilih?
PENGGUNA
Apa? Saya lupa pilihannya...
ACTION
Maaf, saya masih kesulitan. Mana yang kamu pilih?
PENGGUNA
Argh!
ACTION
Maaf, jawabannya salah. Pertanyaan kedua...
Penanganan error sensitif-konteks akan membuat pengguna kembali ke jalurnya:
PENGGUNA
Oke Google, bicara dengan Zombie Quiz.
ACTION
Saatnya Zombie Quiz! Pertanyaan pertama: apa yang harus kamu lakukan jika dikejar zombie: kunci pintu; lari ke bukit, atau menanam di kebun?
PENGGUNA
(berpikir)
ACTION
Yang mana yang harus kamu lakukan jika dikejar zombie: kunci pintu; lari ke bukit, atau menanam di kebun?
PENGGUNA
Uhh.. Saya tidak yakin... sebentar...mungkin..
ACTION
Anda juga bisa mengatakan nomor jawabannya, seperti satu, dua, atau tiga. Mana yang kamu pilih?
PENGGUNA
Oh, nomor tiga.
ACTION
Benar!

Checklist pra-penerbangan Anda

Saya tahu Anda sudah tidak sabar ingin segera lepas landas dan mulai menggambar alur dan menulis kode, tetapi luangkan waktu untuk menulis contoh dialog terlebih dahulu. Dalam jangka panjang, ini akan membuat coding Anda lebih mudah, dan meminimalkan jumlah bug yang harus diperbaiki.
Berikut daftar "Kerja" yang perlu diingat ketika menulis contoh dialog:
  • Lihat Panduan Desain Percakapan untuk bantuan selengkapnya
  • Mulai desain Anda dengan menggunakan contoh dialog tertulis/lisan; diagram alur mendetail bisa menyusul belakangan
  • Baca contoh dialog Anda dengan keras!
  • Buat setiap contoh dialog satu lokasi; mereka tidak boleh bercabang
  • Tulis beberapa contoh dialog "lokasi bahagia"
  • Tulis beberapa contoh dialog "lokasi error"
  • Lakukan "pembacaan tabel" dan minta orang yang tidak terbiasa dengan contoh dialog Anda berperan sebagai pengguna
  • Bagikan contoh dialog Anda dengan semua orang yang terlibat dalam build Action, sehingga semua orang berada di halaman yang sama
  • Saat menguji, bandingkan Action yang sedang bekerja dengan contoh dialog, untuk memastikan ia diimplementasikan dengan benar
  • Ulangi, ulangi, ulangi!
Selamat menulis!