interaction-design-board

インタラクション設計ボード

インタラクションに関する不確実性を、検証可能な根拠に変えます。プロダクトの実際の事実とデザイン言語は固定したまま、インタラクション構造を十分に変え、プロダクションコードを変更する前にユーザーがトレードオフを体験できるようにします。

リクエストに応じて使い分ける

• 挙動、状態、ワークフロー、階層、または段階的な情報開示によって選択が変わる場合は、このスキルを使います。
• 静的なビジュアルスタイルの調整や画像マトリクスには、design-style-picker を使います。
• プロダクト全体に適用する新しいデザインシステムには gstack の design-consultation を、静的な生成モックアップには gstack の design-shotgun を使います。
• ビジュアルの方向性を選んだ後も、クリック可能なインタラクション構造を比較する必要がある場合は、このスキルに戻ります。
• 仕様が確定した1行の CSS 調整や、ユーザーが承認済みのインタラクション仕様をすでに提供し、実装だけを求めている場合には使いません。

必ず達成すること

ギャラリーではなく、意思決定を生み出します。

1. 実行可能な複数の HTML 候補で、ビジネス上の事実、プロダクトの範囲、デザイントークン、利用可能なアクションを共通に保ちます。
2. 各候補は、見た目だけではなく、異なるインタラクション仮説を具現化します。
3. Design Board では、ユーザーがすべての候補を操作し、具体的なフィードバックを記録し、1つを選択するか、名前を指定してリミックスを依頼できます。
4. ユーザーが挙動を承認するまで、プロダクション実装を開始しません。

静的なスクリーンショットは補助的な根拠にすぎません。スクリーンショットでは、折りたたみ状態、キーボード操作の経路、選択モデル、タスクの引き継ぎを証明できません。

ワークフロー

1. 意思決定の契約を固定する

バリエーションを生成する前に、セッションのワークスペースに簡潔な契約を記述します。

• ユーザーの目的： 実際にオペレーターが完了しようとしているタスク。
• 意思決定の範囲： 比較対象とする1つのページ、コンポーネント、または範囲を限定した一連の操作。
• 変更不可の事実： すべてのバリエーションで保持する必要がある実際のオブジェクト、ラベル、ステータス、権限、アクション、データの意味。
• 既存のデザイン言語： 見分けがつく状態を保つ必要がある現在のトークン、コンポーネント、ナビゲーション、情報密度、ブランド素材。
• 初期表示の不変要素： 情報開示の前に表示しておく必要があるもの。
• インタラクション状態： ユーザーが操作できる必要がある重要な状態。
• 終了条件： バリエーションの承認、または明示的なリミックス依頼。プロダクトはまだ編集しません。

既存のプロダクトでは、契約を記述する前に、レンダリングされたページと実装を確認します。不明な事実を、もっともらしいサンプルデータで置き換えてはいけません。インタラクションの選択に不要な場合は、省略するか、不明であることを明記します。

意思決定によって、すでにリリース済みの画面を置き換える場合は、調査中に現在ユーザーから見える挙動を番号付きの一覧にします。すべてのアクション、状態、ディープリンク、キーボード操作の経路、空の状態、コピー操作を含めます。候補では、そのいずれも後回しにしたり、省略したりできます。一覧を作るのは、省略した挙動が見落とされたデグレードではなく、明示されたトレードオフとなるようにするためです。

候補のアーキテクチャを提案する前に、references/interaction-design-method.md を読みます。ここには、ある方向性が妥当かどうかを判断する階層、段階的な情報開示、比較、アクセシビリティのルールが記載されています。

2. 異なるインタラクションアーキテクチャを提案する

デフォルトでは、候補を3つ提案します。独立したインタラクション仮説がほかにもある場合に限り、候補を追加します。細かなバリエーションでボードを水増ししてはいけません。

各候補について、次の項目を示します。

• ユーザーの目的にどう役立つかについての仮説。
• 何を優先するか。
• 何を後回しにするか、または隠すか。
• 想定されるトレードオフ。
• プロトタイプで動作させる必要がある状態とアクション。

意思決定の契約は固定します。色、コピー、データを一度にすべて変更するのではなく、ナビゲーション、選択、情報開示、アクションの管理主体、情報の順序を変えます。役立つ型には、コマンド優先、キュー詳細、オブジェクト中心、比較中心、台帳優先などがあります。ただし、型を埋めるために候補を作るのではなく、現在のタスクに基づいて候補を導き出します。

3. 独立して実行可能な候補を生成する

セッション用ワークスペースに、候補ごとに自己完結した HTML ファイルを 1 つずつ作成します。ワークスペースは製品のソースツリーの外に配置してください。CSS と JavaScript はインラインにし、実行時のネットワーク依存を避けて、各プロトタイプが Board 内で確実に動作するようにします。

独立したワーカーコンテキストを利用できる場合は、同じ固定済みの判断基準と各候補の仮説のみを用いて、候補を 1 つずつ各ワーカーに割り当てます。ワーカー同士の出力は見せないでください。この分離がテスト時のスケーリングの仕組みとなり、仮説同士が収束して類似するのではなく、互いに異なる状態を保てます。ワーカーを利用できない場合は順番に生成しますが、次の候補に取り掛かる前に、前の候補ではなく固定済みの判断基準を読み直してください。

各候補では、宣言された状態をすべて実装する必要があります。何もしない装飾用ボタンは、インタラクションのプロトタイプではありません。誠実なローカル状態を使用し、製品にないバックエンド応答を模擬しないでください。

4. デザインボードを構築して開く

references/board-contract.md に従って board.json を作成し、次を実行します。

SKILL_ROOT="<absolute directory containing this loaded SKILL.md>"
python3 "$SKILL_ROOT/scripts/build_board.py" \
  --manifest <session-dir>/board.json \
  --output <session-dir>/design-board.html

想定される出力：

BOARD_BUILT variants=<derived count> output=<absolute path>

ビルダーは、バイト単位で同一の候補、パストラバーサル、宣言された状態の不足、静的な外部スタイル、スクリプト、メディアを拒否します。また Board は、すべてのサンドボックス化された候補にネットワークを拒否する Content Security Policy を挿入し、動的な JavaScript が未宣言の実行時依存を作成できないようにします。Board を問題なく動作させるために、候補を修正してください。どちらの境界も緩めないでください。

gstack のデザイン実行ファイルがすでにインストールされている場合は、アクティブな gstack Skill インストールから絶対パスを解決してください。新しいシェルで $D が存在すると仮定しないでください。その後、サーバーが出力した Board の URL を正確に取得します。

GSTACK_DESIGN="<resolved gstack design executable>"
SERVER_OUTPUT="$("$GSTACK_DESIGN" serve \
  --html <session-dir>/design-board.html --timeout 1800 2>&1)"
printf '%s\n' "$SERVER_OUTPUT"
BOARD_URL="$(printf '%s\n' "$SERVER_OUTPUT" | sed -n 's/^BOARD_URL: //p' | tail -1)"
test -n "$BOARD_URL"

実行ファイルを解決できない場合、またはコマンドが BOARD_URL を出力しない場合は、ホストのブラウザー起動ツールで design-board.html を直接開いてください。直接ファイルモードでも引き続き利用できます。Submit と Remix は、エージェントが読み取れるよう feedback.json または feedback-pending.json をダウンロードします。選択を行うのは Board 自体であり、チャットは代替手段にすぎません。

5. 感覚ではなくタスクを観察する

各候補で同じ代表的なタスクをユーザーに実行してもらいます。次の点を記録します。

• 何に最初に気づいたか；
• 次に何をすべきかが分かった、または分からなかった場所；
• どの情報開示が必要な根拠の把握に役立ったか、または妨げたか；
• どの状態遷移が自然、または意外に感じられたか；
• どの要素を残し、却下し、組み合わせ直すか。

こうした観察を数値スコアや、最も洗練された候補が最善だという主張で置き換えないでください。ユーザーは 1 つの候補を選ぶことも、複数の候補の名前付きの部分を組み合わせることもできます。

feedback-pending.json が現れたら、採用された部分を残し、指定された失敗軸を変更して、影響を受ける候補だけを再生成し、同じセッションディレクトリにバージョン付きの Board ファイルを作成します。gstack Board がすでに配信中の場合は、古いソースパスで再度 serve を呼び出さず、その正確な Board を再読み込みします。

curl -sS -X POST "${BOARD_URL%/}/api/reload" \
  -H 'Content-Type: application/json' \
  -d '{"html":"<absolute-versioned-board-path>"}'

想定される応答：{"reloaded":true}。serve を繰り返し呼び出しても、変更後のバイト列を読み込まずに既存の Board インスタンスを再利用する場合があるため、再読み込みの手段にはなりません。同じ Board URL でタスクをもう一度試すようユーザーに依頼してください。フィードバックによって判断が変わらなくなったら、追加のラウンドを終了します。

6. 本番実装前に承認を確定する

ユーザーがフィードバックの要約を確認したら、references/board-contract.md のスキーマに従って、Board の隣に approved.json を作成します。以下を記録します。

• 選択した候補、または組み合わせた候補
• 承認されたインタラクションルールとファーストビューの不変条件
• 却下されたトレードオフ
• ユーザーが実際に操作した状態
• 残っている不明点
• プロトタイプファイルの正確な識別情報

その後に限り、プロダクトに実装します。現在のデザインシステムと実際のデータ契約を維持します。プロジェクトのフロントエンド実装スキルとビジュアル QA スキルを使い、実際のブラウザーで同じ代表的なタスクを検証します。ピクセルの類似性だけでは不十分です。承認された状態遷移と情報の順序を維持する必要があります。

ステップ 1 で動作の一覧を作成した場合、すべての項目に対応内容（維持、変更内容、または削除理由）を記載するまで、実装は完了ではありません。その表は、変更をレビューする人が目にする場所に配置してください。セッション用ワークスペースだけに置いてはいけません。削除した項目は特に重要です。説明のつかない動作は、報告されていないリグレッションであり、それに気づける最後の人は作成者です。意図的に削除した項目数は、最初の確認では誤っているものと考えてください。変更を完了とする前に、一覧と照らし合わせて再確認します。

プロジェクトにデザインの SSOT がある場合は、実装の一環として、承認されたインタラクションの決定をそこに記録します。セッションのフィードバックとプロトタイプファイルは証拠として保持し、変動する内容をプロジェクト全般の指示に転記しないでください。

失敗の境界

• すべての候補を別のプロダクトやデータモデルに変えないでください。
• 静的な画像生成で、実行可能なインタラクションを代替しないでください。
• 判断に必要な場合に、アイデンティティ、現在のステータス、主要な根拠、または次のアクションを段階的な開示の背後に隠さないでください。
• ユーザーが操作する前に、見た目で最善と思われる案を実装しないでください。
• プロトタイプを本番用のコンポーネントディレクトリに書き込まないでください。
• 作成者自身のクリック操作だけを根拠に、ユーザビリティを検証したと主張しないでください。エージェントによる QA では壊れた状態を見つけ、ユーザーのタスク観察によってインタラクションを判断します。

提出

Board のパスまたは URL、候補の仮説、フィードバック／承認アーティファクトのパス、実施したブラウザー検証、そして次のステップを明確に提示します。次のステップは、Board を反復する、承認された候補を実装する、または中止する、のいずれかです。