html-prototype

HTML プロトタイプ

プロダクトの意思決定に役立つ、信頼性の高いモデルを作成します。定型のスタイルを毎回適用するのではなく、ユーザーの状況に合わせて成果物を作ります。あらゆる画面を作ることが目的ではありません。重要な視覚上または動作上の疑問を検証可能にすることが目的です。

再現度モードを選ぶ

次の2つのモードのいずれかを使用します。

• モックアップ： 未解決の疑問が視覚的な階層、レイアウト、タイポグラフィ、色、またはプロダクトとの適合性である場合、洗練されたレスポンシブな、ほぼ静的な成果物を作成します。
• プロトタイプ： 未解決の疑問がナビゲーション、入力、状態変化、フィードバック、復旧、または遷移である場合、動作するフローを作成します。

独立した html-mockup スキルは作成しないでください。モックアップをより完成したように見せるためだけに、動作を追加しないでください。ユーザーが両方のモードを求めている場合は、再現度の違いを簡単に比較できるよう、同じコンテンツと構造を維持してください。

コンテキストから方向性を導き出す

デザインの前に、会話、提供された参考資料、プロジェクトを確認します。デザインシステムのドキュメント、トークン、既存のコンポーネント、プロダクトのスクリーンショット、関連する成果物を探します。

判断の優先順位は次のとおりです。

1. ユーザーの明示的な視覚および機能に関する指示。
2. プロジェクトで確立されたデザイン言語とインタラクションの慣例。
3. プロダクト、対象ユーザー、コンテンツ、シナリオ。
4. 独自のデザイン判断。

コーディングを始める前に、次の点を決めます。

• ユーザーと、達成すべき重要な作業。
• レビュー対象となる、範囲を限定したシナリオ。
• モックアップかプロトタイプか。
• 視覚的な方向性の根拠。
• 関連する状態モデル。
• 実際のプロダクトに引き継がれる箇所。

デザインシステムがない場合は、題材とユースケースに合った具体的な方向性を作成します。グラデーション、ダークなダッシュボード、どれも同じようなカード、装飾的な指標を安易に使わないでください。現場ツール、編集ワークフロー、財務承認のプロトタイプが、同じプロダクトのように感じられてはなりません。

design-artifact が利用でき、視覚的な方向性がまだ決まっていない場合は、それを読んでこのスキルと組み合わせてください。デザインのトーン、パレット、書体、構成を選ぶ際に活用し、再現度、状態、インタラクションの完成度についてはこのスキルを優先してください。

信頼できる体験の範囲を定める

レビューの疑問に答えられる、最小限のフローを選びます。現実的で、互いに矛盾しない名前、日付、ステータス、数量、文言を使用します。

• モデル化した範囲内でナビゲーションが機能するようにします。
• フォームにはラベル、バリデーション、送信時のフィードバック、適切なデフォルト値を設けます。
• 中断や確認がシナリオに含まれる場合にのみ、ダイアログを使用します。
• 遷移は連続性や状態変化を明確にするために使い、装飾目的では使わないでください。
• 機能しないボタンは削除します。実際のシステムに属するアクションについては、完了したふりをするのではなく、その境界を説明してください。

関連する状態をモデル化する

作成前に状態を一覧にします。選択したシナリオで実際に到達できる状態を含めます。

• 読み込み中。
• 空。
• エラー。
• 成功。
• 無効。
• モバイル。
• 依頼内容に含まれる、ドメイン固有の状態。

非同期に見えるプロトタイプのアクションでは、通常、読み込み中、成功、失敗または復旧を表示します。コレクションでは通常、空の状態を検討します。条件付きのアクションが無効な場合は、その理由を示します。チェックリストを満たすためだけに、関係のない状態をメインフローに無理に含めないでください。省略した状態は引き継ぎ時に明示してください。

インタラクションを完結させる

• 適切なセマンティクスを提供する場合は、ネイティブ要素を使用します。
• モデル化したフロー全体をキーボードで操作できるようにします。
• フォーカスを視認できるようにし、意味のある状態遷移の後に適切な位置へ移動させます。
• ダイアログにはアクセシブルな名前を付け、フォーカスをダイアログ内に留め、Escapeで閉じられるようにし、トリガーにフォーカスを戻します。
• フォームのエラーを対応するコントロールに関連付け、重要なステータスの変化を通知します。
• ホバー時にしか使えない重要な動作を設けないでください。
• prefers-reduced-motionを尊重しつつ、状態のフィードバックを維持します。
• タッチターゲットを操作しやすくし、ページ全体に意図しない横スクロールが発生しないようにします。

モックアップモードでは、コントロールが未接続であっても、セマンティックな構造と視認可能なフォーカススタイルを維持します。静的なレビューの対象範囲を明確にしてください。

ビルドの要件

• 必須のCSSとJavaScriptをインラインに含めた、自己完結型の.htmlファイルを1つ納品します。
• ビルドツール、認証、稼働中のAPI、外部サービスは不要とします。
• デスクトップ用のキャンバスを縮小するのではなく、レスポンシブな構成にします。
• 選んだ方向性に合わせて、デザイントークンを少数かつ具体的に保ちます。
• アクセシブルなコントラストを確保し、状態の伝達には色だけに頼らないようにします。
• 架空のプロダクト全体に手を広げるより、1つのフローを深く、正確に仕上げることを優先します。

検証と引き継ぎ

成果物を、デスクトップの広い画面幅とモバイルの狭い画面幅でテストします。モデル化したすべての状態とコントロールを操作します。ダイアログではTab、Shift+Tab、Enter、Space、該当する場合は矢印キー、およびEscapeをテストします。コンソール、ページのオーバーフロー、長いコンテンツ、無効状態の動作、フォーカスの復元、モーション軽減モードを確認します。

すべての異なるサーフェスで、特に暗色または色付きの領域内で本文の色を継承する可能性があるテキストについて、前景色と背景色の計算済みスタイルを確認します。ブラウザーツールを利用できない場合は、ソースの確認を代わりとせず、未検証のまま残っている視覚的な確認とインタラクションの確認を明記してください。

絶対ファイルパス、忠実度モード、モデル化したシナリオ、実装した状態、意図的に除外した本番環境での動作を記載して返します。

参考資料

承認済みの構造からモックアップまたは動作するプロトタイプへ進める方法については、Plannotator のコーディングエージェント向けHTMLワイヤーフレームとプロトタイプをお読みください。