人とコンピュータの関係を考えると、二者間には常にインタフェースが存在します。本連載では、人とコンピュータの間に介在するインタフェースに着目し、インタフェースとそれらを世に生み出すプロダクト開発について議論します。Helpfeelが、独自のインタフェースを実装しながら、便利さと楽しさを備えたWebサービスをどのように開発しているのかについてお伝えします。

こんにちは。yuisekiです。Helpfeelでメディアキャプチャーツール「Gyazo」のプロダクトマネージャーをしています。今回は、Gyazoの設計・開発の過程で得られた、人間の認知や判断、行動や操作に関する知見を紹介します。

人間の速さへのもう一つの視点

本稿でみなさんに最もお伝えしたいのは、「人間は極めて速いけど、遅いほうが適切な場面もある」ということです。前回は、「人間は極めて速い」という事実を前提として、ソフトウェアにおける実際の事例や、そうした人間の速さを意識してソフトウェアでおもてなしをすることの重要性について説明しました。

本稿においても「人間は極めて速い」という前提に変わりはありません。しかし、ソフトウェアの設計において、そうした人間の速さに合わせること「だけ」が、常に必ず最適なおもてなしであるとは限りません。むしろ、速さを鎮めて、遅くすることが必要な場面もあることは、みなさんも経験があるかもしれません。こうした人間の性質を観察し、理解し、意識しながらソフトウェアを設計することで、ユーザーにとってわかりやすく、使いやすいソフトウェアを開発できます。

人間が速いと困る場面の実際

具体的に人間が速いと困る場面として、クレジットカードの入力フォーム、個人情報入力フォーム、管理者権限でOSに変更を加える場合、ユーザーに対する重要なお知らせを表示する場合、ユーザーアカウントやコンテンツの完全な削除、アクセス権限を変更する場合、などが挙げられます。

このように、「速さよりも確実さが重視される場面」「速さよりも精確さが重視される場面」「速さよりも詳細さが重視される場面」などにおいては、ユーザーに画面に注目してもらい、じっくりと落ち着いてソフトウェアを操作してもらう必要があります。

人間の速さを鎮めておもてなしする:具体例

さて、前述の通り、速さよりも他の要素が重視される場面は実は多いです。そのすべてを紹介することは難しいため、ここでは、筆者が世の中のソフトウェアを観察していて特にユニークだなと思ったUIをいくつかピックアップしてお伝えします。

強制確認UI

最初に、筆者が「強制確認UI」と呼んでいるUIのパターンです。まずは具体的なスクリーンショットをご覧ください。

  • Misskeyのスクリーンショット、その1

    Misskeyのスクリーンショット(その1)

  • Misskeyのスクリーンショット、その2

    Misskeyのスクリーンショット(その2)

Misskeyとは、分散マイクロブログSNSと呼ばれるソフトウェアです。このサービスはユーザーが投稿した「ノート」に対して他のユーザーが多種多様な絵文字でリアクションできて、かつ、それがリアルタイムで各ユーザーのUIに反映される、という非常に変化が速いソフトウェアです。そんなMisskeyにおいて、ユーザーを引き止めるひときわ印象的なUIが、この強制確認UIです。

ユーザーに「閉じる」のようなボタンではなく、「わかった」というボタンを押すことを強制しているところが特徴的です。ユーザーにソフトウェアを素早く操作されると困る代表的な事例として、「ソフトウェアからの重要なお知らせ」「深刻なエラーメッセージ」などがありますが、このUIはそうした場合に有効です。

一方で、強制確認UIを採用するべきではない場合もあります。例えば「Cookie同意バナー」は、EUのGDPRにおいては、「同意する」ボタンだけではなく「拒否する」というボタンを必ず設置することが義務付けられています。

後戻り不可能UI

ユーザーにソフトウェアを素早く操作されると困るもう一つの代表的な事例としては、「アカウントの削除」などの、元に戻すことができない、後戻り不可能な操作が挙げられます。こちらの具体的な例は以下の通りです。

  • GitHubのリポジトリ削除UIのスクリーンショット、ステップ1

    GitHubのリポジトリ削除UIのスクリーンショット(ステップ1)

  • GitHubのリポジトリ削除UIのスクリーンショット、ステップ2

    GitHubのリポジトリ削除UIのスクリーンショット(ステップ2)

  • GitHubのリポジトリ削除UIのスクリーンショット、ステップ3

    GitHubのリポジトリ削除UIのスクリーンショット(ステップ3)

  • GitHubのリポジトリ削除UIのスクリーンショット、ステップ4

    GitHubのリポジトリ削除UIのスクリーンショット(ステップ4)

GitHubにおいては、リポジトリの削除時にユーザーにそのリポジトリの名前を入力させることで、確実な意志の確認としています。このように、コンテンツの削除時にユーザーにテキストの入力を求めてくるパターン自体はよくあるものですが、GitHubの場合は、そこに至るまでに、2つのモーダルダイアログの内容を確認してボタンを押す必要があります。

そして、単にモーダルダイアログでしつこく慎重に確認を求めてくるだけではなく、「リポジトリを削除する」などの後戻り不可能な操作を実行するためのボタンが、画面を一番下までスクロールしないといけない最下部に「Danger Zone」と名付けられてまとめて配置されていることも重要です。

前回の内容を踏まえると、慎重な確認が必要な操作はあえてファーストビューには配置しない、ということもおもてなしになるのです。コンテンツの削除時にここまでしつこくユーザーに確認を求めてくるソフトウェアも珍しいと思って、GitHubの例をご紹介しました。

味集中カウンターUI

次に、筆者が味集中カウンターUIと呼んでいるUIを紹介します。こちらも、まずは具体的なスクリーンショットをご覧ください。

  • Googleのトップページ

    Googleのトップページ

  • Googleのログイン画面

    Googleのログイン画面

これらのスクリーンショットをお見せしても、共通点がすぐには伝わらないかもしれません。味集中カウンターUIは、「強制確認UI」や「後戻り不可能UI」ほど、明確な強い特徴のあるパターンというわけではありません。

画面がいろいろなUIコンポーネントでごちゃごちゃしていると、ユーザーに「自分は一体いま何をして良いのか?」と迷わせてしまいます。余計な要素を一切排除して、特定のアクションしかできないくらいまで削ぎ落とすことで、正確な操作を促すことができます。

このように、ユーザーに雑念を払って目の前の作業に落ち着いて集中することを促すようなUIを、筆者は味集中カウンターUIと呼んでいます。語源はもちろん、「天然とんこつラーメン専門店 一蘭」の「味集中カウンター」です。

「天然とんこつラーメン専門店 一蘭」はカウンター席のみで、さらに席ごとに仕切りがあることで、他人と会話などせずラーメンの味に集中できるのです。

  • 一蘭の味集中カウンター 出典:一蘭 ( https://ichiran.com/column/clmn-005039.html )

    一蘭の味集中カウンター 出典:一蘭 ( https://ichiran.com/column/clmn-005039.html )

人間の速さと情報環境の設計

今回、最後に味集中カウンターUIをご紹介したことには、理由があります。飲食店における内装設計は、従業員やお客様の行動に大きな影響を持つと言われています。一蘭のようにカウンター席のみで壁で仕切られたラーメン店であれば、そこではお客様は目の前のラーメンと向き合うしかなくなります。一方で、例えば、オープンキッチンのラーメン店であれば、そこで働く従業員たちはお客様からも目に見える厨房の清潔さを大切にするでしょう。

筆者が伝えたいことは、ソフトウェアにおけるUIも、単なる表層的なものではなく、ユーザーの行動を大きく左右しているということです。今回ご紹介したように、ただすべての操作が速くできるだけでは、それが良いソフトウェアになるとは限りません。あえて操作を難しく・遅くするなど、ゆっくりと慎重に集中して操作してもらうためのUIのパターンがあります。

本稿が、より良いソフトウェアの開発に関して何かしらのインスピレーションを与えられるものになっていたら嬉しいです。

文:yuiseki