UI component architecture, design tokens, and semantic theming Compiled for immediate developer deployment.
JSONスキーマを使ったエディタでのソース段階、pre-commitフック段階、CIパイプライン段階、npmパッケージ公開前のpre-publish gate段階です。この記事は各ステージを、デザインツール優先・コード優先・CSS custom propertiesを使うプロダクトコードというトークン所有モデルにマッピングし、各レイヤーで実行可能なチェックを説明します。循環参照の検出やトークン間の参照解決などの構造的チェックはすべてのトークンファイルが揃ってから実行可能なため、pre-commitまたはCI段階でのみ実施できます。始めたばかりのチームはまずStage 3(CI)を実装し、トークンパッケージを公開するチームは警告がハードエラーになるstrict modeでStage 4を必ず実行する必要があります。
CSS変数によるテーマカスタマイズ、完全なローカライズ、REST API統合用のRestDataProviderが含まれます。PRO版はYear、Agenda、Resources、Timelineビューと繰り返しイベントを追加します。このコンポーネントはreact-big-calendarのような軽量オプションとBryntumのような重厚なエンタープライズツールの間を狙い、全体でTypeScriptをサポートします。
Beyond IdentityのデザイナーBeckyとHead of DesignのAlanが、4人のデザインチームがClaude Codeをエンドツーエンドで活用する方法を実演します。プロダクションコンポーネントを取り込んだライブsandbox環境の構築からステークホルダーレビュー向けのFigmaフロー置き換えまでを示します。主なワークフロー要素には、デザインのイテレーションとユーザーロールを切り替えるシークレットコントロールパネル、AlanがsandboxプロトタイプにビジュアルコメントをつけるためにビルドしたVS Codeプラグイン、MUI専用コンポーネントや特定のアイコンライブラリなどデザインシステムの制約を適用するCLAUDE.mdファイル、そしてハードコードされたカラー値とspacing違反を監査するカスタムClaudeスキルがあります。Alanはまた、Figmaのスクリーンショットをクロードに入力して週末でイテレーションしながらチームのデザインシステムをbootstrappingし、最終的にエンジニアリングチームの承認を得てsandboxを実際のプロダクションデザインシステムに接続した経緯も説明しています。
ほとんどのデザインシステムチームは企業規模に関わらず2〜5名で構成されており、NNGの調査はこの少人数体制が欠陥ではなく強みであると主張しています。小規模チームはハンドオフなしにコンテキストを共有し、対立を素早く解決し、デザイナーがcomponent APIに触れエンジニアがデザインをレビューするなど役割の境界が柔軟です。強制的な優先順位付けにより、システムは実際のプロダクトロードマップのニーズに集中し続けます。この記事は、意図的なdesign-ops戦略として少人数体制を維持するチームと、単に人手不足なチームを区別し、後者はバーンアウトと技術的負債に悩まされると指摘します。チャンピオンプログラムや貢献者モデルによる影響力の拡大は、経営陣のサポートと現実的な許容量への期待があってこそ持続可能です。
Beyond IdentityのデザイナーBeckyとHead of DesignのAlanが、4人のデザインチームがClaude Codeをエンドツーエンドで活用する方法を実演します。プロダクションコンポーネントを取り込んだライブsandbox環境の構築からステークホルダーレビュー向けのFigmaフロー置き換えまでを示します。主なワークフロー要素には、デザインのイテレーションとユーザーロールを切り替えるシークレットコントロールパネル、AlanがsandboxプロトタイプにビジュアルコメントをつけるためにビルドしたVS Codeプラグイン、MUI専用コンポーネントや特定のアイコンライブラリなどデザインシステムの制約を適用するCLAUDE.mdファイル、そしてハードコードされたカラー値とspacing違反を監査するカスタムClaudeスキルがあります。Alanはまた、Figmaのスクリーンショットをクロードに入力して週末でイテレーションしながらチームのデザインシステムをbootstrappingし、最終的にエンジニアリングチームの承認を得てsandboxを実際のプロダクションデザインシステムに接続した経緯も説明しています。
デザイントークンのlintingは、4つのパイプラインステージにわたる多層防御として機能するとき最も効果的です。FigmaやTokens Studioなどのデザインツール内またはJSONスキーマを使ったエディタでのソース段階、pre-commitフック段階、CIパイプライン段階、npmパッケージ公開前のpre-publish gate段階です。この記事は各ステージを、デザインツール優先・コード優先・CSS custom propertiesを使うプロダクトコードというトークン所有モデルにマッピングし、各レイヤーで実行可能なチェックを説明します。循環参照の検出やトークン間の参照解決などの構造的チェックはすべてのトークンファイルが揃ってから実行可能なため、pre-commitまたはCI段階でのみ実施できます。始めたばかりのチームはまずStage 3(CI)を実装し、トークンパッケージを公開するチームは警告がハードエラーになるstrict modeでStage 4を必ず実行する必要があります。
GitHubはGitHub Copilot CLIとVS Codeに統合した実験的なアクセシビリティエージェントを試験運用中で、3,535件のpull requestをレビューし68%の解決率を達成しています。エージェントはpassive reviewerとactive implementerの2つのsub-agentアーキテクチャを採用し、トークンの無駄遣いとハルシネーションを防ぐためstructured template schemaのみで通信します。主な設計判断として、コードの複雑さを評価するshellスクリプトのヒューリスティック、閾値を超えるとコード生成を無効化する機能、LLMがアクセシブルにしにくいdrag-and-dropやdata gridなどの高リスクパターンの明示的なブロックリスト、そして並列ではなく線形の順次実行があります。LLMは数十年分のアクセシブルでないコードで学習されているため、エージェントはGitHubが手動でキュレーションしたアクセシビリティ問題のログとそのremediation PRのコーパスを積極的に活用しており、一般的なベストプラクティス指示よりも大幅に効果的でした。
READ_FULL_LOGarrow_forwardスピナーを有益なステータス更新で置き換えることが信頼性の高いエージェントUIの基盤であり、この記事はAction Word、Specific Item、Limits/Rulesの3部構成のmicrocopy公式を提案します。4つの具体的なインターフェースパターンがリスクレベルに応じてマッピングされます。低リスクなバックグラウンドタスク向けのLiving Breadcrumb、フロントエンドの状態管理とwebhookイベント処理が必要な高リスクな多段階フロー向けのDynamic Checklist、サニタイズされたrawログへのアクセスが必要な専門ユーザー向けのThinking Toggle、そして持続的なタスク完了後のレシートとしてのAudit Trailです。また、部分的な成功のための設計、ツール障害とエージェント障害の切り分け、パワーユーザーはリアルタイム更新を完全に無視することが多いという現実も扱っており、Audit TrailはAI出力が期待と乖離した際に廃棄され手作業で再処理されるのを防ぐ安全網であることを強調しています。
READ_FULL_LOGarrow_forwardSVAR CalendarはMITライセンスで公開された新しいオープンソースのイベントカレンダーコンポーネントで、Svelte、React、Vue向けのネイティブ実装を提供しながら、内部ではフレームワークネイティブを維持しつつ統一APIを共有します。無料版にはDay、Week、Monthビュー、drag-and-dropによるイベント作成とリサイズ、組み込みイベントエディタ、サイドバートグルによるカレンダーグループ管理、iCalインポート/エクスポート、CSS変数によるテーマカスタマイズ、完全なローカライズ、REST API統合用のRestDataProviderが含まれます。PRO版はYear、Agenda、Resources、Timelineビューと繰り返しイベントを追加します。このコンポーネントはreact-big-calendarのような軽量オプションとBryntumのような重厚なエンタープライズツールの間を狙い、全体でTypeScriptをサポートします。
PDF、Word(.docx)、EPUBファイルなどのデジタル文書は、欧州アクセシビリティ法(EAA)、ADA Title II(期限2027年4月)、英国PSBARなど増大する法律の下でWCAG 2.1 Level AAを満たす必要があります。この記事は、画像のalt テキスト欠落、低解像度ラスター画像に埋め込まれたテキスト、非論理的な読み取り順序、セマンティック見出し構造の欠如など最も一般的なアクセシビリティ障壁を取り上げます。各フォーマットには固有の考慮事項があります。PDFは固定レイアウトのためWCAG技法に加えてPDF/UA(ISO 14289)が必要で、EPUBはHTML/XMLベースのためEPUB Accessibility 1.1に従い、Wordドキュメントはエクスポート前にMicrosoftの組み込みAccessibility Checkerを通過する必要があります。全体を通じた重要な原則は、コンテンツ作成後に修正するのではなく、最初から設計にアクセシビリティを組み込む必要があるということです。
READ_FULL_LOGarrow_forward今週の NNG リサーチは、ほとんどのデザインシステムチームが企業規模に関わらず意図的に2〜5名で構成されており、これが人員不足ではなく構造的な強みであることを改めて確認しました。小規模チームはハンドオフなしにコンテキストを共有し、対立を迅速に解決し、デザイナーがcomponent APIに触れエンジニアが視覚的な決定をレビューするなど役割の境界が柔軟です。強制的な優先順位付けにより、システムは実際のプロダクトニーズに集中します。重要な区別は、design-ops 戦略として少人数体制を維持するチームと、単に人手不足のチームの間にあり、後者はバーンアウトと技術的負債が蓄積します。チャンピオンプログラムを通じた影響力の拡大は、経営陣のサポートと現実的な許容量への期待があってこそ機能します。
2つの記事がパイプラインの両端でプロセス品質を扱いました。トークンガバナンス面では、ソース（Figma/Tokens Studio またはエディタの JSON スキーマ）、pre-commit フック、CI パイプライン、pre-publish ゲートの4段階 linting 戦略が示されました。循環参照の検出などの構造的チェックはすべてのトークンファイルが揃ってから実行可能なため、pre-commit または CI 段階でのみ実施できます。AI 面では、GitHub Copilot CLI と VS Code に統合された GitHub の実験的アクセシビリティエージェントが3,535件のプルリクエストを68%の解決率でレビューし、passive reviewer と active implementer の2サブエージェントアーキテクチャと、LLM がアクセシブルにしにくい drag-and-drop などの高リスクパターンへの明示的ブロックリストを活用しています。
チーム運営とプロセス以外では、Smashing Magazine のエージェント UI 透明性シリーズ第2回がリスクレベルに応じた4つのインターフェースパターン（Living Breadcrumb・Dynamic Checklist・Thinking Toggle・Audit Trail）を提案しました。SVAR Calendar は MIT ライセンスで React・Svelte・Vue 向けに統一 API を共有するマルチフレームワークイベントカレンダーとしてリリースされ、Beyond Identity のデザインチーム事例では Claude Code をプロダクションコンポーネントのサンドボックス化からステークホルダーレビューまでエンドツーエンドで活用し、CLAUDE.md で MUI 専用制約を適用、カスタムスキルでハードコードされた色やspacing 違反を監査する方法が紹介されました。