Kami membuat aplikasi suara menggunakan contoh Google Assistant

Setiap penduduk kelima Amerika Serikat memiliki pembicara yang cerdas, dan ini adalah 47 juta orang. Asisten dapat membuat pengingat, daftar tugas, jam alarm, timer, membaca berita, menyalakan musik, podcast, pengiriman pesanan, membeli tiket film dan memanggil taksi. Ini semua adalah "keterampilan" atau "keterampilan" asisten. Mereka juga disebut aplikasi suara. 70.000 aplikasi telah dikembangkan untuk Alexa dan Google Assistant untuk 2018.

Pada 2017, Starbucks meluncurkan fitur pesanan kopi rumahan untuk Amazon Alexa. Selain meningkatkan pesanan pengiriman, semua outlet media yang mungkin menulis tentang hal itu, menciptakan PR keren. Starbucks diikuti oleh Uber, Domino, MacDonald, dan bahkan Tide Laundry Detergent mengembangkan keterampilan Alexa-nya sendiri.

Seperti Starbucks, aplikasi suara memiliki satu atau dua fungsi: memesan kopi, mengatur alarm, atau memanggil kurir. Untuk mendesain sesuatu yang serupa, tidak perlu menjadi perusahaan antarbenua. Gagasan, desain, pengujian, pengembangan, dan rilis mirip dengan tahapan serupa di dunia pengembangan ponsel, tetapi dengan fitur untuk suara. Pavel Guay berbicara secara terperinci tentang prosesnya: mulai dari ide hingga publikasi, dengan contoh-contoh permainan nyata, dengan insets historis dan analisis dunia pengembangan suara.



Tentang pembicara : Pavel Gvay ( pavelgvay ) - mendesain antarmuka suara di studio pengembangan ponsel KODE. Studio sedang mengembangkan aplikasi mobile, misalnya, untuk Utair, Pobeda, RosEuroBank, BlueOrange Bank dan Whiskas, tetapi KODE memiliki divisi yang menangani aplikasi suara untuk Yandex.Alice dan Google Assistant. Pavel berpartisipasi dalam beberapa proyek nyata, bertukar pengalaman dengan pengembang dan desainer di bidang ini, termasuk dari Amerika Serikat, dan berbicara di konferensi tematik. Selain itu, Pavel adalah pendiri startup tortu.io , alat untuk merancang aplikasi suara.

Apa itu aplikasi percakapan

Dalam aplikasi percakapan, saluran interaksi dengan pengguna dibangun melalui percakapan : lisan - dengan pembicara pintar, atau melalui yang tertulis, misalnya, dengan Google Assistant. Selain kolom, perangkat interaksi dapat berupa layar, sehingga aplikasi percakapan juga berbentuk grafik.

Memang benar untuk berbicara aplikasi yang diucapkan , bukan aplikasi suara, tetapi ini adalah istilah yang mapan, dan saya akan menggunakannya juga.

Aplikasi suara memiliki keunggulan penting daripada yang seluler: tidak perlu diunduh dan diinstal. Cukup mengetahui namanya, dan asisten akan memulai semuanya sendiri.

Itu karena tidak ada yang dapat diunduh - baik pengenalan suara maupun logika bisnis - seluruh aplikasi hidup di cloud. Ini adalah keuntungan besar dibandingkan aplikasi seluler.

Sedikit sejarah

Kisah asisten suara dimulai dengan Respon Suara Interaktif , sistem interaktif respons suara yang direkam. Mungkin tidak ada yang mendengar istilah ini, tetapi semua orang datang ketika mereka memanggil dukungan teknis dan mendengar robot: "Tekan 1 untuk sampai ke menu utama. Klik 2 untuk mempelajari lebih lanjut ”- ini adalah sistem IVR . Sebagian, IVR dapat disebut aplikasi suara generasi pertama. Meskipun mereka sudah menjadi bagian dari cerita, mereka dapat mengajari kita sesuatu.

Kebanyakan orang, ketika berinteraksi dengan sistem IVR, mencoba menghubungi operator. Ini karena UX yang buruk ketika interaksi didasarkan pada tim keras, yang hanya merepotkan.

Ini membawa kita pada aturan dasar aplikasi percakapan yang baik.

Aplikasi percakapan yang baik berinteraksi dengan pengguna tidak melalui perintah yang ketat, tetapi melalui percakapan yang hidup dan alami, mirip dengan komunikasi antara orang-orang.

Percakapan dengan aplikasi harus lebih seperti memanggil restoran pizza untuk pesanan daripada berkomunikasi dengan bot obrolan oleh tim. Tidak akan mungkin untuk mencapai fleksibilitas yang sama seperti dalam percakapan di antara orang-orang, tetapi berbicara dengan aplikasi dalam bahasa yang nyaman dan alami cukup.

Ini juga keuntungan dari aplikasi voice over graphic: tidak perlu belajar cara menggunakannya . Nenek saya tidak tahu bagaimana cara pergi ke situs atau memesan pizza melalui aplikasi, tetapi dia dapat memanggil pengiriman melalui kolom. Kita harus menggunakan keunggulan ini dan beradaptasi dengan cara orang berbicara, dan tidak mengajar mereka berbicara dengan aplikasi kita.

Mari kita beralih dari sistem IVR ke masa sekarang - ke asisten virtual.

Asisten virtual

Dunia suara berputar di sekitar asisten virtual: Asisten Google , Amazon Alexa dan Alice .

Semuanya diatur hampir seperti di dunia seluler, hanya alih-alih platform iOS dan Android ada Alice, Google Assistant dan Alexa, alih-alih aplikasi grafis - suara, dengan nama atau nama mereka sendiri, dan setiap asisten memiliki toko aplikasi suaranya sendiri. Sekali lagi, mengatakan "aplikasi" salah, karena setiap platform memiliki istilahnya sendiri: Alice memiliki "keterampilan", Alexa memiliki "keterampilan", dan Google memiliki "tindakan".

Untuk menjalankan keterampilan, saya bertanya kepada asisten: "Alexa, beri tahu Starbucks bahwa saya ingin kopi!", Alexa akan menemukan aplikasi coffee shop di tokonya dan memberinya percakapan. Maka pembicaraan terjadi bukan antara Alex dan pengguna, tetapi antara pengguna dan aplikasi . Banyak yang bingung dan berpikir bahwa asistennya terus berbicara dengan mereka, walaupun aplikasi tersebut memiliki suara yang berbeda.

Seperti inilah tampilan toko aplikasi. Antarmukanya menyerupai App Store dan Google Play.

Langkah pengembangan aplikasi percakapan

Untuk pengguna, aplikasi tidak memiliki bagian grafis - semuanya tampak seperti serangkaian dialog. Secara lahiriah, sepertinya aplikasi itu adalah hal yang sederhana, mudah untuk membuatnya, tetapi tidak. Langkah-langkah pengembangannya sama dengan untuk aplikasi seluler.

• Desain Dalam hal suara, ini bukan rendering layar, tetapi uraian dialog.
• Pengembangan dibagi menjadi dua bagian: pengembangan sistem pemahaman pembicaraan dan penulisan logika.
• Pengujian.
• Publikasi

Dua tahap pertama bersifat spesifik, karena aplikasi bersifat percakapan, dan dua tahap terakhir adalah standar.

Kami akan melewati setiap tahapan menggunakan game Guess the Price , yang diluncurkan di bawah Asisten Google. Mekaniknya sederhana: aplikasi menunjukkan kepada pengguna kartu dengan barang, dan ia harus menebak harganya.

Mari kita mulai menyelam dari tahap pertama: kami memutuskan ide, melakukan analisis, menyadari bahwa pengguna memiliki kebutuhan dan melanjutkan untuk membuat aplikasi suara.

Desain

Tujuan utamanya adalah merancang interaksi antara pengguna dan aplikasi. Di dunia mobile, tahap ini disebut desain. Jika perancang aplikasi grafis menggambar peta layar, tombol, bentuk dan memilih warna, maka perancang VUI mengerjakan dialog antara pengguna dan aplikasi: menentukan berbagai cabang dialog, memikirkan garpu dan skenario samping, memilih opsi frase.

Perancangan dilakukan dalam tiga tahap.

• Contoh dialog.
• Menggambar diagram alur.
• Membuat daftar prompt.

Contoh-contoh Dialog

Hal pertama yang harus dilakukan adalah memahami bagaimana aplikasi akan bekerja. Pemahaman dan visi perlu disiarkan kepada semua orang, terutama jika Anda adalah perusahaan outsourcing, dan Anda harus menjelaskan kepada pelanggan apa yang akhirnya akan ia terima.

Alat yang ampuh untuk membantu adalah contoh dialog: percakapan antara pengguna dan aplikasi tentang peran , seperti dalam permainan.

Contoh dialog untuk game kami.



Aplikasi menyapa, memberi tahu pengguna tentang aturan, menawarkan untuk bermain, dan, jika orang itu setuju, menunjukkan kartu dengan barang sehingga pengguna menebak harganya.

Script membantu untuk dengan cepat memahami bagaimana aplikasi akan bekerja, apa yang bisa dilakukan, tetapi, di samping itu, contoh dialog membantu untuk menghilangkan kesalahan utama di dunia antarmuka suara - bekerja pada skrip yang salah .

Ada aturan sederhana: jika Anda tidak bisa membayangkan bagaimana Anda berbicara skrip dengan orang lain, maka Anda tidak boleh mengerjakannya.

Suara dan grafik sangat berbeda, dan tidak semua yang berfungsi pada antarmuka grafis berfungsi dengan baik pada suara. Hampir setiap aplikasi seluler memiliki pendaftaran, tetapi saya tidak bisa membayangkan bagaimana Anda bisa mendaftar dengan suara? Cara mendikte kata sandi ke kolom pintar: "Huruf kapital, huruf kecil, seperti dolar ..." - dan semua ini dengan lantang. Dan jika saya tidak sendirian, tetapi di tempat kerja? Ini adalah contoh skenario kesalahan. Jika Anda mulai mengembangkan skrip dengan kesalahan, maka akan ada masalah dengannya: Anda tidak akan mengerti cara menjalankannya, pengguna tidak akan mengerti cara menggunakannya.

Contoh dialog akan membantu menemukan momen yang serupa. Untuk menemukan kesalahan dalam skenario, tulis dialog, pilih kolega, duduk berseberangan dan mainkan peran: Anda adalah pengguna, kolega adalah aplikasi. Setelah membaca peran dialog, akan menjadi jelas apakah aplikasi berbunyi atau tidak, dan apakah akan nyaman bagi pengguna.

Masalah seperti itu akan muncul terus-menerus. Jika Anda memiliki pengembangan in-house, maka godaan akan muncul: "Kami sudah memiliki situs web, mari kita ubah itu menjadi suara dan semuanya akan baik-baik saja!" Atau pelanggan akan datang dan berkata: "Ini adalah aplikasi seluler. Lakukan hal yang sama, hanya dengan suara! " Tapi kamu tidak bisa melakukan itu. Anda, sebagai spesialis, harus dengan cepat menemukan skenario yang tidak boleh Anda kerjakan, dan menjelaskan kepada pelanggan mengapa. Contoh dialog akan membantu di sini.

Benar-benar editor teks apa pun yang Anda gunakan cocok untuk membuat resep dialog. Hal utama adalah menulis teks dan membacanya berdasarkan peran.

Bagan arus

Contoh-contoh dialog adalah alat yang kuat, cepat dan murah, tetapi mereka hanya menggambarkan perkembangan acara secara linier, dan percakapan selalu non-linear . Misalnya, dalam game kami “Tebak harga”, pengguna dapat menjawab pertanyaan dengan benar atau salah - ini adalah garpu pertama dalam rangkaian yang akan terjadi nanti.

Agar tidak bingung di semua cabang dialog aplikasi Anda, buat diagram blok - visualisasi dialog. Ini hanya terdiri dari dua elemen:

• Langkah dialog atas nama pengguna.
• Langkah dialog atas nama aplikasi.
  

Diagram alir adalah peta aplikasi kita, tetapi dengan satu properti yang tidak menyenangkan - ia tumbuh dengan kuat, menjadi tidak dapat dibaca dan secara visual tidak dapat dipahami. Di sini, misalnya, adalah tangkapan layar dengan bagian dari diagram alur dari skenario di mana pengguna menebak harganya, dengan beberapa garpu.



Beberapa garpu bukan batasnya, mungkin ada puluhan atau ratusan jumlahnya. Kami bertanya pada diri sendiri, “Apa yang terjadi jika seseorang menjawab dengan benar? Dan jika tidak? Apa yang terjadi jika upaya berakhir? Bagaimana jika barangnya habis? Dan jika dia menebak harganya pasti? Bagaimana jika Internet mati pada langkah ini atau yang lain? " Sebagai hasilnya, kami menciptakan skema besar yang tidak dapat dibaca.

Kami tidak sendirian dalam hal ini. Saya berbicara dengan seorang desainer dari AS yang sedang mengerjakan proyek serius. Proyek ini memiliki IVR, bank, dan keterampilan pada saat yang sama, dan semua ini menggembungkan diagram blok hingga 600 lembar. Tidak ada yang mengerti skema sampai akhir, dan ketika perancang melihatnya, dia hanya ngeri.

Saya punya saran tentang cara mencegah ini. Skema akan selalu tumbuh, tetapi jangan pernah mencoba membangun satu diagram blok besar untuk seluruh aplikasi - itu akan rumit, dan tidak seorang pun kecuali Anda akan memahaminya. Pergi dari kebalikannya dan pecahkan diagram menjadi bagian-bagian logis : skenario terpisah menebak harga, skenario bantuan terpisah. Bagi skenario ini menjadi sub-skenario sesuai kebutuhan. Hasilnya bukan satu peta besar dengan koneksi yang tidak dapat dipahami, tetapi banyak sirkuit kecil, mudah dibaca, dan terhubung dengan baik di mana setiap orang merasa nyaman untuk bernavigasi.

Untuk diagram blok, alat apa pun cocok. Saya dulu menggunakan RealtimeBoard , dan ada juga Draw.io dan bahkan XMind . Akibatnya, saya mengembangkan sendiri, karena hanya lebih nyaman. Dalam gambar saja disajikan. Alat ini juga mendukung sub-skrip.

daftar prompt

Artefak terakhir yang akan kita bentuk pada tahap desain. Daftar cepat adalah daftar semua frasa yang mungkin diucapkan aplikasi.

Ada satu kehalusan. Percakapan dengan aplikasi harus fleksibel dan mirip dengan percakapan dengan seseorang. Ini berarti tidak hanya kemampuan untuk melewati cabang-cabang yang berbeda, yang kami lakukan pada tahap diagram alur, tetapi juga suara percakapan secara keseluruhan. Seseorang tidak akan pernah menjawab dengan frasa yang sama jika Anda menanyakan pertanyaan yang sama. Jawabannya akan selalu diparafrasekan dan terdengar berbeda. Aplikasi harus melakukan hal yang sama, jadi untuk setiap langkah dialog atas nama aplikasi, tulis bukan satu pilihan jawaban, tetapi setidaknya lima.



Menurut lembar petunjuknya, ada hal penting lainnya. Komunikasi harus tidak hanya hidup dan fleksibel, tetapi juga konsisten dalam hal gaya bicara dan perasaan umum interaksi pengguna dengan aplikasi Anda. Untuk ini, desainer menggunakan teknik yang sangat baik - menciptakan karakter . Ketika saya menelepon teman saya, saya tidak melihatnya, tetapi secara tidak sadar saya membayangkan teman bicara saya. Pengguna memiliki hal yang sama ketika berkomunikasi dengan speaker pintar. Ini disebut pareidalia .

Pada tahap lembar prompt, Anda membuat karakter atas nama siapa aplikasi akan berbicara. Pengguna Anda akan mengaitkan merek dan aplikasi dengan karakter - itu bisa menjadi orang nyata atau fiksi. Berusahalah untuk penampilan, biografi, karakter, dan humornya, tetapi jika tidak ada waktu, maka cukup bawa semua frasa Anda dalam lembar petunjuk ke gaya tunggal. Jika Anda mulai menghubungi pengguna di "Anda", maka jangan hubungi tempat lain di "Anda". Jika Anda memiliki gaya komunikasi informal, maka pertahankan di mana-mana.

Biasanya, Excel atau Google spreadsheet digunakan untuk membuat lembar prompt, tetapi dengan mereka ada kerugian sementara yang sangat besar dalam pekerjaan rutin. Diagram alir dan tablet dengan frasa sama sekali tidak terhubung satu sama lain, setiap perubahan harus ditransfer secara manual, yang diterjemahkan ke dalam rutin yang konstan dan panjang.

Saya tidak menggunakan Excel, tetapi alat saya, karena di dalamnya semua frasa ditulis langsung di diagram alur, mereka ditugaskan untuk langkah dialog. Ini menghilangkan rutinitas.

Dalam mendesain, kami mengerjakan setiap skenario: kami menulis contoh dialog, menemukan cabang samping, kesalahan, menutupinya dengan diagram alur, dan kemudian mengerjakan gaya bicara dan frasa.

Tampaknya sekarang semuanya sudah siap dan Anda dapat memberikan tugas kepada pengembang dan mendapatkan kode, tetapi masih ada satu tahap pengujian yang lebih penting. Kami harus memastikan bahwa sebagai perancang kami melakukan semuanya dengan benar, bahwa aplikasi akan bekerja seperti yang kami inginkan, bahwa semua frasa memiliki gaya yang sama, bahwa kami telah membahas semua cabang samping dan memproses semua kesalahan.

Pengujian

Pengujian pada tahap awal ini sangat penting untuk aplikasi suara. Dalam dunia antarmuka grafis, pengguna dibatasi oleh apa yang digambar perancang: ia tidak akan melampaui layar, tidak akan menemukan tombol yang tidak ada, dan hanya akan mengklik apa yang ...

Dalam dunia suara, ini tidak begitu: pengguna bebas untuk mengatakan apa pun, dan Anda tidak tahu bagaimana dia akan mulai bekerja dengan aplikasi Anda sampai Anda melihatnya. Lebih baik melakukan ini pada tahap awal desain dan mempersiapkan hal-hal yang tidak terduga sampai pengembangan yang mahal telah dimulai.



Aplikasi diuji menggunakan metodologi Wizard of Oz . Ini digunakan dalam aplikasi grafis, tetapi lebih jarang, dan dalam suara itu harus dimiliki. Ini adalah metode ketika pengguna berinteraksi dengan sistem, dengan asumsi bahwa itu ada dan bekerja sendiri, tetapi Anda mengontrol seluruh proses.

Pengujian dilakukan menggunakan prototipe interaktif. Biasanya, perancang harus meminta pengembang untuk membuat prototipe, tetapi secara pribadi saya menggunakan alat saya, karena semuanya dilakukan dalam satu klik di dalamnya dan tidak perlu menunggu siapa pun. Kami juga membutuhkan pengguna. Kami memanggil seseorang yang tidak terlibat dalam pengembangan, tidak tahu apa-apa tentang aplikasi dan, idealnya, termasuk dalam audiens target Anda. Anda mengundang seseorang, menjelaskan jenis aplikasi apa itu, bagaimana menggunakannya, menanamnya di ruangan, menyalakan prototipe interaktif dan pengguna mulai berbicara dengannya. Prototipe tidak mengenali ucapan, dan Anda mendengar apa yang dikatakan orang itu dan memilih opsi jawaban yang digunakan aplikasi merespons setiap frasa.

Jika pengguna tidak melihat layar, maka tampak baginya bahwa aplikasi bekerja dengan sendirinya, tetapi Anda mengontrol prosesnya. Ini sedang menguji Wizard of Oz. Dengan itu, Anda tidak hanya akan mendengar bagaimana aplikasi itu terdengar, tetapi juga melihat bagaimana orang menggunakannya. Saya jamin Anda akan menemukan banyak skenario yang tidak terungkap.

Ketika saya menguji permainan, saya menelepon teman saya. Dia mulai menebak harganya dan mengatakan bahwa semacam salep bernilai "gubuk lima." Saya tidak mengharapkan kata seperti itu, saya pikir akan ada opsi 500 rubel, seribu rubel, dan bukan "pondok lima" atau "memotong". Ini adalah hal sepele yang terungkap selama pengujian. Orang-orang menggunakan aplikasi secara berbeda dari yang Anda bayangkan, dan pengujian mengungkapkan hal-hal sepele dan skenario yang tidak berlaku.

Tes banyak dan untuk waktu yang lama sebelum pengembangan, sampai Anda yakin bahwa aplikasi itu berfungsi dan pengguna berinteraksi dengannya seperti yang Anda harapkan.

Pada tahap ini, fase desain berakhir dan kami memiliki contoh dialog, diagram blok adalah deskripsi logis dari aplikasi, dan daftar prompt adalah apa yang dikatakan aplikasi. Kami akan memberikan semua ini kepada pengembang. Sebelum saya memberi tahu Anda bagaimana pengembang membuat aplikasi, saya akan berbagi kiat desain.

Kiat

Gunakan bahasa markup SSML - seperti HTML, hanya untuk ucapan. SSML memungkinkan Anda untuk berhenti sebentar, mengatur tingkat empati, stres, mendaftarkan apa yang harus dibaca dan mengeja.



Ucapan berlabel terdengar jauh lebih baik daripada robot, dan semakin baik aplikasinya terdengar, semakin menyenangkan untuk digunakan. Jadi gunakan SSML - tidak rumit.

Pikirkan tentang saat-saat di mana pengguna beralih ke aplikasi Anda untuk meminta bantuan. Untuk suara, ini sangat penting. Seseorang dapat berbicara dengan pembicara sendirian di ruangan, atau dia bisa naik bus dan berbicara dengan smartphone. Ini adalah dua skenario perilaku yang berbeda secara mendasar untuk aplikasi suara. Kami memiliki situasi yang serupa dengan aplikasi perbankan. Ada skrip dalam aplikasi ketika pengguna menerima informasi tentang akun, dan ini adalah informasi pribadi. Saya pikir - jika seseorang berbicara di rumah, maka semuanya baik-baik saja, tetapi jika dia bepergian dengan bus dan aplikasi mulai menyuarakan keseimbangan kartu dengan keras - itu akan jelek.

Memikirkan momen seperti itu, Anda dapat menentukan bahwa jika pengguna berbicara dengan smartphone, bahkan dengan suara, maka lebih baik untuk tidak membaca informasi pribadi dengan keras, tetapi untuk menunjukkannya di layar.

Gunakan desain multimoda.

Ini adalah desain untuk permukaan dan platform yang berbeda. Perangkat suara memiliki tekstur yang sangat berbeda. Di dunia seluler, perangkat hanya berbeda dalam platform dan ukuran - faktor bentuk layar. Dengan suara, semuanya berbeda. Misalnya, kolom tidak memiliki layar sama sekali - hanya suara. Ponsel cerdas memiliki layar, dan Anda dapat mengetuknya dengan jari Anda. TV memiliki layar besar, tetapi tidak berguna untuk menyentuhnya. Pikirkan tentang bagaimana aplikasi Anda akan bekerja pada masing-masing permukaan ini.

Misalnya, pengguna melakukan pembelian dan kami ingin menunjukkan cek. Membaca check out dengan keras adalah ide yang buruk, karena ada banyak informasi dan tidak ada yang akan mengingatnya, karena informasi suara dianggap sulit dan sulit.



, , , , , . , .

. , — , . , , .

. , Amazon Alexa, Google Assistant.



, . - , .

• — intent , — , : , , webhook , . - webhook, , API.
• .

Dialogflow , , , .

— Natural Language Understanding — NLU.

Dialogflow

Dialogflow, , , . Dialogflow : — Google Assistant, -, Amazon Alexa Telegram . — API. , .

Dialogflow.

• Agent — , , .
• Intents — .
• Entities — .
• Contexts — , .

, — Intents.

Intents

, , . . , : « », «, ?», « — » - . , Intent , , .

10 . , Dialogflow , 10 , , . , , .

Intent . Dialogflow , , webhook. , — : , .

«» — . , Google Assistant , , , . Google Assistant , .

Entities

Intent , - . — , , — Entities . , , , , . : .



. « », . , — . , :

— ?
— !

Dialogflow re-prompt — , , . . - : « , ...»

— Entities. Dialogflow — , , . , , , , . Dialogflow — . ^ , , , . , , . : «», Dialogflow , «»

Context

: context — , . , : « ?» , . , . , : « », . Google , — .



context — « — » , . Intent context , -, . context . : , 5 , .

context — : , . , Intent, context , Intent. .



webhook. Dialogflow , JS. Google Assistant webhook — , 5 , fallback. , — 1,5 3 .

, webhook , QA, .

, , .

, . . , .

:

• . ., . , « », , .
• , , .

Google Assistant , — «, Google, ...». , , : «, Google, Uber» — , . , : «, Google, Uber !» , .

, . , — . , « » , « » . , «» «» Google Assistant. , , .

, . Google Assistant , , .

.

• Alpha — 20 .
• Beta — 200 .
• Production- — store. Production, . Google , , . , . , , .
  

, , , — .

. , , — , , .

. , Dialogflow :

• — .
• — , , , .

, . - : «4 ». «» , «» — .



, , .

. , . , , - .

-
- .
Slack- Amazon Alexa
Slack- Google Assistant
Google Assistant
Amazon Alexa
«Designing VUI» Cathy Pearl
«VUX best practices, Voicebot»
Medium
Google Assistant
Amazon Alexa
.
,

: Twitter Linkedin , Medium .

AppsConf 2019 , 22 23 . , , .

— YouTube- .

AppsConf, !