デザインシステム・UIガイド

015工程のうち1

画面と部品を集める

対象の画面と、そこで使われている部品、値、表記、実装上の制約を集めます。

分担

• 人判断：調べる対象の画面を決め、記録の様式を決める
• AI画面の写し、デザインファイル、コードから部品を一覧にする。デザインファイルやコードを読む接続と権限がない場合は、人から渡された画面の写しを使う。画面ごとに複数の担当で分担できる
• 開発担当者コード上の部品と、変更できない箇所を示す

材料

対象の画面と部品、色・余白・文字の値と表記のルール、既存のデザインライブラリ、コード、実装上の制約

成果

部品の一覧（名前、見た目、状態、使われている画面、コード上の名前）

考え方

最初に、既存のデザインライブラリとコードを確認します。既にある部品を知らずに共通部品を作ると、既存の重複をもう一つ増やすことになります。

画面ごとに部品を調べる作業は、複数の担当で分担できます。分担する前に、記録する項目と名前の付け方を決めておきます。部品は見た目と一緒に、どの画面で何のために使われているかを記録します。見た目が同じでも役割が違えば別の部品として扱い、見た目が違っても役割が同じなら共通化の候補になります。

推奨と理由

1. 分担する前に、記録の様式を決める

   理由様式が担当ごとに違うと、同じ部品が別の名前で集まり、重複しているかどうかを判定できません。

2. 見た目と一緒に、使われ方を記録する

   理由見た目だけで集めると、役割の違う部品を一つにまとめてしまい、代表画面で試す段階で例外が増えます。

次へ進む目安

• 対象の画面が全て調べられている
• 各部品に、使われている画面と、コード上の対応（ある場合）が書かれている
• 既存のデザインライブラリにある部品との対応が分かる

025工程のうち2

重複や違いを調べ、共通化する範囲を決める

集めた部品を比べ、揃える違いと残す違いを分け、今回共通化する範囲を決めます。

分担

• AI似た部品をまとめ、違いを「理由がありそうな違い」と「偶然の違い」の候補に分ける
• 開発担当者部品を置き換えたときに影響する画面と、作業の量を示す
• 人判断：共通化する範囲を決める

材料

部品の一覧、実装上の制約

成果

共通化する部品の一覧、残す違いとその理由、今回の対象外

考え方

部品の違いには、理由のある違いと偶然の違いがあります。理由のある違いには、取り消せない操作を目立たせるため、一覧の中で密度を上げるため、実装上の制約のため、などがあります。偶然の違いは、担当や作った時期が違うために生じたものです。

判断の材料は、その部品が使われている画面の数、違いの理由、置き換えたときの影響、同じ見た目で違う動きをする箇所の有無です。複数の画面で使われ違いに理由がない部品と、違いを規則として説明できる部品を範囲に入れます。

推奨と理由

1. 違いの理由を確かめてから揃える

   理由偶然と判断した違いが、誤った操作を防ぐなど業務上の理由を持っていた場合、揃えることで誤操作を招きます。

2. 最初の範囲は、使われる頻度の高い部品に絞る

   理由全ての部品を一度に揃えようとすると、代表画面での確認が終わらないまま規則だけが広がります。

次へ進む目安

• 範囲に入れた各部品について、揃える理由または残す違いの理由を言える
• 置き換えの影響を受ける画面が分かっている
• 今回の対象外が書かれている

035工程のうち3

共通部品を作る

範囲の部品について、状態、値、名前を決め、デザインファイルとコードで対応する形で作ります。

分担

• AI部品の案と状態の一覧、値の整理を作る。デザインファイルやコードを編集する接続と権限がある場合は、その上で作る
• 開発担当者コード側の部品を作る
• 人判断：名前と値を確定する

材料

共通化する部品の一覧、残す違いとその理由

成果

状態つきの共通部品、名前つきの値、デザインファイルとコードの対応表

考え方

各部品には、通常、フォーカス、押している間、使えない、エラー、読み込み中など、必要な状態を全て作ります。名前は、色や形より役割から付けます。値は名前を付けて管理し、部品からはその名前で参照します。

デザインファイルとコードの対応は、表にして残します。デザインファイルとコードを自動で同期する仕組みを使う場合は、実際に使う環境で一度動かし、変更が正しく反映されるかを確かめてから採用します。

推奨と理由

1. 名前は役割から付ける

   理由色で名付けると、ブランドの色を変えたときに名前と見た目が食い違います。

2. デザインファイルとコードの対応表を作る

   理由対応が片方にしか書かれていないと、更新のたびに二つがずれていきます。

次へ進む目安

• 範囲の各部品に、必要な全ての状態がある
• 値が名前つきで管理されている
• コード側の対応が決まっている。未実装の部品には担当がある

045工程のうち4

代表画面で試す

共通部品で代表画面を組み直し、利用者に必要な操作と状態が成り立つか、規則だけで作れるか、例外がどれだけ出るかを確かめます。

分担

• AI代表画面を共通部品で組み直す。編集と表示確認ができる環境がある場合に行う
• 開発担当者実装したときの問題を確かめる。AIに環境がない場合は、操作できる表示を用意する
• 人判断：代表画面を操作し、共通部品で使えるかを確認する

材料

共通部品、性格の違う代表画面

成果

組み直した代表画面、操作と状態の確認結果、例外の記録と対応方針

考え方

代表画面には、性格の違う画面を選びます。例えば、入力が多い画面と、一覧が多い画面です。組み直す中で規則に合わない箇所が出たら、その場で個別に直さず、数と理由を記録します。

例外の数だけでは、共通部品が使えるかを判断できません。実際に操作できる表示で、利用者が代表画面で必要な操作を最後まで行えるか、入力の誤り、読み込み中、使えない状態など、利用者に必要な状態が表示で伝わるかを確かめます。

判断の材料は、操作と状態の確認結果、例外の数と理由、組み直す前と後の画面の比較、置き換えによって変わる操作です。必要な操作が成り立ち、必要な状態が伝わり、例外が規則として説明できる数に収まり、置き換えで利用者の操作が変わる箇所が把握されていれば合格とします。操作が成り立たない、または例外が多い場合は、工程02へ戻り、範囲や部品の分け方を見直します。

推奨と理由

1. 性格の違う画面を、少なくとも二つ選ぶ

   理由似た画面だけで試すと、規則がその種類の画面に合わせて作られ、他の画面で例外が増えます。

2. 例外は個別に直さず、記録して集める

   理由個別の対応を重ねると、共通部品の外に新しい重複が生まれ、工程02の整理が元に戻ります。

3. 静止画で並べるだけでなく、操作して状態を出す

   理由部品の見た目が揃っていても、エラーや読み込み中の状態が画面の中で見分けられない、押せる範囲が足りないといった問題は、操作しないと分かりません。

次へ進む目安

• 代表画面で、利用者が必要な操作を最後まで行える
• 入力の誤り、読み込み中、使えない状態など、利用者に必要な状態が表示で伝わる
• 例外が記録され、それぞれに対応方針（規則に加える、画面を直す、範囲を見直す）がある
• 置き換えで利用者の操作が変わる箇所が分かっている

055工程のうち5

使い方と例外をまとめる

各部品の使う場面、使わない場面、状態、例外、コード上の名前を、ガイドとして書きます。

分担

• AI部品ごとのガイドの下書きを作る。部品ごとの執筆は、複数の担当で分担できる
• 人判断：一人が全体を読み、名称と値を揃えて確定する

材料

共通部品、代表画面での確認結果と例外の記録、UXライティングのガイドで決めた表記ルール（ある場合）

成果

UIガイド（部品ごとの使う場面、使わない場面、状態、例外、コード上の名前、実例）

考え方

部品ごとに、使う場面と使わない場面を書き、使わない場面では代わりに使う部品を示します。例は、工程04で組み直した代表画面から取ります。

部品ごとの執筆は分担できます。分担した場合は、最後に一人が全体を読み、部品の名前、値の名前、用語を揃えます。文言の規則をガイドに含める場合は、UXライティングのガイドで決めた表記ルールと呼び名を使います。

推奨と理由

1. 使わない場面と、代わりの部品を書く

   理由使う場面だけを書くと、似た部品のどちらを選ぶかが読む人の判断に任され、また違いが生まれます。

2. 例は代表画面の実例から取る

   理由架空の例だけでは、読む人が実際の画面で同じ判断をできるかが分かりません。

次へ進む目安

• 範囲の全ての部品に、使う場面、使わない場面、状態、コード上の名前がある
• 例外に理由が書かれている
• 一人が全体を読み、名称と値が揃っている

成果を渡す先

UIガイドと共通部品は、画面を作る担当と開発の担当が同じ基準で判断するための材料になります。

このガイドへ戻るとき

UI画面のガイドで、既存の部品では作れない部品が必要になったときは、工程02で範囲に加えるかを判断します。ブランド方針が変わり色や書体の値が変わるときは、工程03で値を更新し、工程04で代表画面を確かめ直します。