「デザイナーのためのコンポーネント設計論」を無料公開しました + タイミーではどうしているか
こんにちは、タイミーの横田です。
デザインシステムのコンポーネント設計について、これまでさまざまな現場で議論してきた内容をまとめ、ZennでBookとして公開しました。本文は10万字以上、図は70点以上で、技術書1冊分のボリュームです。
Zenn Book
GitHub
※ 上記は私による個人の公開物であり、タイミー社として提供するものではありません。
本記事では、Bookの概要をご紹介したうえで、タイミーにおけるデザインシステムの運用方法をご紹介します。
デザインシステムは難しい
コンポーネント設計の考え方を原則から具体の実践まで、デザイナーの言葉でかみ砕いて紹介しています。「デザイナーのための」と銘打っていますが、エンジニアやPdMも一読の価値があると考えています。
原則 / デザインシステムの構築戦略 / コンポーネント分割 / 現実的な問題への対処 / コンポーネントの変数 / コンポーネントの状態 / レイアウト / アセット
デザインシステムの考え方には、（私もそうなのですが）エンジニアリング経験が多くないデザイナーにとって、はとっつきづらい経験則や原則がたくさんあります。そして、他者に教えることの難しさも感じていました。
またそして、多くのデザイナーにとって、デザインシステムは、顧客への価値提供そのものではなく、手段・基盤です。そのため、から、ディープダイブして学ぶことの障壁も高いのではと思います。
そこで、デザイナーの観点から実践的に言語化をし、まとめて読めるようにしようと思ったのが出発点です（結果的に長くなってしまいましたが）。
ぜひ社内で使ってほしいです
このBookは、チームでコンポーネントの運用方針を議論するとき、命名で迷ったとき、プロパティの設計をレビューするとき。議論のアウトラインにしていただければと思います。社内で輪読会をしたいとの声もいただいてます。
もうひとつ想定しているのが、AIに読み込ませる使い方です。このBookのGitHubリポジトリをまるごとコンテキストとして渡せば、自社のコンポーネント設計方針を壁打ちしたり、観点のレビューに活用できます。
※ このBookのGitHubリポジトリの内容を利用する場合は、各社の情報管理ルールや利用するAIサービスの利用規約、機密情報の取り扱いに留意したうえで、必要な範囲でご活用ください。
冒頭でも触れていますが、生成AIによってデザイナーがコードに触れる敷居は大きく下がりました。AIがコードを書く時代だからこそ、構造の設計を理解する価値が高まっています。そして、AIによる開発を実プロダクトで取り入れる際に、デザインシステムは強力に作用します。
タイミーではどうやっているか
公開していないものの、タイミーでもデザインシステムを活発に運用しています。
上述のBookでは、どの組織でも多用途に使えるようにタイミーでの事例を除いて記述することにしました。
ここでは、実際にタイミーのプロダクト開発では実際にどう実践しているかを紹介します。とっつきづらい部分があればりますので、先にぜひBookをお読みいただいてから戻ってきてもよいかと思います。
タイミーはiOS・Android・Webの3プラットフォームでサービスを展開しています。モバイルアプリはワーカー向けの体験、Webは企業向けの管理画面です。そのため、2つの系統のデザインシステムが存在し、共通の点と共通しない点があります。
コンポーネントの分け方
モバイル: 粒度と用途の2軸
モバイルアプリでは、Atomic Designを簡素化した2つの軸でコンポーネントを整理しています。ネイティブアプリでデザインシステムを運用するケースはやや珍しいと思います。
粒度による軸
atoms — ボタンやテキスト入力欄など、これ以上分割できない最小のUI部品
molecules — atomsを組み合わせた複合コンポーネント。たとえば「ラベル＋入力欄＋エラーメッセージ」のセット
用途による軸
general — どの画面でも使える汎用部品（ボタン、アバター、バッジなど）
feature — 特定の業務に特化した部品（求人カード、勤怠ブロックなど）
Organisms以上の階層は設けず、atoms / moleculesに限定することで「これはどっちに入れるんだっけ？」と迷う場面を減らしています。
Web管理画面: 汎用部品とドメイン部品の2層
Web管理画面では、モバイルのようなatoms / moleculesの区分は設けていません。シンプルに2つの領域で分けています。
汎用コンポーネント — ボタン、テーブル、入力欄、バッジなど。どの画面でも使える部品をカテゴリごとに整理
機能ごとのモジュール — 認証、企業管理、勤怠など、業務の単位でまとめたコンポーネント群。
コンポーネント化の合意形成
新しいコンポーネントを作るかどうかの判断は、デザイナーがたたき台を作成し、iOS・Android・Webのエンジニアと一緒に決めます。
タイミーでは、プロダクト数が少なく規模が大きい分、共通化のレバレッジが高いと考えています。新しい要素が生まれたときは、コンポーネント化すべきか、命名をどうするか、将来的にどう活用するかを、しっかり議論して進めています。
デザイントークンの設計
デザイントークンは、タイポグラフィと色のみを管理しています。
カラートークンは2つの層で管理しており、現在はすべてのプラットフォームで共通です。具体的には、Global Colorと、それをエイリアスしたSemantic Color（例：Button.Primary.normal）を定義しています。実際に使うのはSemantic Colorのみです。
多数のリポジトリで共通化するために、トークンの更新フローは自動化されています。
FigmaのVariablesで色を更新したのち、プラグインでJSONとしてエクスポートし、GitHhubの中間リポジトリで変更を適用します。iOS・Android・Webそれぞれに自動で変更のプルリクエストが自動で届く仕組みです。このソリューションは以下の記事で紹介しています。
この方法では、複数プラットフォームで共通化するメリットを享受する反面、トークンの削除や改変には膨大な調整が必要になるおそれがあります。よって、命名に拡張性を十分持たせたり、堅牢に判断できるロジックを整備しています。
アイコン管理
UIアイコンはMaterial Symbolsで全面統一。Rounded / Weight 700 / Optical Size 40pxの設定で統一し、サイズは xs から 5xl まで9段階をトークン化しています。
3プラットフォームとも同じアイコンセットを使用しているので、デザイナーがアイコン名を指定すれば、iOS・Android・Webで同じアイコンを速やかに使用できます。Figma上ではアイコンフォントをSVGに分解し、variantで切り替えられるようにしています。
ガイドラインや設計の一元管理
Product Design GuidelinesというNotion Databaseで、以下の4カテゴリのガイドラインを一元管理しています。
基盤ルール — コンポーネント分割方針、カラートークン、アイコンシステムなどの設計原則
UIガイドライン — ボタン、モーダル、フォーム入力、ナビゲーションなど、コンポーネントごとの使用ルール
表記ルール — ボタンラベル、日時表記、記号の使い方など、UIテキストの統一規約
デザインアセット — カラーパレットの具体値、アイコンの設定仕様など
ガイドラインの採択や提案、採用された記述の同期もワークフロー化しています。デザイナー全員が参照したり、GitHub上でもAIを通じてアクセスできるようにしています。
ガイドラインは増えていくものなので、人の記憶と注意力だけでは維持できません。そこで、自社製のFigma Plugin（Normalizer Plugin）を使って、命名規則やカラートークンの適用チェックをボタンひとつで自動化しています。レギュレーションへの準拠がデザインワークの負担にならないようにすることが狙いです。
また、Figmaのコンポーネント情報をNotionに毎晩自動同期しており、「どのコンポーネントがどの画面で使われているか」「最近変更があったのはどれか」をNotion上で一覧できるようにしています。
上記の記事の執筆時点ではまだありませんでしたが、現在はこの他にもガイドラインがAI向けのプロトタイプ生成機構から読み出されたり、デザインレビューの仕組みから参照されるようになっています。
以上、かいつまんでの紹介になりますが、タイミーでの運用のご紹介でした。ご相談や聞いてみたいことがある方は、XかYOUTRUSTでご連絡いただけたらと思います。
タイミーでは一緒にはたらく仲間を募集中です
タイミーでは以前より更にプロダクトデザイナーを積極的に採用しています！興味を持っていただいた方はぜひお話しましょう！
