Communityコーディング&開発github.com

プロダクトUX

実際のユーザータスク、情報の優先順位、状態遷移に基づいてプロダクト画面の設計とレビューを行います。新規または変更されたUIフローや煩雑なインターフェースに使用し、UIデザインが不要な非UIタスクではスキップします。

プロダクトUX とは?

このスキルは、AIエージェント(Claude Code、Cursor、Codexなど)向けに設計されたプロダクトUXデザインとレビューのためのガイドラインです。ユーザーの状況と意図する成果を起点とし、既存のデザインシステムやリサーチ結果を尊重しながら、タスク中心の画面設計を支援します。具体的には、プライマリーロールとタスクごとにトリガー、既知情報、判断事項、完了結果、回復経路を特定し、コンパクトなフローと低忠実度レイアウトを生成します。状態とインタラクションのモデリングでは、初期、読み込み中、空、失敗、成功、編集中/未保存、古い結果、権限制約といった関連する状態のみを使用し、ユーザーの作業を保存しながら、静かな変更による驚きを避ける明示的なアクションを推奨します。レンダリングされたフローのレビューでは、実際のブラウザやアプリケーションツールを使用して構造、ラベル、可視状態を確認し、DOMチェックだけに頼らず、視覚的およびユーザビリティ品質を検証します。このスキルは、UIデザインの品質を向上させたい開発者やAIエージェントユーザーに特に有用で、不要な要素を追加せず、アクセシビリティとユーザビリティを重視します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/tkddu1591/product-builder/tree/main/plugins/product-builder/skills/product-ux

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

タスク中心のプロダクトUX

ユーザーの状況と意図する成果から始めてください。既存のデザインシステム、リサーチ、提供されたデザインは証拠です。汎用的なダッシュボードでそれらを置き換えないでください。タスクの種類に応じたパターンと反例を読み、すべてのパターンを読む必要はありません。

画面を構築する前に

主要なロール/タスクごとに、トリガー、既知の情報、判断事項、完了結果、回復経路を特定します。判断内容が異なる場合はロール固有のワークフローを分離し、タスクとコンテキストが本当に一致する場合にのみ画面を共有します。

変更の規模に比例したコンパクトなフローと低忠実度レイアウトを生成します。各可視領域の状態について:

  • この領域は今、どのユーザーの判断またはアクションを必要としていますか?
  • それはプライマリ、コンテキスト詳細、またはこのビューでは不要ですか?
  • どの要件、ソース、または明示的なデザイン決定がそれを正当化しますか?

これを使用して情報を選択し、製品のコピーを追加生成しないでください。概要カード、チャート、バナー、フィルター、ナビゲーション、AI説明、または「近日公開」パネルを自動的に追加しないでください。誰かが関連する判断を行うときにメトリクスが属します。技術的な出所は、新鮮さや妥当性を判断するために必要な場合に属します。デバッグログや実装ステータスは通常、開発記録に属します。

盲目的に最小化しないでください。アクセシビリティの説明、意味のあるエラー、必須のコンテキスト、必要な開示、判断の結果を保持してください。プライマリアクションは有用なデフォルトであり、恣意的な1ボタン制限ではありません。可視コントロールを減らすためだけに、重要なアクションを汎用メニューの背後に隠さないでください。

状態とインタラクション

関連する状態をモデル化します:初期、読み込み中、空、失敗、成功、編集中/未保存、古い結果、権限制約。製品が必要とする状態のみを使用してください。選択された入力と表示された結果は同じコンテキストを参照するようにします。回復可能なエラーではユーザーの作業を保持します。静かな変更がユーザーを驚かせる場合は、明示的なアクションを選択します。

編集サーフェスを選択する場合や状態を持つレイアウトを変更する場合は、インタラクションパターンの選択を読んでください。タスクの複雑さ、頻度、コンテキストの必要性、利用可能なスペースに基づいて、インライン編集、ダイアログ、専用ページのいずれかを選択します。レイアウトのバグを隠すためだけにモーダルを使用しないでください。意味のあるコントロールの前後位置、スクロール、フォーカスを確認します。意図的な開示によってコンテンツが移動することはありますが、偶発的なジャンプやターゲットの消失は修正が必要です。

プロジェクトのトークン、コンポーネント、言語、アクセシビリティの規則を使用します。利用可能なサポートツールを通じて提供された参照を検査します。Figma MCPがないだけでは停止理由になりません。未検査のデザインをマッチしたとラベル付けしないでください。小さな変更のために新しいコンポーネントライブラリを導入しないでください。

有効/エラー/回復状態全体でアクセシブルな名前と説明を確認します。視覚的な可視性とフォーカスだけでなく、アクセシブルな説明によって参照されるときに隠されたメッセージも公開される可能性があります。エラーテキストは、エラーが適用される場合にのみ接続します。

レンダリングされたフローをレビューする

利用可能なブラウザまたはアプリケーションツールを使用して、実際のエントリポイントからタスクを実行します。ラベルとコントロールの構造、およびレンダリングされたスクリーンショットの階層、クリッピング、間隔、視覚状態を検査します。自動化されたアクセシビリティまたはDOMチェックだけでは、視覚的またはユーザビリティ品質を証明できません。

レスポンシブチェックの場合、ブラウザの実際のビューポート寸法を確認し、最終キャプチャ画像を検査します。スクリーンショットのトリミング、要素の幅の変更、または水平オーバーフローの確認だけでは、同等のビューポートテストにはなりません。ツールがビューポートを設定または確認できない場合は、そのカバレッジを未検証としてマークします。スクリーンショットを報告された結果と照合します:不足しているコンテンツ、使用不可能な折り返し、または非表示のアクションは、DOMチェックが合格したからといって視覚的合格と呼ぶことはできません。

各所見について記録:再現→観察された動作→ユーザーへの影響→最小限の有用な修正→再チェック。推測は観察から分けてラベル付けします。説明を追加する前に、削除、移動、統合、またはデフォルトの改善を優先します。変更や残された懸念事項がそれを正当化しない限り、合格したレビューを繰り返さないでください。

ブラウザアクセスが利用できない場合は、コード/レイアウトの証拠をレビューし、ランタイムUXは未検証としてマークします。独立した作業を続けてください。スクリーンショット、クリック、またはユーザー検証を偽造しないでください。開発者またはエージェントのレビューはユーザー調査ではありません。

関連スキル