ux-tooltips について
ux-tooltips は、インターフェースでツールチップを使う場面と方法を判断する生成型デザインスキルです。短い補足説明に用途を絞り、必須情報や複雑な内容には適切な別パターンを案内します。
主な機能
- 01各ツールチップの必要性を判断
- 02簡潔な文面の指針
- 03配置とコントラストの指針
- 04タッチ画面向けの代替案
- 05ユーザビリティと文案の監査連携
活用シーン
- 01意味が曖昧なアイコンの説明
- 02省略表示されたテキストの補足
- 03ホバー依存の説明を可視化
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/ux-tooltipsを入力して読み込まれたか確認します。
詳細
ツールチップスキル
このスキルの動作（最初にお読みください）
これは生成型のスキルです。デフォルトの失敗パターンは次のとおりです。ツールチップを杖にする（不明瞭なインターフェースを、ホバーヒントをそこら中にばら撒くことで「修正」してしまう）、冗長性（「送信」ボタン＋「クリックして送信」ツールチップ）、そしてホバー領域に重要情報を置く（コンテンツを必ず見る必要があるのに、多くのユーザーが決して行わない操作の背後に隠してしまい、さらにタッチデバイスでは確実に操作できません）。ツールチップは本当に曖昧な要素のための補足であり、フローの根幹を支える部分であっては決してなりません。このスキルがゲートするのは次のとおりです。
- 各ツールチップをゲートする — その要素は本当に曖昧なのか、それともデザインが不明瞭なのか？
- 常に当てはまる核心を適用する — 配置、簡潔さ、スタイリング、カーソルのシグナル。
- エスカレーションの判断を表面化する — ツールチップがまったく間違ったツールである場合。
その後、検証のために ux-heuristics-audit、ux-accessibility-audit、ux-aesthetics-audit、ux-microcopy-audit に引き継ぎます。
ステップ 0 — 各ツールチップの存在をゲートする
ツールチップごとに 3 つの質問があります。
- その要素は本当に曖昧か？ 「写真を撮る」か「ギャラリーを開く」かを意味しうるカメラアイコン → ツールチップはその居場所を得ます。「送信」とラベル付けされたボタン → ツールチップは不要です。ラベルを繰り返すだけになってしまいます。
- その情報はタスクに必須か？ ツールチップはユーザーがトリガーするものなので、多くのユーザーは決してホバーせず、タッチデバイスにはホバーがありません。フローを完了するために必要なものはインターフェース内（ラベル、ヘルパーテキスト、インラインメッセージ）に置き、決してツールチップには入れません。
- これはデザイン上の問題を上辺だけ取り繕っているのか？ ある画面が多くのツールチップを必要とするなら、ラベル、アイコン、またはレイアウトが失敗しています。要素を修正しましょう。注釈を付けてはいけません。（より優れた普遍的なアイコン、可視ラベル、またはアイコン＋ラベル —
ux-buttonsとux-menusを参照してください。）
常に適用する核心（ゲートを通過したツールチップ向け）
- 簡潔で必須事項のみのコンテンツ — 一口サイズの明確化（「写真を撮影」）、冗長性なし、ユーザーが目を凝らして読まなければならないものは何もなし。
- 配置が妨げにならないこと — ツールチップとそのトリガー要素の両方が完全に見えたままであること。説明している入力欄やボタンを決して覆わず、画面の端で切れることも決してないようにします。
- ホバー可能なトリガーにはポインターカーソル — より多くの情報が利用可能であることを示し、カーソルをポップアップと結び付けます。
- 左揃えのテキスト（LTR）、控えめなスタイリング、装飾的な枠なし、テキストとツールチップ背景の間に ≥4.5:1 のコントラスト。
- 製品全体で一貫した扱い — 1 つのツールチップスタイル、1 つのトリガー動作。
エスカレーションの判断（ツールチップが間違ったツールである場合）
| 状況 | 手を伸ばさないもの | 代わりに使うもの |
|---|---|---|
| フォームフィールドを完成させるために必要な情報 | 情報アイコン上のツールチップ | 入力欄の下のヘルパーテキスト（→ ux-inputs-and-forms） |
| 視覚的な疑問（CVV はどこ？） | モバイルでのテキストのみのツールチップ | インラインのアイコン/グラフィック、デスクトップでの補足としてのツールチップ |
| 初回実行時の機能の教育 | そこら中に常設されるツールチップ | オンボーディングのウォークスルーパターン（→ ux-onboarding） |
| タッチファースト製品上のあらゆるもの | ホバー依存のツールチップ | 可視ラベル、ヘルパーテキスト、またはタップでトリガーされるポップオーバー（ポップオーバーについては → ux-modals-and-dialogs） |
| リッチコンテンツ（画像、複数のアクション） | 詰め込みすぎたツールチップ | ポップオーバー |
| 全文表示が必要な切り詰められたテキスト | ユーザーが推測することを期待する | ツールチップはまさにここが適切です — 切り詰め＋ツールチップは正当な組み合わせです（→ テーブル、メニュー、パンくずリスト） |
結果を検証する（オーケストレーション）
ハンドオフでは、各レンズをインストール可能なスキルの
nameで指定します。呼び出すのは、そのスキルがインストールされている場合のみです。インストールされていない場合、このスキル自体のコアがすでにこれらのルールを備えているため、ブロックせずにそのまま進めてください。
生成または修正を行った後は、完了と宣言するのではなく、結果を監査レンズに引き渡してください。これらは候補のレンズです — 姿勢は docs/orchestration-policy.md で設定するか、全体を ux-design-review 経由でルーティングしてください。ここでは、**heuristics と microcopy はティア A（自動実行）、accessibility、aesthetics、mobile-responsiveness はティア B（オファー）**です — 既存のデザインシステムがある場合、aesthetics は抑制され、accessibility は使用状況に絞り込まれます。mobile-responsiveness はモバイルにのみ適用されます。ユーザーがこのスキルを特定の目的で呼び出した場合は、その範囲を尊重してください。
ux-heuristics-audit(ティア A) — 想起よりも認識（インターフェースはツールチップなしで自明ですか？）、扱いの一貫性。ux-accessibility-audit(ティア B — オファー。デザインシステムがある場合は絞り込み) — ツールチップの内容へのキーボード／フォーカスアクセス、タッチによる代替手段、コントラスト、ホバー専用の重要情報がないこと。ux-aesthetics-audit(ティア B — オファー。デザインシステムがある場合は抑制) — スタイリングの抑制、配置の cleanliness（清潔さ）。ux-microcopy-audit(ティア A) — ツールチップテキストの簡潔さと明瞭さ。ux-mobile-responsiveness-audit(ティア B — オファー。モバイルにのみ適用) — コンテキストがモバイルの場合：ホバー依存はそこではデフォルトで欠陥です。
監査で競合が表面化した場合は、主タスクに立ち返って解決してください。ツールチップを必要とするユーザーはすでに少し迷っています — 目標は、ツールチップをほとんど必要としないインターフェースです。
よくある do/don't パターン
| ❌ しない | ✅ する |
|---|---|
| Submit ボタンに「Click to submit」 | 意味が本当に曖昧な場合にのみツールチップを使う |
| 必須の指示をホバー内に隠す | 重要な情報はインターフェース内に。ツールチップは任意の補足 |
| 不明瞭な画面を ten 個のツールチップで patch する | ラベル／アイコンを修正する。ツールチップはまれな補足として |
| 説明対象のフィールドを覆うツールチップ | トリガーとツールチップの両方が見える配置 |
| ビューポートの端で切れるツールチップ | 端を考慮した配置 |
| 装飾的なフレーム、低コントラストのテキスト | 控えめなスタイリング、≥4.5:1 のコントラスト、左揃え |
| ツールチップ内の paragraph | 一口サイズの明確化を 1 つ |
| タッチ製品でのホバー専用ヘルプ | 可視ラベルまたはタップで起動するポップオーバー |
| 確認せずに出荷 | heuristics + accessibility + aesthetics + microcopy に引き渡す |