design-ux

design-ux — ユーザビリティ監査（ヒューリスティック評価）

使用する場面

このスキルは、インタラクティブな UI のユーザビリティ監査（ヒューリスティック評価）が必要なときに使用します（単なる見た目の磨き込みではありません）。UI が「どこかおかしい」、「使っていて不快」、習得が難しい、説明の壁が必要、あるいはインタラクティブなツール／エディター／アプリを出荷する前に、design と一緒に読み込んでください。レンダリングされた UI をニールセンの 10 項目 + ... に照らして採点します。

ユーザビリティ ≠ 美しさ。design-system/design-spatial はそれを正しく見せるためのものですが、これは初めて使う人が何も教えられずにタスクを実行できるかを確認します。UI が「使っていて不快」なとき、1 段落の説明書きが必要なとき、あるいはインタラクティブなものを出荷する前にはいつでも使ってください。

ルール 0 — レンダリングされた成果物に対して、まっさらな視点で（design-spatial §1 から継承）

自分で採点しないこと。 作り手は自分の UI を合理化してしまいます。実際に動いている UI をデフォルトの初回読み込み状態でレンダリングし（手作業で整えたスクリーンショットではなく）、主要タスクのインタラクショントレースを取得し、別の評価者（それを構築していないサブエージェント／VLM）に採点させてください。変更点の一覧を書いたものは監査ではありません — 監査とは、まっさらな評価者が実際の画面で何が間違っているかを探し出すことです。

手順

1. 主要なタスクを挙げる — UI が存在する目的のタスク（例:「クリップをトリミングして速度を設定し、エクスポートする」）。監査は抽象的な美しさではなく、これらを基準に行います。
2. デフォルト状態をレンダリングし + タスクをトレースする。 初回読み込みの UI をスクリーンショットします（ワイド AND ナロー — design-spatial §2 のオーバーフローゲート）。次に実際に主要タスクを実行し、各ステップをスクリーンショットします。
3. すべてのヒューリスティックを採点する（以下の表）— 成果物に対して、合格／違反、重大度（ブロッカー／重大／軽微）、具体的に位置を示した指摘、そして具体的な修正案。これは別の評価者が行います。
4. 優先順位付け: ブロッカー → 重大 → 軽微。同じ画面に触れる修正はまとめます。
5. 修正し、その後 RE-RENDER と RE-SCORE を行う。 新しい成果物を再監査せずに修正済みと主張しないでください（verify-outputs-rule）。

ヒューリスティクス — それぞれを採点する (ニールセンの10原則, 1994) + インタラクションの追加項目

#	ヒューリスティクス (ニールセン)	この UI で確認すべきこと
1	システム状態の可視性	すべての操作に目に見えるフィードバックがあるか; 現在の状態・選択・モードが常に読み取れるか; 時間のかかる操作の進捗が示されるか。
2	実世界との一致	既知のメタファーと慣習 (例: NLE ならクリップ、トリムハンドル、再生ヘッド) — ユーザーが覚えなければならない独自のジェスチャーではないか。
3	ユーザーの主導権と自由	取り消し・やり直し、キャンセル、どの状態からでも明確に抜け出せるか; デフォルトで可逆であるか。
4	一貫性と標準	同じものは同じ見た目・同じ挙動か; プラットフォームの慣習 (⌘Z、Delete、ドラッグで移動) が守られているか。
5	エラーの予防	不正な状態が起こり得ないようにされているか; 破壊的な操作は確認されるか、簡単に取り消せるか。
6	記憶ではなく認識	選択肢・アフォーダンスが目に見えるか — 暗記は不要か。指示の壁はこのヒューリスティクスの失敗です。スクロールでズーム・端をドラッグ・ダブルクリックを文章で説明しなければならないなら、アフォーダンスが欠けています。
7	柔軟性と効率	デフォルトが初心者を支えるか; 熟練者向けのショートカット・アクセラレータがあるか; 何も設定していない初回起動が適切か。
8	美的でミニマル	装飾よりもシグナル; 無関係な要素が競合していないか; 主要なサーフェスが最も視覚的な重みを担っているか。
9	エラーの認識・診断・回復	平易な言葉のエラー (生の stderr ではない)、そして抜け出す道があるか。
10	ヘルプとドキュメント	1〜9が守られていればほとんど不要; タスク指向で、文脈に沿っており、ページ冒頭の説教ではないか。

インタラクションの追加項目 (組み合わせるもので、繰り返すものではありません):

• 考えさせない (Krug): アフォーダンスが自明であるか; UI が自らを教えるか。説明の段落 ⇒ アフォーダンスの負債 (#6 に関連)。
• フィッツの法則 / 移動時間 (design-spatial §3): コントロールはタスクがカーソルを離れる場所の近くにあるか。選択されたオブジェクトのプロパティはオブジェクトの隣 (ドック/ポップオーバー) にあるべきで、遠くのパネルではない — 編集のたびに往復するべきではありません。
• ジェスチャーの発見可能性: 自明でないジェスチャー (ホイール、端のドラッグ、ダブルクリック) には目に見えるアフォーダンス (ハンドル、ホバーキュー、アイコン) が必要で、なければほとんどのユーザーにとって存在しないのと同じです。
• 視覚的な重みの一致 (design-spatial): ユーザーが操作するサーフェス (タイムライン、キャンバス、エディター) が視覚的な主役であるべきで、大きな受動的なプレビューの下の細い帯ではありません。
• 段階的な開示 (design-thinking UX): まず本質を; 高度なものは要求に応じて。ただし開示 ≠ 主要なツールを隠すこと。
• ツールチップのタイミング: グループ内の最初のツールチップは遅延させる (~300〜700ms のホバーインテント) ことで、コントロールの上をカーソルでなぞってもチップがちらつきません; ひとつ開いたら、ユーザーが行をスキャンしている間は隣接するものは即座に表示されます (ツールチップごとの再遅延はなし)。ホバーのたびに発火するのはノイズです; 隣ごとに再遅延するのは緩慢です。
• スクロール位置の復元: 戻る/進むはユーザーを元いた場所に戻し、先頭ではありません — 詳細→戻るの往復で場所を失うのは、静かで繰り返される負担です。ブラウザーはデフォルトでこれをします; バグは手動のスクロールリセットやクライアントルーティングが忘れることによってそれを壊すことです。
• 送信時の冪等性: 変更を伴う操作には冪等キーを持たせ、ダブルクリック、リトライ、不安定なネットワークでの再送が効果を重複させないようにする (二重請求、重複投稿)。これは「処理中のリクエストの間は送信を無効化 + スピナー」と対になります — キーはサーバー側の保証、無効化はクライアント側の配慮です。

(ツールチップ / スクロール復元 / 冪等性は Web Interface Guidelines、vercel-labs/web-interface-guidelines @ 4e799d4、2026-04-06 より。)

出力形式

採点済みの表 — Heuristic | Finding (located) | Severity | Fix — その後に優先順位付けされた修正リスト (ブロッカーが最初)。重要度: blocker = タスクを完了できない / 積極的に誤解を招く; major = 遅くするか混乱させる; minor = 磨き上げ。

設計の他の部分との関係

• design-spatial は、レンダリングしてから批評するメカニズム + フィッツの法則/移動 + オーバーフローゲートを担います。このスキルはその視点を特にユーザビリティに適用し、ヒューリスティックスコアカードを追加します。
• design-thinking は UX の原則（ゴール/タスク、IA、フィードバック、アクセシビリティ、プログレッシブディスクロージャー）を担います。このスキルはそれらをスコア付き監査 + 修正ループに変えます。
• インタラクティブな UI を「完了」と宣言する前に、ビジュアル批評と並行して（それの代わりではなく）、ユーザビリティ監査を実行してください。

例

ユーザーからのリクエスト:

@design-ux でこのインターフェースをレビューし、最も影響の大きい設計上の問題を特定し、実装可能な改善案を提示してください。

制限事項

• このスキルは、タスクがその上流のソースとローカルプロジェクトのコンテキストに明確に一致する場合にのみ使用してください。
• 変更を適用する前に、コマンド、生成されたコード、依存関係、認証情報、外部サービスの動作を確認してください。
• 破壊的または高コストな操作については、例を環境固有のテスト、セキュリティレビュー、ユーザーの承認の代わりとして扱わないでください。