※本記事はBotの設計や開発に興味ある方向けの記事です。イベント当日話した内容を掻い摘んで文字におこしています。
イベント概要
「LINE Developer Meetup」とは、LINEが主催している開発者向けの勉強会です。
以前東京で開催された同イベントのLTに参加したことがキッカケで、主催の方から声をかけて頂き、話すことになりました。
LINEが提供しているAPIは こちら
![](https://blog.n11sh1.com/content/images/2019/05/8dc37b17-a440-4930-bbac-c6def464e4c6.png)
イベント詳細
https://line.connpass.com/event/95135/
発表スライド
登壇内容
![](https://blog.n11sh1.com/content/images/2019/05/4550d009-9605-4635-92de-f19ca7ba14e2.jpeg)
これまで僕自身のBot開発経験やいろいろなBotを触ってみての実体験 + Bot設計に関する書籍をもとに、「BotにおけるUI/UX設計ノウハウ」について話しました。
<関連書籍>
![](https://blog.n11sh1.com/content/images/2019/05/dcd144fb-006c-42f8-a3be-81c4e34eccfc.jpeg)
書籍からの引用ではありますが、Bot(というよりスマートスピーカーも含めた会話型UI)は「"transparent" user experience(透明なUX)」と表現されています。
確かに、単純なテキストメッセージのやり取りだけだと印象に残らないですよね。(対人でも顔文字や絵文字、スタンプで感情表現しますし)
そして印象に残らないと、いざという時に「あのBot使おう!」ともなりませんよね。
ということで、
印象に残る&使ってもらうために、BotのUI/UX設計は必要。
と定義しておきます。
![](https://blog.n11sh1.com/content/images/2019/05/4d0d6e67-c715-402a-9c7c-028c2fcc22c1.jpeg)
どんな設計でも同じだとは思うのですが、「全体像を捉える」→「細部に目を向ける」が鉄則の流れです。
Botにおける「全体像を捉える」とは
一つは、Botをのせるプラットフォームの特徴を知ることです。 LINEとSlackを比べても、プラットフォームの差はかなり違います。
- 利用ユーザー(LINE=オープンでC向け、Slack=クローズドでB向け)
- 利用デバイス(LINE=スマホ大多数、Slack=PC>スマホ)
- 提供API(独自UI含む)
もう一つは、Botの目的&機能を明確にすることです。 スタートアップの世界では、MVP: Minimal Viable Product(顧客に価値を提供できる最小限の製品)と呼ばれることも多いですが、これを見つける感覚に近いと思います。
Botにおける「細部に目を向ける」とは
プラットフォームや実現したい機能によって異なりますが、以下の項目が挙げられることが多いと思います。
- ロゴや名称
- ユーザーとBotの会話フロー
- コンテンツ(テキスト, 画像, 動画, 音声, 位置情報, ボタン)
- AI(自然言語処理)の導入
![](https://blog.n11sh1.com/content/images/2019/05/163e9a5a-d89f-4dad-b7fd-c228cee586e5.jpeg)
Botとの会話には大きく2種類「タスク主導の会話」と「トピック主導の会話」があります。
タスク主導の会話
ヤマト運輸の公式LINEアカウントの場合、
- 配達状況の確認
- 受取日時の変更
- 再配達依頼
が主なタスクになります。
これらのタスクは、正確性が求められます。(希望と誤った日時に変更されていたら二度と使いたくなくなりますよね)
![](https://blog.n11sh1.com/content/images/2019/05/d5cb26ee-52bd-477c-bf1f-465037c781af.png)
トピック主導の会話
この会話には正確性は必要なく、むしろ予想外の返答が求められます。
女子高生AIで有名なりんなのLINE公式LINEで「歌えるか?」「絵を描けるか?」聞いてみました。
![](https://blog.n11sh1.com/content/images/2019/05/6d63c0cf-1220-40df-a778-ab711238b4cc.png)
![](https://blog.n11sh1.com/content/images/2019/05/6ea17503-186b-4a1a-81a8-82c3f246b371.jpeg)
具体的な設計の話に入っていきます。 前述のヤマト運輸にならい「再配達Bot」を開発すると仮定します。 左右どちらのBotを使ってみたいと思いますか?
Onboardingとは、 組織の一員やサービスのユーザーとして新しく加入したメンバーに手ほどきを行い、慣れさせるプロセスのこと。 上記の場合、再配達Botを初めて友達登録した後の話です。
左の場合、 テキストが送られて来ただけなので、次にどうアクションして良いのか分からないですよね。 「再配達依頼」とテキスト入力?でもするのでしょうか。
右の場合、 下部にメニューボタンが表示されているため、とりあえず押したら次へ進めそうです。 また、次回以降のアクセス時も表示されるので、Botの使い方を覚えるコストも減ります。
このように、テキストメッセージのみではなく、画像や動画・ボタンなどグラフィックで表現することによって、コンバージョン率をグッと伸ばすことが可能です。
![](https://blog.n11sh1.com/content/images/2019/05/ebb8a686-ab74-48d8-885f-107c662fefac.jpeg)
次に、再配達の会話フローの設計に移ります。
ベースとなる会話フローは、以下のとおりです。
- STEP1 送り状番号をきく
- STEP2 希望配達日時をきく
- STEP3 最終確認
- STEP4 変更完了
これだけの処理で良いなら、IF分岐を駆使して処理が書けそうです。
ただ、以下のようなユーザー入力がされた場合、IF分岐を増やすだけでは追いつかなくなります。
- 送り状番号と希望配達日時を同時に入力されたら?
- 配達日時に「本日」や「夜」と入力されたら?
- 送り状番号と希望配達日時を逆に入力されたら?
![](https://blog.n11sh1.com/content/images/2019/05/6a44a578-143e-413c-8e39-2fc7b2a9fd18.jpeg)
そこで、AI(というよりは自然言語処理ですが)を導入することによって選択肢が広がります。
現時点のNLU+Conversation Managementのツールとしては、以下が有力でしょう。
- Dialogflow(Google)https://dialogflow.com
- Watson Assistant(IBM)https://www.ibm.com/watson/jp-ja/developercloud/conversation.html
- LUIS(Microsoft)https://www.luis.ai
- Amazon Lex(Amazon、日本語未対応)https://aws.amazon.com/jp/lex/
![](https://blog.n11sh1.com/content/images/2019/05/cc9bc8ac-20aa-4fed-b23c-c62524ea417e.jpeg)
![](https://blog.n11sh1.com/content/images/2019/05/92604cd4-ecc9-40cf-829f-2d2f0ded143a.jpeg)
20分という限られた時間だったので、重要な割合を占める導入部について話しました。実際に開発してみないと分からないことも多々あると思うので、ぜひ手を動かしてみて下さい!