chiaroscuro

Chiaroscuro

ユーザー向けのウェブインターフェイスを、依頼から完成して動作する実装まで仕上げます。プロダクト本来の言葉を使い、実際のコンテンツと挙動を反映し、システムの裏側を露呈させたり、余計な装飾を付け加えたりせず、明確なビジュアルの方向性を持たせます。

これを使って、コンポーネント、領域、ページを構築したり、既存のインターフェイスの階層、仕上がり、磨き上げの水準を高めたりできます。完成したデザインを1つ制作します。ほかの作業には、それぞれ専用のスキルがあります。

• 複数のページ案から選ぶ場合：maquette；
• スクロールするドキュメントアプリを固定のアプリシェルに変える場合：armature；
• 小型ノートパソコン、タブレット、スマートフォンに対応するレスポンシブ調整を行う場合：reflow；
• Paper でモックアップを作る場合：paste-up。

依頼された UI が実際の文脈で動作し、デスクトップとスマートフォンの両方で適切に見え、既存の挙動も保たれていれば、作業は完了です。

絶対ルール

これらのルールは、ヘルパーに任せる作業も含め、作業のあらゆる部分に適用されます。プロダクトにすでにあるスタイルも例外ではありません。対象範囲内で修正し、そのことは対象範囲外で伝えてください。ユーザーから明示的な指示がある場合に限り、ルールより優先されます。

1. スモールキャップ、字間を広げた大文字、装飾的な等幅書体は禁止です。 小見出し、前置き、セクションラベル、チップ、表見出しに大文字を使わないでください。等幅書体は、文字を確認する必要があるリテラルなコード、識別子、値にのみ使用し、ラベルや見出しには使いません。正式な略語は大文字のままにしてください。
2. インターフェイスがある場所に説明文を置かないでください。 画面を説明する段落が必要なら、その画面は失敗です。ラベル、コントロール、値、または何もない状態に置き換えてください。プロダクト UI では、見出しは物事の名前を示し、目立たせたりセクションを導入したりするものではありません。同意、制約、エラーからの復旧に関する内容のみ残してください。
3. 選んだ書体で、4〜6種類の文字スタイルを使ってください。 プロダクトで定義されている役割を使用してください。既存の役割では対応できない用途がある場合に限り、新しいサイズやウェイトを追加できます。新しい書体は typecase のフォント推奨から選び、使用禁止リストにあるものは決して使わないでください。Instrument Serif はそのリストの先頭にあります。
4. 作る前に再利用してください。 このプロダクト内と、ユーザーが指定したパッケージやプロジェクト内で、目的を果たす既存のコンポーネント、シェル、ヘッダー、コントロールを探して使用してください。既存のコントロールを別バージョンで作るのは不具合です。
5. それぞれ1つにしてください。 同心状に入れ子になった角丸のスケールを1つ、ストロークの太さを統一したアイコンファミリーを1つ、密度ごとにコントロールの高さを1つにしてください。
6. タッチターゲットは、少なくとも CSS ピクセルで 44 × 44 にしてください。
7. 完了と判断する前に、実際に見てください。 実際のブラウザーで操作経路をたどり、ユーザーの視点でデスクトップとスマートフォンの各画面全体を確認してください。静的チェックでは、動作することも見た目が適切であることも確認できません。

最初から最後まで作業する

1. プロダクトとタスクを調査する

プロジェクトの指示、プロダクトとブランドのドキュメント、該当するルートとコンポーネント、既存のトークン、実行可能なインターフェイスを確認してください。次の点を特定します。

• ユーザーの目的と主要な操作経路；
• 実際のコンテンツ、データ、状態；
• 確立されているシェル、グリッド、コンポーネント、用語；
• 技術的な制約とスタイリングシステム；
• 変更してはならないもの。

まず、孤立した状態でビジュアルテーマを考案してはいけません。ユーザーのタスク、プロダクトの制約、インターフェイスの対象範囲を、具体的な数文で説明できる状態にしてください。

フローの場合、画面を描く前に具体的なシナリオを1つたどってください。ユーザーが何を入力し、何を変更せずに保ち、何を選び、どのような結果を得て離れるのかを確認します。意味の異なる入力は区別してください。役に立つ最終状態を定めたうえで、そこに至る遷移を順に設計します。対象を限定した編集の場合は、既存の操作経路における位置を確認してください。プロダクト全体を見直す必要はありません。

2. 関連するリファレンスのみを読み込む

references/interface/index.mdを読み、このタスクに必要な分岐だけを開きます。

• モーションについては、まずreferences/interface/animation.mdを参照します。インストールされている場合は、モーションの専門的な技術にzoetropeを使い、最新のAPI情報についてはライブラリ独自のドキュメントを参照します。
• UIの文言を作成または変更する場合は、言葉によってレイアウトが形作られる前に、インストールされていればsignageを使います。そうでない場合は、ここでその基本的なテストを適用します。つまり、対象ユーザーにこの表現を使って、説明なしで伝わるでしょうか。ラベルは具体的にし、コントロールの代わりになる文章は削除します。
• グラフやデータビジュアライゼーションの集合を扱う場合は、references/interface/charts.mdを読み込みます。

リファレンスファイルはルーターであり、チェックリストではありません。デフォルトですべてのルールファイルを読み込まないでください。

3. 見た目を決める

スタイルを決める前に、プロダクトの形を固めます。目的を絞った単機能のエクスペリエンスでは、画面には対象だけを表示し、それ以外はほとんど表示しません。デフォルトではヘッダー、ナビゲーション、タイトルを設けません。永続的なシェルが必要なのは、ユーザーが複数の場所を移動したり、複数のペインをまたいで作業したりする場合に限られます。

次に、階層、タイポグラフィ、色の扱い、密度、インタラクションの特性を、1、2文で見た目として決めます。実装を制約できるほど具体的なものにし、ムードボードの標語のような表現は避けます。

スマートフォン向けは、デスクトップ版を縮小したものではなく、独自のデザインとして構成します。主要なアクションは親指が届く位置に置き、中央配置のモーダルではなくシートを使い、メディアは画面いっぱいに表示し、一度に表示するコントロールを減らし、表示サイズも小さくします。

提供されたデザインや承認済みのレビューで示された、いくつかの重要な判断を実装に反映します。何を主役にするか、何を控えめにするか、何を表示し続けるか、アクションと補足情報をどう結び付けるかを反映します。コンポーネントのデフォルト設定でもこれらの判断を保ちます。使いやすいバリアントがあるからといって、構成を変える理由にはなりません。

別のインターフェースの美的要素を取り入れる場合は、タイポグラフィ、質感、密度、コントロールの扱いなど、借用する特徴を明示します。対象プロダクトのタスク、オブジェクト、状態遷移はそのまま維持します。見た目を似せただけでは、元のアプリが引き続き機能することにはなりません。

4. Tailwind v4で実装する

新しいプリミティブを作成する前に、プロジェクトのコンポーネントと規約を使います。散在する任意の値ではなく、Tailwind v4のユーティリティ、バリアント、@themeトークンを通じて視覚的な判断を表現します。v4の導入によってパッケージマニフェスト、ビルド設定、グローバルCSSのエントリーポイントが変わる場合は、移行を提案して、まず確認を求めます。範囲を限定したUIの依頼を、リポジトリ全体のスタイル移行に広げてはいけません。

最初のフレームだけでなく、安定した状態を実装します。意図しないレイアウトシフトを防ぎます。後から表示されるラベルやコントロールのためのスペースを確保し、状態に応じて変わる境界線はボーダーではなくリングやインセットシャドウで描画し、同じ行のコントロールは高さを揃え、画像には固定の比率を設定します。キーボード操作ではネイティブのフォームセマンティクスを維持し、フォーカスは常に見えるようにして、表示範囲内へ移動させます。クリッピングによって意図しないスクロールコンテナーが生じないようにします。

5. 描画されたエクスペリエンスを検証し、洗練させる

変更対象の正確なルート、ビューポート、状態で実際のアプリを実行し、ユーザーの主要な操作経路を最後まで確認します。必要に応じて、次の点を確認してください。

• デスクトップとスマートフォンのレイアウト；
• キーボードとポインターでの操作；
• フォーカス順序、フォーカスの視認性、セマンティクス、アクセシビリティツリー；
• 長文、空、読み込み中、失敗、成功の各状態；
• コンソールエラーと失敗したネットワークリクエスト；
• 永続化と、ユーザーの操作が後続に及ぼす影響；
• モーションの中断と視差効果を抑える設定での動作；
• ダークモードでのコントラストと実際のラスター画像アセット。

ズームアウトして全体を見直します。 最初の全体構成ができた後と、大きな変更を加えた後に、ビューポート全体と連続する状態をまとめて見ます。最初に目を引くのは何でしょうか。それはユーザーが注目すべき対象でしょうか、それともその周囲のコントロールでしょうか。次の操作は明確でしょうか。最も目立つ問題は構成にあるでしょうか。細部を磨く前にそれを修正し、局所的な修正で全体の一貫性が失われたら構成を見直します。技術的なチェックに合格しても、こうした問いへの答えにはなりません。

インストールされていて、リスクに見合う場合は、より深いブラウザーQAには fieldtest を、画面サイズ全体を通した確認には reflow を使用します。

6. クリーンアップして報告する

作業で導入した一時的なラッパー、非表示の分岐、抑制設定、未使用のインポートを削除します。変更内容、実施した操作と確認した項目、そして正直な制約事項を報告します。静的チェックしか実行していないのに、ブラウザーで確認したと主張してはいけません。

デザインと品質のガードレール

• 本物の製品コンテンツを使います。仮のキャッチコピーや汎用的なダッシュボードデータは、デザイン上の問題を覆い隠します。
• 製品独自の画像を使い、明るさ、比率、トリミングを揃えて、一貫したセットにします。適切な画像がない場合は、ストック画像や不適切な被写体を使うより、画像を使わないほうがよいでしょう。
• 通常のUIテキストには文頭のみ大文字にする表記を使います。数値を揃える場合は、等幅フォントではなく本文フォントの表形式の数字を使います。
• アイコンの意味が明確でない場合は、アクセシブルな名前を付けるか、隣にラベルを配置します。
• 見た目のコントロールをすべて大きくするのではなく、見えないパディングでタッチターゲットを広げます。
• 数学的な中央揃えが不自然に見える場合は、視覚的な形状を目で見て揃えます。
• ありがちなAIのデフォルトを避けます。角丸カードの積み重ね、むやみなグラデーション、光る境界線、装飾的なピル、大きすぎるヒーローコピー、製品UI内のエディトリアル風見出し、装飾的なステータス表示などです。
• ダークモードでは、色を反転するのではなく、コントラストの関係を組み立て直します。明るいモード用のラスターアセットが適さない場合は、ダークモード用のバリエーションを使います。
• モーションには目的、発生元、中断時の動作、頻度の上限、視差効果を抑える設定への対応が必要です。演出より、素早いフィードバックと体感速度が重要です。

専門スキルの境界

Chiaroscuro は単独でも使えます。専門スキルは深みを加えますが、Hard Rules の代わりにはなりません。専門スキルがインストールされていて、その作業で深い検討が有益な場合に限り、委任してください。

• タイプスケールとそのスキャナーには typecase；
• 再利用と重複の監査には componentize；
• ジェスチャーを含むモーションの作成、レビュー、特定には zoetrope；
• 手順2の指示に従ってUIコピーを書く、または変更する場合は signage；
• エビデンス重視のブラウザーQAには fieldtest；
• あらゆる画面のレスポンシブ対応を確認するには reflow；
• 洗練より先にペイン付きの固定シェルが必要な場合は armature；
• ユーザーが複数のページ案から選びたい場合は maquette；
• Paper ファイルでの作業には paste-up；
• 対象を限定したユーティリティには dark-mode-image、canonicalize-tailwind、markup-from-image、prototype、または pick-ui-library。

通常のエンドツーエンドのインターフェイス作業は、ここで行います。ユーザーから求められない限り、専門スキルへの依存、保存済みのデザイン仕様、ワイヤーフレーム、承認待ちを無理に追加してはいけません。