見出し画像

ツールチップ|UIデザインポリシー整理

リーガルテックAI SaaSスタートアップ、MNTSQモンテスキューのプロダクトデザイナーのクボスケです。

私たちは、レバレッジの効くデザインの仕組みづくりを目指しています。この記事は、MNTSQとしてのUIデザインの基準や方針を決めていく「UIデザインポリシー整理」というプロジェクトのなかで行なわれたディスカッションをもとにまとめたものです。

このプロジェクトの主旨や運営については、初回の記事でも述べていますので、ぜひご覧ください。

それでは、今回のトピックは「ツールチップ」です。


ツールチップ

ツールチップは、要素または機能について補足情報を提供します。マウスオーバーまたは入力へのフォーカスによって呼び出されます。クリックをトリガーとするもの、補足を超えて構造化された情報を持つものは、ツールチップとは区別して取り扱います。

ツールチップはあくまで補足であり、操作に必要な情報の表示には使用しません。主な使用例は、補足的な説明を表示する場合、アイコンのみのボタンにラベルを表示する場合、省略されたテキストの全文を表示する場合などです。アクセシビリティの観点からも、それがないとユーザーが操作を進められない情報は別の方法で常時表示することを検討します。

補足情報であるツールチップのコンテンツは装飾のないテキストおよび、絵文字やインラインで文字に準じて扱うアイコンのみとします。文全体のボリュームは数行程度に収めます。文が長くなってしまう場合、省略された全文の表示が適切か、あるいはそもそもの設計に見直すべきところがないか検討します。

さりげない角丸の四角形と、トリガーである要素を指す同色の三角形で構成します。高度に合ったドロップシャドウをつけ、背景のコンテンツよりも上位のレイヤーにあることを示します。

配色はグレートーンです。通常明るい色である業務アプリケーションの背景と区別しやすいように、明度を反転してツールチップの背景色は暗く、テキストの色は明るいものにします。補足情報という控えめな存在として、主のコンテンツよりも高いコントラストにならないようにします。テキストのフォントは環境デフォルトのゴシック体とします。

トリガーである要素に対して上側への配置を基本とします。周囲の余裕に合わせて、上下左右に配置を調整し、ツールチップが画面から見切れないようにします。


以下はやりとりの内容を一部抜粋したものです。

クボスケ:ひとくちに「ツールチップ」といっても、さまざまな用途のものがいっしょくたに呼ばれている気がします。基本的には、ホバーなどの特定のアクションをトリガーに、情報を追加で表示するためのもの

kassy:a11y(アクセシビリティ)観点では使わないほうがいいと言われていたり。ツールチップで提供する情報はあくまで補足的なもので、なくても成立する場合に限ります

クボスケ:スマートフォンやタブレットなどタッチデバイスとの相性もよくないですよね。ホバーがないので。そういえばFigmaのInteractionsって「On Click」と「While hovering」を同時につけられないですよね。あえてなんでしょうかね?

ナカシマ:補足の用途、というのは認識同じです。

  • 何につけるか--それだけだと識別が難しいオブジェクトのデータ

  • どんな情報か--ユーザーの関心に沿い、判断の助けになる意味を補強する情報

  • どんなタイミングか--ユーザーが補足を必要としていないときに表示するのはノイジーだし、ほかの情報を覆い隠してしまうことも。アイテムが並んだリストの上でカーソルを滑らせたときにホバーで次々とツールチップがやたらに表示されるのはよい操作感ではない

クボスケ:かといって、「ユーザーが求めた時」すなわち「クリックしたとき」なのかというと、そうでもないですよね

kassy:長いため「…」で省略されているテキストを表示するためのツールチップがありますが、そもそもアイテムの一覧のように表示スペースの制約が大きいところで、なんの情報を表示すべきなのかなど、関連する論点はいろいろありそうですね

クボスケ:たしかに。ユーザーにとってその場面で本当に必要な情報の選別を怠った結果、あれもこれもツールチップに頼ることになってしまっている状況を見直すことは大事ですね

クボスケ:ユーザー名をクリックすると、そのユーザーのメールアドレスや所属グループといった詳細情報を追加的に表示するUIは妥当な感じもしますが、こういうのは「ツールチップ」なんでしょうか

ナカシマ:ツールチップで扱う情報は、その中に階層構造を持たないという整理がいいのでは。SmartHR社による定義は自然な感じがします

Tooltipコンポーネントは、UI上のスペースが限られている場合に、補足テキストを一時的に表示するために使います。
- 補足的な説明テキストを表示する場合
- アイコンだけのボタンにラベルを表示する場合
- 省略されたテキストを全文表示する場合

SmartHR Design System コンポーネント > Tooltip

クリックで構造を持つ情報を表示するものは別のUIという扱いですかね。

クボスケ:構造を持ったコンテンツのふきだし表示の呼称は「popover」 でしょうか

kassy:「Coach Mark」という呼び方もありますね

ナカシマ:ちょっと調べてみると、いわゆるウィザードなどでアプリの使い方を表示するのを「coarch mark」というニュアンスが多かったですね。ところで、Nielsen Norman Groupのtooltipの解説に、わりとこの議論に近いことが整理されています

  • Webの世界で一般的だが誤用も多い

  • ユーザーの求めに応じて出現する

  • だから新機能の案内や操作説明はToolitipとは別物

  • あくまで補足的に使う

  • タッチデバイスでは使えない

クボスケ:トリガーはホバーのほか、フォーカスもありますね
「Keyboard hover」(Tabや→キーででfocusした時)という用語を知りました

ナカシマ:それから、この記事での「popover」や「tooltip」などの“画面のうえに浮いている要素”の整理がいい感じです。別のUIではなく、内包した概念というのが視覚的にわかりすいですね。「coarch mark」も「Popovers」に内包されるものってすると納得感ある分類になるのもいいなと思いました

クボスケ:「Overlays」からベン図で仕分けていくのはわかりやすいですね。のちのちのドキュメンテーション整備では、これまでに議論済みのモーダルウィンドウなどもあわせて、この構成で紹介する形にしてもいいかもしれません

kassy:この整理はわかりやすいですね〜!

Tooltips-categorization
Tooltip is a type of popover 出典:Popups, dialogs, tooltips, and popovers— UX Patterns #2
Comparison table — tooltip 出典:Popups, dialogs, tooltips, and popovers— UX Patterns #2

クボスケ:ツールチップで表示する情報の中には構造を持たない、という整理にしましたが、テキスト情報だけ? 画像もOK? 量についてはどうですか

kassy:テキストのみでいいのでは。量は複数行に渡ることもあると思います。テキストに組み合わせてアイコンを使うケースはあるかも

ナカシマ:emojiも文字ですかね。

クボスケ:文量が多すぎるのは困りそうなので、適量はありそう。複数行の場合は見やすい幅で適宜折り返す。字数を決めるよりは、補足として妥当な範囲で、くらいの整理にしておいてはどうでしょうか。幅に関してはウィンドウから見切れないようにするという観点もありますね。位置も影響があります

ナカシマ:基本は上だが、画面内の要素周辺の余裕に応じて位置を出し分けるとよいと思います。フレームワークである程度吸収できるはず。ふきだしについても考慮してくれるライブラリがあります。左・右(上・下)・中央の固定位置のバリエーションがあれば十分

クボスケ:ツールチップの配色についても考えたいです。視覚的に埋もれないように、元のコンテンツとは反対の明度の背景色がよさそう。

ナカシマ:配色はボーダー、ドロップシャドウとの兼ね合いも考慮したいですね

クボスケ:補足的な情報という位置付けなので、元のコンテンツよりはコントラスト比が弱いほうが順位づけが自然に思います。コンポーネントとしては明るいグレー/暗いグレーの2種類の用意があったりしますが、MNTSQでは基本的に淡色背景なので、ツールチップは暗いグレーの1種類でいいのかもしれません。ドロップシャドウは境界がぼけないように注意したい

kassy:実際のバランスをみて要調整ですね。あと角丸。インタラクティブなものは角丸にするなど一貫性を持たせるとよいと思います

クボスケ:あまり大きな角丸はカジュアルな印象になってしまうので、MNTSQの世界感的には、径が小さめの、ほのかな角丸が合っていますね

クボスケ:ツールチップのフォントはどうでしょうか。明朝体になっているものを見かけたことがありますが、違和感がありました。補足であるツールチップは比較的小さい文字サイズになるので、視認性の観点でも明朝体は向かないと感じました。

ナカシマ:Webフォントを全面的に使うのはいろいろ難しい面も。見出しだけとかなら

クボスケ:何年か前にWebフォントの読み込み速度を検証をしたことがあります。セットに入れるJISの水準を絞って高速化を図っしたりしました。でもサブセットを小さくすると異体字がなかったりして、業務システムで人名や地名の表示に困るケースもあったんですよね

kassy:スマートフォンアプリだとまた事情は異なるけど、ここらへんあまり大きく進化している印象はないですね

クボスケ:ツールチップのフォントはゴシック体を使う、までとしましょう


参考資料


みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!