技術や読んだ書籍、考えたことなどを書くブログ。http://blog.noriaki.meこの広告は、90日以上更新していないブログに表示しています。キャラクター設定」を考えたら、コミュニケーションプラットフォームでBotサービスを作るときに大切にしたいことが分かりました。Trialを利用して、「カサいる?」というBotを作ってみました。画像にあるとおり、LINEトークの基礎機能である「位置情報を送信」すると、傘を持っていくべきか(その地点に今雨が降っているか、1時間の間に傘が必要なくらい雨が降るのか)を教えてくれるもの*1です。よかったら試してみてください。(LINEアプリ内のQRコードによる友達追加から上の画像を読み取ってみてください)というBotサービス紹介だけでは申し訳ないと思うので、ここではBotサービスを作る際に考えたことを書き出してみます。Messengerなどコミュニケーションが前提となるプラットフォームの上で動かすBotの場合、インタフェースは当然チャットになります。今回、「カサいる?」を作ったときに、このチャットというインタフェースが意味することとして3つのことを考えました。最初にユーザさんがこのBotを使うシーンとして「家から外出する玄関」や「家に帰るために会社から出るとき」を思い浮かべました。その上で、この3つのことを考えていきました。結論から言うと、テキストで「地名」や「住所」などを受け取る入力方法は適さないので、「位置情報を送る」機能を使うことにしました。最初、チャット画面なので対話型で「いまどこにいますか?」と聞いて、「銀座」などとユーザさんに答えてもらうような方式を考えました。これはシステムとしては思った以上に複雑で、入力されたテキストが住所として適切なのかとか、打ち間違いや表記揺れはどうするのかとか、日本全国に銀座ってたくさんあるけどどれのことを指しているのか、など対応パターンが膨大になってしまいそうでした。*2また、ユーザ体験の観点でも、自分が今いる住所や地名が分からない(思い出さないといけない)とか、場所を特定するためにBotサービスとの会話の往復が増えたり、傘を持っていくべきか決めたいだけなのに考えないといけないことが多すぎると感じました。結局、チャットという方式にこだわらず、LINEに標準で備わっている「位置情報を送る」機能を使って送ってもらうことにしました。ユーザさんはBotサービスに話しかけるのが普通だと思っていると思われるので、「カサいる?」Botサービスでは友達追加したとき(とブロック解除したとき)に使い方を含むメッセージを自動で送るようにしました。結論は、情報の詳細度合いや時間的な正確性を多少犠牲にしてでも「ユーザさんが求めていること」だけをシンプルに回答するようにしました。傘を持って行った方が良いのかそうでないのかどのくらい濡れてしまいそうなのか結局、利用シーンを考えると上記のように知りたいことは傘の要不要だけなので、(情報としては提供可能でしたが)晴れや雨などの天気概況や降雨量、時間毎にどう変化するのか、といった情報は全て削除しました。結論として、ユーザさんが知りたいこと(解決してほしい課題)がストレートに分かることを意識した名前にしたこと、チャットで返答してくれるのだからキャラクターを決める、ということをしました。最初、名称は「天気Bot」とかにしていました。アイコンは「天気マーク(太陽に雲がかかってるやつ)」*3にしていました。ここでも利用シーンを考えると(おそらくたくさんの)友達や公式アカウントなどが並ぶ友達一覧から探してタップすることになるのに、しかも急いでいるから早く見つけたいのに、「天気」というワードが思い浮かぶでしょうか。頭に思い浮かんでいるのは「傘要るかな?」だと思ったので、素直にそのままの名前にしました。アイコンも対話するのに自然なのはキャラクターかな、と思いましたが自分で描くことは出来なかったので、傘をさしたカエルのキャラクターのイラストを「いらすとや」さんから使わせていただきました。まとめあらためて自分が考えたことを書き出してみると「コミュニケーションのスピードを出来る限り速くしよう」と考えていたことに気付きました。3つの考えたことに照らして説明すると、こうなります。多少都合良く書いていますが、要点は伝わるでしょうか。速い:今は降ってないよ。Messengerといったコミュニケーションプラットフォームは非常に多くの利用者を抱えているので、Botサービスを開発をする側にとっては利用される機会が増えチャンスです。(会話そのものを楽しむサービスでない限り)短い接触時間で済むようなデザイン・コミュニケーション設計が出来ていないBotサービスは次第に使われなくなっていくでしょう。これらプラットフォームの通常のユーザ体験は、じっくり会話するより瞬間的な会話応答の連続なので、この基本体験から時間軸が外れるBotサービスは面倒がられていくと思うためです。システムの応答速度はもちろん、チャットや会話によるインタフェース特性を考慮して、ユーザが満足を感じるまでの時間が短いサービス体験を提供する必要があるため、エンジニアリングだけでなくコミュニケーションデザインや情報整理の重要性が高まりそうです。今回は「傘の要不要」を解決するBotサービスを作ったことから得た考え方を整理しました。企画する人、開発する人の参考になれば幸いです。Yahoo!デベロッパーネットワークを利用しています*2:すなわちこういうことですね。日頃Terminal使ってない人が、その口で「すべてのUIはチャットになる」とかいうの、もう見てらんない。MS-DOSのときにコマンド覚えられない人がたくさんいた。Windowsになった。2016年4月14日チャットボットによる未来の理想と現実。Uchiyama※ここで書いているものは私個人のものであり、特に明示しない限り所属する企業や団体には一切関係ありませんはてなブログをはじめよう!uchiuchiyamaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。