デザインシステム: コンポーネント、トークン、ドキュメントにおける人工知能

利益:

人工知能を使用して、一貫した設計トークン、コンポーネントの命名、および使用ルールを起草して作成する機能
人工知能を使用して、コンポーネントのドキュメント、推奨/禁止の例、および使用方法のテキストを迅速に作成する機能
人工知能の提案が既存の設計システムと競合していないかチェックし、特異性を維持する機能

デザインシステムは、製品ファミリーの外観と動作に一貫性を持たせるための共通言語です。再利用可能なコンポーネント (ボタン、カード、フォームフィールド)、デザイントークン (色、間隔、タイポグラフィなどの値の名前付き定義)、およびそれらの使用方法を説明するドキュメントです。優れた設計システムでは、10 人の設計者が、あたかも 1 つのソースから製造されているかのように同じ製品を設計できます。このシステムのインストールと保守は、反復的でテキストを大量に使用する面倒な作業です。まさにここが人工知能の威力を発揮するところです。しかし、システムの本質は特異性と一貫性です。 AI の推奨事項は、現在のシステムとの矛盾をチェックすることなしに受け入れることはできません。

トークンと命名: 一貫性の基礎

デザイントークンは、デザイン決定の名前付きの再利用可能な値です (color-primary、space-center、text-title-capital)。トークンのおかげで、1 か所で色を変更し、製品全体でそれを更新できます。しかし、トークンの威力は名前の一貫性によって決まります。 blue-1、main-blue、primaryBlue を混合して使用すると、システムがクラッシュします。

AI は、一貫した命名スキームに照らして既存のトークンセットをレビューすることと、新しいトークンにスキーマに準拠した名前を提案することの 2 つの点で優れています。「このトークンリストをセマンティック (意味ベース) 命名に変換する」のようなリクエストは、blue-500 の代わりに color-action-primary など、意味を伝える名前を生成するのに役立ちます。しかし、ネーミングの最終的な決定はチームの契約によって決まります。モデルは概要のみを提供します。

ヒント: AI にトークンに名前を付けるときは、現在のスキームの例を 5 ～ 6 つ挙げて、「同じパターンを維持する」と伝えます。サンプルのないリクエストでは、システムにとって異質な名前が生成されます。

コンポーネントのドキュメント: AI の最も生産的な領域

コンポーネントのドキュメントには、コンポーネントの機能、いつ使用するか、いつ使用しないのか、そのバリアント、状態 (デフォルト、ホバー、パッシブ、エラー)、アクセシビリティに関する注意事項、および「行うべきこと/してはいけないこと」の例が含まれます。これらのテキストを手書きで書くには何時間もかかるため、多くのチームは文書化を無視します。

AI はこのギャップを埋めます。コンポーネントを説明すると、ドラフトドキュメント、使用ルール、およびすべきこと/してはいけないことの例が一貫した形式で生成されます。したがって、ドキュメントは「存在しない」から「草案はある、修正される」へと変わり、これは大きな進歩です。ただし、モデルはコンポーネントの実際の動作を知りません。それが生成するルールをシステムの現実と一致させるのがあなたの仕事です。

文書の断片

人工知能の貢献

人間による検証

それは何をするのですか？

明確な輪郭定義

目的に対する真の適合性

いつ使用するか

一般的なシナリオ

製品固有のルール

行うべき/してはいけない例

クイックドラフトペア

実際の悪用

アクセシビリティに関する注意事項

標準リマインダー

実際のテストで確認済み

バリアント/ケースのリスト

可能なリスト

システム内に実際に存在する人々

矛盾チェック: 特異点の維持

デザインシステムの大敵は重複です。同じ仕事をする 2 つのボタン、2 つの異なる空間スケール、2 つの矛盾するルールです。 AI が新しいコンポーネントやルールを提案する場合、その提案は既存のシステムと競合する可能性があります。モデルシステム全体が考慮されているわけではありません。そこで私は、「これはすでに存在するものと矛盾していませんか?」と尋ねることによって、それぞれの提案を評価します。質問でフィルタリングします。競合スキャンに人工知能を使用することもできます。現在のシステムの概要と新しい推奨事項を提供し、競合をリストすることができます。しかし、最終的な「唯一正しい」決定はチーム次第です。

ミニケース3個

ケース 1 — 書類の負債が解消されました。チームの 24 コンポーネントのうちドキュメントがあったのは 6 つだけでした。残りの 18 コンポーネントについては、人工知能を使用して草案文書が作成されました。チームはそれぞれ 10 ～ 15 分で修正しました。数週間延期されたその仕事は2日で完了した。

ケース 2 — トークンの命名が一貫しました。あるシステムでは、色は blue1、mainBlue、brand-blue のように混合されていました。 AI は既存の 40 個のトークンをセマンティックスキーマに変換しました。チームはそれを修正し、単一の標準に切り替えました。その後のデザインでは、色の誤差が著しく減少しました。

ケース 3 — 競合するコンポーネントが拒否されました。 AIは「二次アクションボタン」と呼ばれる新しいコンポーネントを提案しました。チームが矛盾をスキャンしたところ、既存の「ゴーストボタン」と同じ働きをすることがわかり、その提案を却下しました。教訓: すべての提案がシステムに新しいコンポーネントを追加するわけではありません。利用可能なものを使用することが正しい場合もあります。

コピー可能なプロンプト

このトークンのリストをセマンティック (意味ベース) 命名スキームに変換します。現在のスキーマの例: <<5-6 例>>。同じパターンで続けます。トークンごとに、古い名前 -> 新しい名前 -> 正当性テーブルを指定します。リスト: <<トークン>>

矛盾をスキャンします: 現在のデザインシステムの概要: <<まとめ>>。新しい提案されたコンポーネント/ルール: <<提案>>。この提案は既存のシステムと競合しますか (同じジョブを実行するコンポーネント、競合するルール、重複したトークン)?矛盾とあなたの提案をリストします。

このコンポーネントの「行うべき/してはいけない」ペアの例 (現実的な正しい使用法と現実的な誤った使用法シナリオ) を生成します。各ペアについて、なぜそれが true/false であるかを 1 文で説明してください。コンポーネント: <<名前と目的>>

弱いプロンプト / 強いプロンプト

弱者: 「このボタンのドキュメントを作成します。」

結果: システムとは関係のない、フォーマットされた一般的なテキスト。

Strong: 「このボタンを次の形式で文書化します (機能 / 使用しない場合 / バリエーション / ケース / アクセシビリティ / やってはいけないこと)。知らない動作を補って、「チームが記入する必要がある」と書きます。」

結果: 一貫してフォーマットされ、適切に配置された、編集可能な原稿。

違い: 強力なプロンプト形式 + 製造禁止 + する/しないプロンプト。

よくある間違い

例なしでトークンの命名を要求します。モデルは、システムにとって異質な名前を生成します。一貫性が崩れています。
矛盾をスキャンせずにコンポーネントを追加する。重複はシステムの大敵です。
モデルによって考案された動作が正しいと仮定します。 AI はコンポーネントの実際の動作を知りません。
テストせずにアクセシビリティ評価を受け入れる。標準リマインダーは実際のテストの代わりにはなりません。
ドキュメントを一度書いただけで、更新しません。システムの変更に応じてドキュメントを更新する必要があります。

要約すると

デザインシステムは、一貫性と拡張性のインフラストラクチャです。しかし、テキスト中心で繰り返し作業が多いため、メンテナンスが無視されることがよくあります。 AI は、コンポーネントのドキュメント、推奨/禁止の例、使用スクリプト、トークンの命名草案を迅速に作成することで、この負債に対処します。しかし、システムの本質は特異性と一貫性です。すべてのトークン名はサンプルスキーマと照合して検証する必要があり、すべてのコンポーネントの提案は矛盾をスキャンする必要があり、動作のすべての記述は現実と照合して検証する必要があります。モデルを効率的な製図者として使用します。チームは個々の正しい決断を下します。

アプリケーションタスク

ドキュメントが不足しているコンポーネントを選択し、最初のプロンプトでドラフトドキュメントを作成します。
「チームは必ず入力する必要があります」とマークされたフィールドに実際の動作を入力します。
2 番目のプロンプトで、8 ～ 10 トークンをセマンティックスキームに変換し、新旧の名前テーブルを作成します。
新しいコンポーネントのアイデアについては、3 番目のプロンプトで矛盾がないか調べてください。
4 番目のプロンプトでは、コンポーネントの「実行する/しない」サンプルのペアを生成し、システムに追加します。

チェックリスト

[ ] トークンの名前付けをサンプルスキーマにリンクしました。
[ ] 新しいコンポーネントの競合をスキャンしました。
[ ] モデルで作成した動作を現実で検証しました。
[ ] アクセシビリティに関する注意事項を実際のテストで確認する予定でした。
[ ] ドキュメントを一貫した形式に保ちました。
[ ] 特異点を保持し、重複を防止しました。

デザイン システム: コンポーネント、トークン、ドキュメントにおける人工知能