articleタグ: AI + トークン読了_時間: 8分
EngineerとAgent向けに仕様化したDesign Systemを構築
Evil Martiansは、テスト観測プラットフォームのCurrentsに対して、791ファイルをAI支援で監査し、わずか7週間で完全なデザインシステムを構築しました。監査では236種類のユニークカラーと1,413件の使用事例、重複したフォントシステム、並行するアイコンライブラリが発見されました。新しいカラーシステムはelevation、content、UI、borderの4つのセマンティックトークングループに整理され、AIエージェントがパレットを予測可能に拡張できるようOKLCHで定義されています。タイポグラフィは6つのサイズと5つのトークングループに統合され、ボタンラベルには唯一正しいトークンを持つUIグループが含まれます。アイコンはAIが90%の精度で生成したマッピングテーブルを使ってFigura Oneセットに移行されました。このシステムはFigma、Storybook、GitHubに実装され、デザイナーなしでエンジニアとLLMの両方が利用できるよう設計されています。
タグ: アクセシビリティ読了_時間: 6分
Design TokenでColour Contrastを自動化
本記事はデザイントークンワークフローシリーズの一部で、Style DictionaryとColorjs.ioを使ってビルド時にWCAG準拠のカラーコントラストを自動生成する方法を解説しています。-backgroundで終わるトークンは自動的に-foreground-aaおよび-foreground-aaaトークンを生成し、黒と白のうち高いコントラストを持つ方を選択してAA基準を常に満たします。カスタムforegroundカラーを定義した場合、ビルド時にそのコントラスト比と合否がCSSコメントとして出力されます。transformはbackgroundTokenNameとforegroundTokenNameをカスタマイズ可能で、既存のネーミング規約にも柔軟に対応できます。バリデーションアクションはビルド後に実行され、AA未達のカスタムforegroundカラーのみエラーを返します。出力はすべてのブラウザやフレームワークで利用可能なCSS カスタムプロパティです。
タグ: ワークフロー読了_時間: 12分
ProposalからReleaseへ：Design System Workflowを設計
明確なワークフローがなければ、デザインシステムはコンポーネントの重複、品質の不均一、チームのバーンアウトを招きます。記事はデザイナーとエンジニアが同じprogress barコンポーネントを独立して作ってしまうシナリオから始まります。著者は健全なデザインシステムワークフローの6つの基本的な柱を提示します：Contribution、Review and Approval、Documentation、Communication、Iteration、Versioning and Deprecationです。コンポーネントのライフサイクルはIdeation、Validation、Design、Review、Development、Testing、Documentation、Releaseと進み、シンプルな変更で1〜2週間、複雑なコンポーネントで8〜12週間を目安とします。デザイナーからエンジニアへの一方向なハンドオフでなく、継続的なコミュニケーションの重要性が強調されており、セマンティックバージョニングによる変更管理の予測可能性についても解説されています。
タグ: ガバナンス読了_時間: 10分
Design System Governance Planの作り方：混沌から一貫したUIへ
このガイドは、成熟したデザインシステムの79%が公式なガバナンスを持ち、適切なガバナンスがデザインドリフト（意図したパターンと実際のリリースとの乖離）を防ぎ、最大60%のROI向上をもたらすと主張しています。著者は6ステップの実装フレームワークを提示します：ガバナンスチームの定義（Champion、Product Owner、Implementation Support、Stakeholderの役割を含むコアと拡張レイヤー）、10ステップのコンポーネントリクエストとレビュープロセスのマッピング、有用性・独自性・汎用性を基準にした貢献ガイドラインの設定、SlackやGitHubを活用した変更管理ワークフローの構築、セマンティックバージョニング（major/minor/patch）とリリースケイデンスの確立、使用・貢献・サポートを網羅した文書構造の構築です。意思決定権のためのRACIマトリクス、例外処理プロトコル、コンポーネント再利用とカスタムバリアントの比率を追跡する月次ガバナンスレビューも推奨されています。
タグ: Storybook読了_時間: 13分
StorybookでのMocking
Fotis Adamakisは、Storybookにおける隔離コンポーネントテストのためのモッキング戦略を包括的に解説しています。対象はprops、context provider、カスタムフック、サードパーティライブラリ、API、GraphQL、ルーティング、状態ストア、ブラウザAPI、環境変数まで多岐にわたります。カスタムフックはStorybookのネイティブ.mock.jsファイルパターンと@storybook/testのfnユーティリティを使用し、APIリクエストはmswパラメーターでMSWにより傍受されます。ReduxストアはrRedux-mock-storeデコレーターを、ZustandはフックベースのアーキテクチャゆえにMock.jsアプローチを採用します。window.matchMedia、IntersectionObserver、localStorageなどのブラウザAPIはpreview.tsxでObject.definePropertyとfn()によりグローバルにスタブ化されます。play関数を使ったインタラクションテストと、ストーリー間の状態リークや過剰モッキングといったアンチパターンも取り上げています。
タグ: TypeScript読了_時間: 3分
型付きPolymorphic React Component
Kitty Giraudelは、DunaのデザインシステムでTypeScript対応のポリモーフィックReactコンポーネントを実装する際に発見したコンパクトな解決策を紹介しています。目標はasプロップでspan、a、time、dataなど任意のHTML要素をレンダリングしながら、選択した要素に有効なpropsのみを許容するTextコンポーネントです。{as: E}とReact.ComponentProps<E>の単純な交差型は、TypeScriptがEを推論するとき交差を絞り込まないため機能しません。有効な解決策はComponentProps<E>のキーを明示的にマッピングし、EがResolveされた後にTypeScriptが具体的なオブジェクト型を具体化するよう強制する方法です。または、ComponentProps<E>をOmitでラップする（存在しないキーを除外しても）ことで同じ効果が得られます。著者はこのマップ型アプローチがなぜ機能するのか完全には理解できていないと述べており、StackOverflowでの類似事例を挙げています。
タグ: アクセシビリティ読了_時間: 10分
D/deafの人のためのDesign
TetraLogicalのEla Gorlaは、D/deaf（Deafは文化的・手話コミュニティ、deafは後天性の聴覚障害を持つ人々）の具体的なデザインニーズを取り上げ、単なる字幕提供を超えたアプローチを提案します。字幕、テキスト書き起こし、手話通訳などのメディア代替手段は正確で同期されており、ネストされたメニューに埋もれず、コンテンツの近くに配置される必要があります。手話を第一言語とする人々のスペルミスを減らすため、フォームではラジオボタンやselectなどの選択肢型入力を優先すべきです。短い文章、慣用句の回避、略語の展開といったプレインランゲージの原則も理解を助けます。ゲーム、XR、アプリの音声通知には視覚的またはハプティクスの代替手段を用意し、2024年のFortniteのように初期設定で有効化することが理想的とされています。D/deaf当事者をデザインプロセスに直接参加させることも推奨されています。
summarizeダイジェスト_要約
今週のデザインシステム関連の話題は、AIツール、トークンアーキテクチャ、ガバナンスの成熟度の交差点に集中しました。Evil Martiansは791ファイルへのAI監査で236種類のユニークカラー1,413件の使用事例、重複したフォントシステム、並行するアイコンライブラリを発見し、7週間でCurrents用の完全なデザインシステムを構築しました。AIエージェントが色のずれなく予測可能にパレットを拡張できるよう、結果はelevation、content、UI、borderの4つのOKLCH定義のセマンティックトークングループにまとめられました。アイコンはSVGRでラップしたFigura OneセットとAI生成のマッピングテーブルで90%の精度で移行され、システム全体がFigma、Storybook、GitHubに実装されてデザイナーなしでLLMが活用できるよう設計されています。
ガバナンスとプロセスも同等の重みで取り上げられました。詳細なワークフローガイドでは健全なデザインシステム運営のための6つの柱（Contribution、Review and Approval、Documentation、Communication、Iteration、Versioning and Deprecation）が示され、コンポーネントのタイムラインはシンプルな変更の1〜2週間から複雑なものの8〜12週間まで様々です。ガバナンス記事では成熟したデザインシステムの79%が公式なガバナンスを持ち、デザインドリフトを防ぐことで最大60%のROI向上をもたらすと述べ、RACIマトリクスとコンポーネント再利用対カスタムバリアント比率を追跡する月次レビューを推奨しています。
コンポーネントテスト面では、Fotis Adamakisがprops、API傍受用MSW、Redux向けredux-mock-storeデコレーター、ZustandとカスタムフックへのMock.jsパターン、window.matchMediaやIntersectionObserverなどのブラウザAPIへのObject.definePropertyスタブを網羅するStorybookモッキングガイドを発表しました。TetraLogicalはD/deaf ユーザーのアクセシビリティを取り上げ、コンテンツ近くの正確な同期字幕、スペルミス軽減のための選択式フォームコントロール、音声通知のデフォルト有効な視覚的・ハプティクス代替を強調しました。Kitty GiraudelはDunaデザインシステムの作業中に発見したtypedポリモーフィックコンポーネント用のコンパクトなTypeScriptパターンを共有し、asプロップが確定した後にTypeScriptが具体的なpropsを具体化するようmapped typeを活用する方法を紹介しました。
重要ポイント- Evil Martiansは791ファイルへのAI監査でCurrents用デザインシステムを7週間で構築しました。OKLCHトークンを採用した理由は、AIエージェントが色のずれなく予測可能にパレットを拡張できるためです。
- 公式ガバナンス（RACIマトリクス、10ステップのコンポーネントリクエストプロセス、セマンティックバージョニング、月次ドリフトレビュー）は成熟したデザインシステムで最大60%のROI向上と相関しています。
- Storybookの.mock.jsファイルパターンとMSWの組み合わせで、カスタムフック・API呼び出し・Redux・Zustand・ブラウザAPIを含むデザインシステムコンポーネントの全モッキング領域を一貫したアプローチでカバーできます。
