Design Token命名のベストプラクティス — 2026年 第8週 デザインシステム

今週のdesign systemsは繰り返す緊張を浮き彫りにしました。アーキテクチャ的に堅牢なものを作ることと、実際に使われるようにすることの間のギャップです。注目記事のtoken命名はその基盤層を直接扱い、IBM Carbonモデルに倣うglobal-alias-component三階層構造が表記上の慣習ではなく、load-bearingなアーキテクチャであると主張しました。特にcolor-brand-primaryのような単一aliasがnamespaceを重複させずにthemeごとに異なる値として解決されなければならないマルチブランドシステムでは顕著です。併せて紹介されたFigmaの動画はこの原則が実規模で適用される様子を示しており、Jumpスポーツの2人チームがチームごとのFigma modeを使って単一ライブラリで50以上のブランドを管理し、team ID変数ひとつを変えるだけでUI全体がブランド間で切り替わります。

ARIA Authoring Practices Guideへの批評は重要なアクセシビリティの訂正をもたらしました。APGはARIAの機能を実演するために設計されたものであり、プロダクションのpattern libraryではなく、ネイティブHTMLで十分な場面でもARIAに依存しすぎた例が含まれています。Stefan Judisの実践ルール — ネイティブHTML優先、支援技術での実機テスト、実践者のフォロー — はdesign systemのコンポーネントドキュメントにも等しく当てはまります。adoption pitfallsの記事は文化的な要因を強調しました。チームが回避する技術的に完璧なライブラリよりも、governanceとフィードバックループが長続きします。

エンゲージメント心理学に関するstreak UXの詳細解説がカテゴリを締めくくり、損失回避・Zeigarnik効果・grace mechanismといった行動設計レイヤーが、design systemがユーザー向け機能をリリースする際にcomponentレイヤーと同じくらい重要であることを思い起こさせました。