ボタン不要の対話型インターフェースの作り方(前編)

Source

Meekanプロダクトデザイナー

デザインとはユーザーにとって自然なストーリーを作ること。スケジューリングツールMeekanのプロダクトデザイナーによる、対話型インターフェース開発のプロセスと考え方とは?

私たちは、もはやグラフィカルユーザインターフェース(GUI)を持たないアプリケーションの爆発的な増加を目撃している。実際は、以前から出回っていたのだが、主流へと広がり始めたのはつい最近のことである。それらはbot、バーチャルアシスト、インビジブルアプリなどと呼ばれ、Slack、WeChat、Facebook Messanger、シンプルなSMS、あるいはAmazon Echo上で機能している。完全に人工知能で動かしているものもあれば、中に人間が入っている場合もある。

Still from the movie WarGames
こんにちは、Falken博士。
やあ。
ご機嫌いかがですか。
いいよ。君はどう?
元気です。しばらくですね。あなたの1973/6/23のアカウント削除について説明してください。
人は時々「間違う」ものです。
そのとおり。ゲームでもしますか?
いいね。世界核戦争はどうかな?
チェスのほうが面白いですよ。
それは後で。さあ、世界核戦争を始めよう。
分かりました。

映画『ウォー・ゲーム』より: コンピュータJoshuaとDavid Lightmanの会話。

私自身の対話型インターフェースとの出会いは1983年に遡る。まだ小さい子どもだった私は、友人たちと『ウォー・ゲーム』を見に行ったのだ。若いハッカーDavid Lightman(演じたのはMatthew Broderick)はカルフォルニア州サニーベールの電話番号に片っ端からダイアルしていたところ、偶然、第3次世界大戦をシミュレートするために設計された軍事スーパーコンピュータに接続してしまう。

すぐに私たちは、このコンピューターが異次元のレベルで作動していることを理解した。それはLightmanとまともに会話をし、ご機嫌伺いをしたり、ゲームに誘ったりできるのだ。細かくコマンドを打つ必要はない。このコンピューターに話しかけるだけで、答えが返ってくるのである。

30年後に戻ろう。Meekanで、チームメイトと私は新しい会議スケジューリングツールの開発に乗り出した。カレンダーに「来週中にJanとお茶したい」と伝えるだけで、最適な時間と場所をカレンダーが手配してくれるようにしたかったのだ。

まずは、Webページの概略を作成した。それからAndroidアプリ、次にiOSアプリ、最後にOutlookアドインを構築した。それぞれは互いに別物だった。つまり、それぞれが別の角度から問題点にぶつかった。そして、結局、満足のゆくものは何もできなかった。

Screenshot from Meekan’s iOS app showing time-of-day options
私たちのiOSアプリの時間帯オプション

15年以上ユーザーインターフェースを作ってきて、私がやりたいようにやるには、インターフェースは大きな妨げになることに初めて気づいたのだった。私たちが試していることはなかなか理解されず、たとえ理解したとしても、それを私たちのやり方でやるのは、既存の方法よりもはるかに難しいように見えるのだった。私たちは先へ先へと開発を進め、より多くのバージョンを作ることもできるが、それよりもアプローチを変える時が来たのだ。可能な動作の範囲、ユーザーが求める数え切れないほどのやり方 — それは1セットのボタンとコントローラーで描き出せるものではない。インターフェースには制限がある。インターフェースではない何かが必要だ。その「何か」にJanとのミーティングについて伝えれば、そのとおりに手配されるように。

そして分かってきた。私たちが作るのはロボットだ!

今からその話をする前に知っておいてほしい。あなたがデザイナー、あるいは開発者であるなら、少し新しい考え方に慣れる必要が出てくるかもしれない。最も一般的なGUIパターンとフローのいくつかはもはや機能しない。また、あるものはこれまでのパターンとは少々異なって見えるだろう。オックスフォード大学によると、次の20年のうちにアメリカ国内の職業のうち約半数はロボットに取って代わられるのだという。つまり、誰か(あなたかもしれない)がこれらのマシンを作り、私たちとマシンが適切にコミュニケーションをとれるようにしなければならないのである。私たちが既に飛び越えてきたハードルを共有することで、他のデザイナーたちのスムーズな移行の一助となればと思う。結局、デザインとはほとんどがユーザーにとって自然なストーリーを導くことであり、ロボットの作成はそれをより純化したものと言えるだろう。

Photoshopはいらない

考えてみてほしい。今やアプリケーションの外観はコントロールできないに等しいのだ。レイアウトやスタイルは選べないし、タイポグラフィーを変えることもできない。常に誰か他人のプラットフォームに乗せてもらうことになるのだから、彼らのルールを尊重しなければならない。

Screenshot showing how the same message appears across Slack, HipChat, and WhatsApp
Slack、HipChat、WhatsAppそれぞれのメッセージ表示

さらに良くない状況にもなり得る。プラットフォームが声によって制御されていたなら、ビジュアルの要素すら無いということだ。あなたのインターフェースは全て、目でなく耳で理解できなくてはならない。それに加えて、同じチャネルで起こっている他の会話と、1つのスペースを争うこともあるだろう。

簡単な状況ではない中で、会話を主導しなくてはならない。つまり、全ての仕様に言葉だけでアクセスできる必要がある。適切な言葉、ユーザーに合う対話のトーンの選択がきわめて重大だ。もはやそれが、あなたのアプリケーションが何をどのように行うかを伝える唯一の方法なのである。Webの標準では、コンテンツとスタイルの分離が要求される。しかしここでは、スタイルに関するものはまるごと窓の外に放り投げられる。あなたのコンテンツが、あなたのスタイルなのだ。Photoshopスキルを否定された今、あなたが語ろうとしているストーリーの核心に手を伸ばさなければならない。

では開発者はどうだろう?喜ばしいことに、あなたの仕事は純粋なロジックになる。CSSをいじり回すのを嫌うタイプの開発者にとっては、これは人生で最も幸福な出来事であろう。

新しいツールボックスに入っている第1のツールは、ロボットのスクリプトと動き方を書くテキストエディターである。話が込み入ってきたら、その紆余曲折を理解するのに、Twineなどのツールが便利だ。botのコーディングとスケーリングのためのツールとライブラリーは、こうしている間にも何十も登場している。例えば、言語理解を操作するWit.ai、ホスティングはBeep Boop、人気のSlackプラットフォームとのインテグレーションならBotkit、などだ(これを書いている時点では、開始から終了まで全てのプロセスを操作できる全網羅ツールは存在しない。そこにチャンスの予感がする)。

しかし、もう一度言う。ビジュアルインターフェースデザインの全項目は、例えばコントローラーを配置したり、マウスとタッチインタラクションを操作したり、カラーを選んだりすることまで、全ては対話型フォームへの切り替えによって影響を受けたり、丸ごと無くなったりする。そのことを頭の片隅に置いて、次に進もう。

役割を説明し、次のアクションを促す

新規ユーザーが、あなたのiOSアプリをインストールし、初めて起動したところを想像してみよう。ホームスクリーンが現れる。おそらくほぼ空白だが、その上にはなじみ深いコントローラーがいくつかある。オプションメニュー、設定ボタン、新しいことを開始するための大きなボタン。好きなものを選べばよい。

それに比べると、ロボットとの最初の出会いは、顔も見えない相手の声に頼るしかない状況だ。

ユーザーとの最初の接触は、自己紹介が自然だ。繰り返すが、あなたはおしゃべりの最中なのである。簡潔に、ポイントが分かるよう、1行か2行にとどめよう。このことについては後でもう少し話すが、目に見えるインターフェースがない場合、ユーザーの頭の中は次の2つのどちらかであることを覚えておきたい。

  1. これは私が頼んだことを何でもやってくれるから、指示を出そう。

  2. 何をどうすべきか見当がつかないから、ただじっとスクリーンを眺めている他ない。

これは最初のテストをした時の、私たちのユーザーの反応だ。ただ眺めているか、突拍子もない命令を入力するかのいずれかだった。

私たちはうろたえた。ユーザーにとっては、スケジューリングが出来ることが一目では分からないのだ。だから、自己紹介をして、チーム内での新しいロボットの役割について何をどう期待すればよいのかを定義することが必要なのだ。同時に、躊躇せず彼の使命を宣言することだ。このロボットはあなたのカレンダーを操作する!そうすれば、突拍子もない指示に従わなくとも、ユーザーは落胆せずに済むのである。

紹介の後は即座にアクションを促そう。その場でできることをすぐに提示し、ユーザーが止まってしまうのを避けるのである。

やあ、Matty!僕はMeekan、あなたのチームの新しいスケジューリングアシスタントです。瞬時にミーティングの予定を入れたり、あなたの予定を確認したりするだけでなく、航空券も見つけられます!早速、指示してください。

「Meekan、来週ランチミーティングをしたい」。

何かを見つける時は、目的への最短距離を選ぼう。ユーザーは1つのことを入力するだけで、すぐに魔法の宝物が得られるのだ。この後ユーザーは、ロボットなしで何かをしなければならない生活には、二度と戻りたいと思わないだろう。そして、ロボットを繰り返し使うようになるだろう。さらには、友人全員にそのことを話すに違いない(実際はそれほど簡単なことではないが、「第一印象」のポイントをつかんでもらえれば幸いだ)。

さらなる仕様を提示する

GUIをデザインする時には、「見つけやすさ」が議題に上ることが多い。ユーザーに、あなたのアプリにできることを知ってもらいたければ、それをスクリーンのどこかにベタッと貼っておくしかない。例えば、初めてのTwitterで、初めてツイートを目にした場合、私の選択肢は次のように表示される。

Twitter screenshot showing various UI elements like the Heart and Retweet icons, etc.

分かりやすい。私はこれらの小さなアイコン群の上にマウスを移動すればいいだけだ。非常に意味が明快なものもあれば(星やハートなど)、多少調べなくてはならないものもあるが、少なくともそこに存在するのは分かる。スクリーンを見渡すと、通知リンクがあり、赤く小さな数字が付いている。サイトを離れている間に、通知を受け取ったらしいと推測できるわけだ。

Screenshot showing Twitter UI elements: the Home, Notifications, and Messages icons

しかし、ロボットに話しかける時は、ただ空間を見つめることになる。次のステップを示し、すぐには見つけにくい仕様に気付かせるべく、あらゆるチャンスをつかみに行くのはロボットの仕事なのだ。

  • 導入時:先に述べたように、ユーザーとの最初の接触で、そのロボットに頼めば遂行できるタスクを示そう。

  • 最初の命令の受け取り: そこで何が起こっていて、ミッションの達成のためにロボットが何をしているか、詳細な説明から始めよう。次に選択し得るステップを勧めたり、サポートの受け方を説明したりしよう(例: FAQページや完全な手順書にリンクする)。

  • 徐々に説明を減らす: 最初の対話が成功したら、ロボットはより簡潔に、効率的になれる。

  • さらなるゴールを提示する: 関係の進展に従って、より多くの選択肢や、上級者向けのヒントを公開し続けよう。それはユーザーのアクション履歴を基盤に行うとよい。たった今ユーザーがやったことを説明しても意味はない。

例: ミーティングを同期しました!会議室の予約もできますよ。

  • 積極的にできることを提案する: 例えば、ユーザーはロボットがミーティングの予定を入れていることは知っていても、食事の注文までできることは知らない。

例: ミーティングまであと1時間。3人分のランチを注文しましょうか?

ロボットが会話を主導する場合は、話の流れに沿った、役に立つ提案ができるようにすることだ。そうでなければ、ただのスパム行為である。そしてもちろん、ユーザーはいつでも簡単にその提案を断れるようにしよう。

なるべく楽をしよう

ロボットが内部で、整然としたメッセージ送受信や声のプラットフォームを動かすことを前提とするとたやすいが、そうとも言えないケースが増えている。Amazon Echoを制御するのは声だが、ガイドアプリを持っている。WeChatとKikには内蔵ブラウザがある。HipChatではカスタムカードとサイドバーのiframeが使える。FacebookとTelegramには選択メニューがある。Slackbotは、メッセージ内にディープリンクを埋め込んでいる(そして、この技術が近いうちにより拡大するかどうかは疑問だ)。

Screenshot showing how Slack uses deep links
Slackbotはディープリンクでアクションを促す。

対話型インターフェースのあらゆる利点をもってしても、いくつかのタスクは入力装置でボタンをクリックするほうが楽だ(複数選択、文書閲覧、マップ検索など)。あなたのプラットフォームでより多様なツールボックスが使えるなら、対話型インターフェース1個にこだわることはない。ユーザーに提示するフローを具体的なアクションまで落とし込むと、テキストを1行入力するよりも、シンプルなボタンのほうが便利なこともある。

Screenshot showing Telegram’s interface, which uses pop-up buttons
Telegramはメニューの開示とショートカットにポップアップボタンを使っている。

これらの機能はかなりの速度で変化していくので、すぐに適応できるように努めよう。

そして次のステップへ

ユーザーは、おしゃべりロボットに慣れてくるにつれ、これらの動作について期待を形にし始める(私がロボットを「彼」と呼ぶことで、意図的にロボットにジェンダーを割り当て、より人間らしくより容易に関係性を築けるようにしている。しかし、アシスタントロボットを男性にすることで、私たちのチームは、サポート役のロボットに女性名をつけるというありがちなステレオタイプを覆してもいる)。

対話型デザインに関して決定版と呼べる参考書はまだない。対話形式をデザインしては壊し、また作ることを繰り返す中で、ベストプラクティスが見えてくるだろう。私たちデザイナーにとって、これらマシンとの関係性のあり方に影響を及ぼすことのできるチャンスである。私たちが形作ったツールが、今度は私たちを形作ることになるのだ

次に、基本的なGUIのパターンをより深く探り、対話型形式の中でそれらを再現する最善策を議論していこう。

後編に続く