design-style-picker

デザインスタイル選定

目的

このスキルを使って、漠然とした好みを具体的なビジュアルの選択肢に変えます。目的は最終的なデザインを一つだけ推測することではなく、ユーザーの好みの境界をすばやく明らかにできる、構造化された選択肢を作ることです。

基本ルール

ユーザーが抽象的なスタイルを説明できないと言っている場合は、説明を求めないでください。比較できるビジュアルの根拠を作り、選んでもらってから、選ばれた参考デザインをもとに実装します。

ワークフロー

1. 本当の目標を言い換える

   • ユーザーが実際に選ぼうとしているものを明確にします。デザインシステムのスタイル、業務アプリの画面、ランディングページ、デッキ、コンポーネントライブラリなどです。
   • 方向性を一つ選ぶこと、複数の方向性を残すこと、異なるビジュアル上の役割に方向性を割り当てることを区別します。選択肢が複数あっても、相互排他的とは限りません。両方を残しても、それらをどう共存させるかは決まりません。許可された方向性を探索している間は、採用方法や融合方法についての未解決の選択を保留にします。
   • 主たる成果物と検証用サンプルを分けます。タスクがデザインシステムの場合、業務画面は任意の検証用サンプルであり、主たる成果物ではありません。
   • ユーザーが破棄を明示的に求めない限り、既存の UI、アセット、トークン、レイアウト、ブランドの手がかり、ドメインのコンテキストを維持します。
   • このラウンドで許可された軸以外では、既存の空間構造、ナビゲーション、ズームや詳細のレベル、読み進め方を固定します。プロダクトを発展させる前に、対象となる軸を明示します。スタイル比較をしやすくするためだけに、別のページへと再構成してはいけません。

2. まず既存のアセットを集める

   • 現在レンダリングされている UI またはスクリーンショットを確認します。
   • 構造を示すスクリーンショットを選ぶ前に、その画面の実際の対象範囲と操作レベルがユーザーの目的に合っているか確認します。局所的な詳細画面は、個別画面のタスクでは基準にできますが、ワークスペース全体や、概要から詳細へと進む流れの代わりにはなりません。不足している画面を取得するか、検証済みの仕様を使い、視覚的に確認していない箇所にはその旨を明記します。
   • デザイントークン、CSS 変数、コンポーネント名、主要な画像、ブランドやドメインに関する参考情報、既存のスクリーンショットを確認します。
   • 現在のアセットを出発点となる語彙として扱います。それらと無関係な「新しい」コンセプトを重ねて生成してはいけません。

3. 細かなバリエーションではなく、マトリックスを作る

   • 好みが不明な場合は、許可された軸を少なくとも二つ使います。
     • 縦方向の段階：色の強さを 20／35／50／65／80 のように大きく変える、一つの次元です。
     • 横方向の方向性：データ主導の配色、ブランドの軸、温かみのあるプロダクト画像、シナリオ別モジュール、ガバナンス主導のレイアウトなど、異なる構成戦略です。
   • 選択肢の違いをビジュアルで明確にします。二つの画像が似た印象なら、コントラストがより明確になるように片方を再生成します。
   • まとめて生成することを優先します。ユーザーは選択を待っており、時間のかかる画像を一枚ずつ見ているわけではありません。

4. 色をシステムとして扱う

   • 「色を抑える」とは、白黒にすることではありません。通常は、競合する焦点を減らすことを意味します。
   • プロダクトのカラーパレットは保ちつつ、それぞれの色の役割を割り当てます。
     • アーキテクチャを示す広いゾーンやセクション帯。
     • 複数色の意味づけに対応するデータビジュアライゼーションとエビデンスシステム。
     • まれに使い、強いシグナルとなる強調のためのブランドカラーやリスクカラー。
     • 日常的な UI に使うニュートラルなコンポーネント。
   • ユーザーが色を調整している場合は、明示的な上限サンプルを含めます。安全、中間、高、過剰となる境界です。

5. 提示前にレビューする

   • 生成した画像を自分で開いて確認します。
   • 好みを判断する前に、対象範囲を確認します。ユーザーが求める画面、スケール、状態、操作レベルを確認でき、候補が指定された関係性を維持しているかを確かめます。色や細部の印象を判断する前に、不足している範囲を補います。静止画像は操作レベルを示すものであり、操作の挙動を証明するものではありません。
   • どの候補が「寂しすぎる」「色が多すぎる」「汎用的すぎる」「業務システムらしすぎる」可能性があるか、または目標に最も近いかを記します。
   • 役立つ候補ごとに、ファイルパスと短い判断メモを提示します。

6. 選択した画像をもとに実装する

   • ピクセルではなく原則を抽出します。色の役割、レイアウトの密度、焦点の階層、コンポーネントの扱い、画像の使い方、ガバナンスやデータの配置に注目します。
   • 組み合わせが承認された場合は、選択したリファレンスを明示的に融合します。例：「色の配置には H02 を、パレットの強さには V04 を使用します。」複数の方向性を探索用に残すだけの場合は、保持していることを融合や役割の割り当ての承認と見なさず、そのまま利用できる状態にしておきます。
   • ユーザーが新しい成果物を求めていない限り、実装の範囲は既存の UI に限定します。
   • 実装後に、レンダリング結果のビジュアル QA を実施します。

プロンプトのパターン

画像を生成するときは、次を含めます。

This is an evolution of the existing UI/design system, not a replacement.
Preserve these assets: <tokens, imagery, sections, components, brand cues>.
Target surface and levels: <requested view, scale, states, overview/detail coverage>.
Reference coverage: <what each screenshot proves; missing views or specification-only parts>.
Frozen behavior: <spatial structure, navigation, zoom, reading>.
Direction relationship: <choose one / retain several / approved role assignment; unresolved choices>.
Axis: <vertical ladder or horizontal direction>.
Variant name: <clear label>.
Color/visual rule: <specific budget or organization method>.
Primary focal point: <one thing>.
Avoid: <known rejected styles from the user>.

維持すべき教訓

• ユーザーの「カラフルすぎないで」は、「色の重みが同じ小さなカラーチップを何十個も並べないで」という意味かもしれません。「色をすべてなくして」という意味ではありません。
• ユーザーの「もっと重みを」は、ダークモードのコントロールルームではなく、視覚的な存在感と階層性を指しているかもしれません。
• デザインシステムに関する作業では、システムをビジネスダッシュボードに置き換えないでください。ビジネス画面はスタイルの検証に使えますが、最終的な答えそのものにしてはいけません。
• 意図的に境界となるサンプルを必ず作成してください。「やりすぎ」が見えるようになり、選定をすばやく進められます。
• 組み合わせが承認されたら、選んだリファレンスを融合し、それぞれが何をもたらすのか明示してください。

リファレンス

• スタイル選定のセッションを一通り行うとき、または画像を探る中でユーザーから好みに関する修正があったときは、references/selection-playbook.md を読んでください。