prototype

プロトタイプ

実装前に人がデザインを評価できる、使い捨てのプロトタイプを作成します。プロトタイプのコードは一時的なものでもかまいませんが、提示するものはすべて、想定する製品の文脈で信頼できるものでなければなりません。

モードを選択する

• UI モード： 画面、コンポーネント、または短いフローの見た目や操作方法について検討します。以下のプロセスに従ってください。
• ロジックモード： ロジック、状態、データ構造、API、または CLI の動作モデルが実際のケースに対応できるかを検討します。ロジックモードに従ってください。

両方にまたがる場合は、まずロジックモードでモデルを固め、その後 UI モードでインターフェースを検討してください。

UI プロセス

1. 設計上の問いを明確にします。 プロトタイプによって何を判断できるようにする必要があるのか、想定ユーザー、製品を使う場面、主要なタスクと操作、対象プラットフォームまたはビューポート、関連する状態、変更してはならない挙動、時間・コスト・範囲の制約を明示します。方向性がすでに承認されている場合や、依頼が局所的な実装の詳細に限られる場合は、比較しても価値がない理由を説明し、そこで終了します。
2. 共有する事実を確認します。 該当する現行製品、レンダリング済みのベースライン、リポジトリ、デザインシステム、コンポーネント、用語、実際のデータ形式、プラットフォームの慣例を調査します。実際の周辺シェル、情報密度、コンテンツ、実行環境を優先します。shape または別の製品ブリーフに仕様がある場合は、そこからユーザー、課題、状態を採用します。新規製品の場合は、関連性のある参考例を少数追加し、模倣はしません。観察された事実、ユーザーの選択、前提、自由に変更できる点を分けます。
3. 中立なブリーフを1つ確定します。 すべてのデザイナーに、同じユーザー、タスク、正確なコンテンツ、機能、代表的なデータ、各候補のシナリオセレクターに用意する名前付きシナリオ、ビューポート、不変条件、変更可能な点、創作してはならない要素、評価条件を提示します。問題の解釈の違いではなく、デザインを比較できるように、製品に関する事実を固定します。
4. 独立した方向性を作成します。 既定では、異なるモデルファミリーから選ぶことを推奨しつつ、新規のデザイナーエージェントを3つ使用し、最大5つまでとします。それぞれに隔離されたワークスペースと、重複しない探索領域を割り当てます。各デザイナーには、名前を付けた主張を1つ示したうえで、他の候補を見ずに、その方向性を構築、実行、レンダリング、検査し、根拠を提示するよう求めます。それぞれの主張は、構成またはインタラクションモデルに加えて、階層、主要なアフォーダンス、情報密度、開示方法、ナビゲーション、読み進める順序、空間構成など、少なくとも1つの重要な軸でも異なる必要があります。
5. 提示する前に評価します。 すべての候補が完成したら、候補を作成していない新しい評価者を割り当てます。共有ブリーフ、ベースライン、候補一式、レンダリング済みの根拠を提示します。評価者はすべての不変条件を確認し、内容や挙動の創作を禁じ、候補同士を比較して実質的な差異を確認します。候補のセレクターを使って各シナリオを実行し、フィルターの変更、ホバー、スクラブなど、ユーザーのように状態間を移動して、状態、レイアウトシフトのない遷移、実行時の忠実性を検証します。色、タイポグラフィ、角丸、影、イラスト、コピーの変更だけでは、異なる方向性とはみなしません。2つの候補がラフなシルエットの段階でも同等のままなら、一方を不合格にします。
6. 修正は1回に限ります。 評価者は各候補を Pass、Rebuild、Reject のいずれかに判定し、検証可能な理由を示します。不合格候補は、他の実装を見せずに、元のデザイナーが範囲を限定して最大1回だけ再構築できます。結果を再評価します。要求数を満たすための水増しはしません。合格候補が2つ未満の場合は、見せかけの比較を提示せず、不足している根拠または機能を示して Incomplete を返します。
7. 選択できる形で提示します。 合格した候補だけを、同等の閲覧条件で提示します。それぞれについて、名前、主張、重要なトレードオフ、レンダリング済みの根拠、ライブで開くためのリンクまたはコマンドを1つ、既知の制限を示します。評価者は準拠状況や相違点を説明してもかまいませんが、見た目の勝者を選んではなりません。人間に、方向性を1つ選ぶ、具体的なハイブリッドを依頼する、または候補群を却下するよう求めます。
8. プロトタイプを終了します。 選択した方向性と関連する状態、閲覧条件について、曖昧さのないビジュアルリファレンスを保持し、未解決の問いも記録します。ハイブリッドを依頼された場合は、組み合わせた結果を組み立てて提示し、見えるデザインを基に承認できるようにします。実装との比較に使うためこのリファレンスを保持します。選ばれなかった候補は、判断の根拠を保存したうえで削除するか、宣言済みの隔離された探索場所にのみ保持します。起動したサーバーとプロセスをすべて停止し、本番環境向けのソリューションを実装せずに終了します。

UI の忠実度に関するルール

• 使い捨てであることはライフサイクルを表すものであり、視覚的な品質を表すものではありません。粗雑で汎用的なもの、壊れているもの、明らかに未完成な UI を選択肢として提示しないでください。
• 質問に関係する難しいデータ範囲や、空、読み込み中、エラー、長いコンテンツ、レスポンシブの各状態を含め、もっともらしいドメイン固有のコンテンツを使用してください。
• 依頼で変更が明示的に許可されていない限り、実際のアプリシェル、コンポーネント、トークン、用語、動作、プラットフォームの慣習を維持してください。
• すべての候補にシナリオセレクターを含めてください。これは製品 UI の外側に配置し、製品 UI の一部を覆わず、依頼にあるシナリオを名前付きで一覧表示し、いずれのシナリオも読み込めるほか、現在のシナリオを開始時点にリセットできるコントロールです。選択したシナリオを URL に保持し、再読み込みや共有時にもそのシナリオが表示されるようにしてください。人間が 1 つのリンクからすべての状態を操作できるようにします。
• デザインを評価するために必要なインタラクションだけを含めてください。変更操作にはスタブを使い、候補を完全に見せるために機能、コントロール、指標、顧客、主張を作り出さないでください。
• 各候補を想定される実行環境と対象サイズでレンダリングし、確認してください。評価の前に、クリッピング、オーバーフロー、判読しにくい階層、壊れたインタラクション、プレースホルダーコンテンツなど、目に見える不具合を修正してください。
• 必要に応じて製品のプリミティブを共有しても構いませんが、代替案をあらかじめ決めてしまう共通レイアウトを押し付けないでください。ベース候補のスタイルを変更するのではなく、それぞれ独自の設計思想から候補を作成してください。

本番開発の境界

選択によって採用されるのは方向性であり、プロトタイプのコードではありません。候補の一部を再利用する場合も、プロジェクトの通常のプラクティスに従う新たな本番開発作業となり、プロトタイプの品質が引き継がれるわけではありません。

完了基準

ロジックモードには独自の完了基準があります。UI モードの完了基準は次のとおりです。

• 根拠に基づく共通の依頼によって、デザイン上の問いと比較条件が明確に示されていること。
• 少なくとも 3 つの独立した候補を隔離されたワークスペースで作成しようとし、レンダリング結果を新たな評価者が評価していること。
• 提示するすべての候補が、忠実度と候補間の差異の両方に関するチェックを通過していること。省略や再構築の失敗も明示されていること。
• 人間に比較可能な根拠が提示され、各候補のすべてのシナリオを実際に操作でき、方向性の選択、組み合わせ、却下の決定権が保たれていること。
• 候補の扱いとプロトタイプから本番開発への境界が明確であり、本番実装が始まっていないこと。