Communitygithub.com

ウェブサイト完全性

SaaS、代理店、ローカルサービス、スタートアップ、Eコマース、エンタープライズ、ラグジュアリーブランド向けに、証拠に基づいた推奨事項とプレイブックを使用して、Webサイトとランディングページの計画、構築、批評、監査を行います。

ウェブサイト完全性 とは?

このスキルは、ユーザーがWebサイト、ホームページ、ランディングページ、マーケティングページ、オンラインストア、またはサインアップやチェックアウトなどのサイトフローを作成、デザイン、再デザイン、レビュー、監査、または改善したい場合に使用します。ユーザーが「サイトを作って」と言ったり、URLやスクリーンショットを共有しただけの場合でも、このスキルがサイトの内容と機能を決定し、利用可能な場合にはUX/UIキットスキルにコンポーネントコード、デザイントークン、ビジュアルスタイリングを引き渡します。このスキルは、3つの品質レイヤー(基盤:アクセシビリティ、パフォーマンス、技術的信頼性; コア:明確さ、タスク達成、ナビゲーション、有用なコンテンツ、信頼、ビジネスパス; 表現:ブランドアイデンティティ、ストーリーテリング、ビジュアルクラフト、インタラクション)に基づいて評価します。トレードオフを解決するための優先順位、証拠の不確実性を扱うためのラベル付けシステム、および推奨事項を優先順位付けするための定性的なティアを提供します。スタンドアロンのコンポーネント、トークンパイプライン、ダッシュボードなどのアプリ内製品画面、またはネイティブアプリUIには使用しません。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Atharva-Git01/website-excellence/tree/HEAD/website-excellence

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

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

ドキュメント

ウェブサイト完全性 は何をしますか?

ユーザーが、明確で、有用で、信頼でき、アクセシブルで、ビジネスに特化したウェブサイトを計画、構築、改善するのを支援します。ユーザーが繰り返し説明する前に、提供された資料を調査します。リクエストに必要な深さと範囲のみを使用します。

品質モデル

3つの相互に関連するレイヤーを評価します。

  • 基盤: アクセシビリティ、パフォーマンス、レスポンシブ動作、技術的信頼性。
  • コア: 明確さ、タスク達成、ナビゲーション、有用なコンテンツ、信頼、ビジネスパス。
  • 表現: ブランドアイデンティティ、ストーリーテリング、ビジュアルクラフト、インタラクション。

基盤 × コア × 表現 は、どのレイヤーの深刻な弱点も全体的な体験を損なう可能性があることを思い出させるものです。これは思考モデルであり、数値的な公式ではありません。

トレードオフをこの順序で解決する

  1. ユーザーの範囲、技術的制約、および適用される要件を尊重します。WCAG 2.2 AA を強力なデザイン目標として扱います。関連する管轄区域と範囲を知らずに法的遵守を主張しないでください。
  2. ユーザーの理解、アクセス、安全性、タスク完了を保護します。頻繁なインタラクションを認識可能にし、コスト、エラー、選択肢、結果を明確にします。
  3. 誠実な選択やユーザー制御を損なうことなく、意図されたビジネス成果をサポートします。
  4. ボイス、アートディレクション、証拠、コンテンツ、目的のあるインタラクションを通じて、体験をそのブランドに固有のものにします。
  5. メインパスが機能した後で、タイポグラフィ、スペーシング、色、モーション、ディテールを磨きます。

独創性が馴染みのあるタスクを難しくする場合は、インタラクションパターンを維持し、その周りでブランドを表現します。サイトが使いやすいが一般的な場合は、そのボイス、イメージ、証拠、ビジュアル言語を開発します。誰かが「プレミアム」を求めてきた場合、エフェクトを提案する前に、弱みがポジショニング、タイポグラフィ、写真、コンテンツ、サービスの証拠、またはクラフトのいずれであるかを判断します。カート、アカウント、検索、ナビゲーション、製品比較、チェックアウトのパターンは、オーディエンスの証拠が変更をサポートしない限り、慣れ親しんだものに保ちます。

ダークパターン、偽の緊急性、隠れた料金、混乱を招く同意、キャンセルへの障壁を推奨しないでください。理解、フィードバック、オリエンテーション、タスクパフォーマンス、または意図的で軽量なブランドモーメントを向上させないモーションには疑問を投げかけます。

タスクモードを選択する

要求されたモードを特定し、work-modes.md のワークフローに従ってください。狭いリクエストを完全な監査に変えず、ユーザーが動作するサイトを求めたときに計画で止まらないでください。

  • ウェブサイトまたはページを構築する
  • クイック批評
  • 完全なウェブサイトまたはフロー監査
  • 再デザイン戦略
  • ページ設計図または情報アーキテクチャ
  • ビジュアルまたはブランドディレクション
  • コンバージョン最適化
  • 実装またはデザインレビュー

ビジネスタイプのガイダンスについては、storytelling-and-site-playbooks.md の該当するプレイブックを読み込んでください。SaaS、コマース、エンタープライズ、代理店、サービス、スタートアップ、ラグジュアリーサイトでは、ユーザーの質問と成功パスが異なります。

このスキルが決定することと引き渡すこと

このスキルは、ウェブサイトレベルの決定(オーディエンス、ページの目的、構造、メッセージング、証拠、信頼、コンバージョンパス、品質基準)を所有します。構築自体については、セッションで利用可能な場合は ux-ui-kit スキルを使用します。これらのスキルはトークンシステム、フレームワークアダプター、レンダリングチェックを実行するためです。利用できない場合は、work-modes.md の「構築」モードのデフォルト設定に従ってください。

作業の一部使用するスキル(利用可能な場合)
ポジショニングが明確になった後の、名前付きのルックまたはアーキタイプapply-aesthetic
新しいブランドの基盤:パレット、タイポグラフィ、トークンbrandkit、次に design-tokens
選択されたスタックでのページまたはコンポーネントコードdesign-code
スクリーンショットまたはモックアップからの再構築image-to-code
再デザイン戦略後の、既存コードベースのビジュアルアップグレードredesign
インターフェースマイクロコピー:ボタン、エラー、空の状態、フォームラベルux-writing
基準ごとのWCAG監査a11y-audit
Core Web Vitals とローディング作業performance
単一画面またはコンポーネントのスコア付きレビューdesign-review

引き継ぎが別のことを示唆する場合でも、このスキルの優先順位を維持します。ユーザータスクの成功とアクセシビリティは美学よりも優先され、サイトレベルの発見事項は加重スコアではなく定性的なティアを使用します。

不確実性を扱う

読者が仮説を検証された発見と誤解する可能性がある場合は、常にこれらのラベルを使用します。

  • 観察された事実: 提供されたページ、ファイル、コード、またはキャプチャされた動作で直接確認できるもの、または名前付きツールで直接測定されたもの。何をどの範囲で調査したかを述べます。
  • 研究でサポートされたリスク: 関連する研究または標準において困難と関連付けられたパターン。テスト可能な懸念事項を提起します。このサイトのユーザーが失敗していることを証明するものではありません。
  • 推論: 不完全なコンテキストに基づく合理的な説明。前提とその確認方法を述べます。
  • 確定診断: 直接的でタスクに関連する証拠が、テストされた範囲について特定の問題を確認します。証拠を明記します。小規模なユーザビリティラウンドで、それらの参加者がその問題に遭遇したことが確認されますが、全顧客にどの程度一般的であるかは確認されません。ビジネス効果や因果関係を主張するのは、適切な分析、実験、またはその他の因果関係の証拠がそれをサポートする場合のみです。

重大度と確信度は分けて扱います。深刻な潜在的な障壁は、確信度が低くても緊急の検証が必要になる場合があります。目に見える問題は、深刻でなくても確実である可能性があります。スクリーンショットだけでコンバージョン損失、ユーザーインテント、または原因を推測しないでください。

研究と外部ガイダンスについては、証拠の強さが決定に影響を与える可能性がある場合に証拠ラベルを使用します。

  • 標準/要件: 権威ある標準を引用し、関連するレベル、範囲、例外、管轄区域を特定します。
  • 強力な証拠: 十分にサポートされた関連性のある発見。研究が実際にカバーしている結果と母集団を述べます。
  • 限定的/文脈的証拠: 狭い範囲、古い、観察的、自己報告、またはその他の文脈に縛られたソースからの発見。主な限界を明記します。
  • 実用的ヒューリスティック: デザイン判断のための有用な出発点。測定されたしきい値や普遍的なルールではありません。
  • 現在の慣習またはトレンド: カテゴリ、オーディエンス、デバイス、または時間によって異なる可能性のあるパターンまたは流行。

すべての文にラベルを付ける必要はありません。読者が特定の主張の確実性や一般性を誤解する可能性がある場合に、重要な主張と推奨事項にラベルを付けます。これらの情報源の強さのラベルは、特定のウェブサイトについて知られていることに関する上記の4つのラベルとは別のものです。参考ファイルは同じ5つのラベルを角括弧で囲んで使用します。

構築するときは、決定を下して先に進みます。重要な前提は一度だけ、簡潔に引き継ぎに記載します。これらのラベルはユーザーが比較検討する必要のある推奨事項のために残し、コード、コメント、ページコピーには含めません。

信頼できる証拠が矛盾する場合、意見の相違を隠したり、好ましい結論をサポートするソースのみを選択したりしないでください。方法、日付、母集団、コンテキスト、タスクを比較します。重要な不確実性を説明します。それが影響の大きい推奨事項を変える可能性がある場合は、最もリスクの低いオプションを優先するか、適切な検証方法を提案します。

推奨事項の優先順位付け

定性的なティアを使用します。加重合計、固定カットオフ、または未検証のスコアで精度をでっち上げないでください。

  • クリティカルブロッカー: 主要なタスクが不可能であるか、重大な安全上の問題、誤解を招く、排除的、または経済的に有害である。または深刻な法的/セキュリティ/アクセシビリティリスクが明らかである。
  • ハイインパクト: 重要なパスまたはセグメントに実質的な摩擦、誤解、または信頼の喪失が影響し、意味のある裏付け証拠がある。
  • 二次的な改善: 限られた影響で、有用な明確さ、一貫性、または効率の向上をもたらす。
  • オプションの洗練: 確信度が低い、リーチが低い、または主に表現的な実験。

ティア内では、影響を受ける人数と訪問数、タスクの重要度と頻度、証拠の確信度、労力を考慮します。安価な磨きの前にブロッカーを修正します。確信度が高い、中程度、または低いことを、ユーザーが最初に何を検証すべきかの判断に役立つ場合に別途示します。

推奨事項の潜在的なビジネスまたはユーザーへの影響が高いが確信度が低い場合は、それを仮説として特定し、検証するための適切な方法(タスクベースのユーザビリティ調査、分析レビュー、アクセシブルなインタラクションチェック、フィールドパフォーマンス測定、または管理された実験など)を推奨します。仮説を約束された成果に変えないでください。

コンテキストと分析

利用可能な場合は、提供されたURL、スクリーンショット、デザイン、コピー、分析、またはコードを使用します。1つの欠落した事実が推奨事項を変える可能性がある場合は、その重要なコンテキストのみを最大3つの簡潔な質問とともに尋ねます。有用な作業を進められる場合は、停滞する代わりに前提を述べます。

分析では、オーディエンス、エントリーポイント、ページの目的、タスク、ビジネス成果、制約を確立します。初回来訪者とリピーターの両方について、考えられる質問、アクション、リスク、回復パスをトレースします。次に、ユーザーが誤解したり、方向性を失ったり、オファーを信頼しなくなったり、障壁に直面したり、失敗したりする可能性のある最も早いポイントを見つけます。基盤、コア、表現をチェックし、関連するモバイルレイアウトとインタラクション状態を含めます。再デザイン作業では、既にユーザーまたはビジネスをサポートしているものを特定し、証拠、ユーザーニーズ、目標、または明確なデザイン上の問題が変更を正当化しない限り、それを維持します。Eコマースの場合は、検索、カテゴリ、フィルター、比較、製品詳細とバリアント、カート、配送/返品、支払い、注文確認を考慮します。これらの詳細が重要な場合は、trust-conversion-and-commerce.md を使用します。

現在の法律、標準、プラットフォームの動作、指標、および時間に敏感な例を、それらが重要である場合に検証します。元の研究、公式標準、および一次文書を優先します。ソースが実際にサポートしているもの(サンプル、日付、市場、方法を含む)を説明します。専門家のアドバイスはヒューリスティックとして、調査は自己報告として、自動スキャンは部分的な検出として、受賞例はタスクやビジネス成果ではなくクラフトの証拠として扱います。

概念的な推奨事項と検証された結果を区別します。期待される利益は、測定されるまで仮説として扱います。デザインまたは実装の変更がパフォーマンス、アクセシビリティ、ブラウザ互換性、コンバージョン、またはその他の成果を改善したと主張しないでください。ただし、関連する動作が直接テストまたは検証された場合を除き、そのチェックの範囲を述べます。

回答をリクエストに合わせる

デフォルトでは最小限の有用な回答にします。クイック批評は通常、いくつかの十分にサポートされた発見のみを必要とします。焦点を絞った質問には、焦点を絞った応答が必要です。完全な監査、戦略、または実装計画は、要求された場合、または述べられた目標に必要な場合にのみ提供します。短いリクエストを完全な理論レビューで水増ししないでください。構築作業の場合、成果物は動作するサイトまたはページです。付随するメッセージは、構築されたもの、行われた前提、ビジネスが埋める必要のあるプレースホルダー、および実行されたチェックのみに留めます。

最も重要な結論から始めます。重要な推奨事項については、以下を明確にします。

  1. 何が観察されたか、またはどのような前提が立てられているか。
  2. 誰、またはどのタスクが影響を受け、なぜそれが重要なのか。
  3. 具体的にどのような変更を行うのか。
  4. 変更を適切に検証する方法。

ブロッカーとハイインパクトの修正をオプションのアイデアから分離します。研究、標準、法律、または現在の動作に関する主張を引用します。好み、トレンド、ヒューリスティック、または賞を科学的証明として提示しないでください。推奨事項を埋もれさせずに、トレードオフと不確実性を可視化します。「モダンにする」「良い色を使う」「ホワイトスペースを追加する」などの一般的なアドバイスは避け、各提案をオーディエンス、タスク、および調査された証拠に結び付けます。

重要な推奨事項を送信する前に、簡単な一貫性チェックを行います。各推奨事項は述べられた問題に対処していますか、確信度は証拠と一致していますか、ヒューリスティックが普遍的な法則として述べられていませんか、アクセシビリティとパフォーマンスが不当に犠牲にされていませんか、優先度の高い問題が外観の改善の前に来ていますか、応答の深さはリクエストに一致していますか。

関連する参照のみを読み込む

関連スキル