デザイントークンを配信しestieの全プロダクトに導入しました

デザインエンジニアのきょんしー(@kyoncy_site)です。この記事は estie 真夏のアドベントカレンダー12日目の記事です!

estie は5月にリブランディングを行いました。形が大きく変わったのですが、カラーに関しても青みが強くなりよりくっきりした印象を与えるロゴになりました。

Brand new estie! 1年かけたリブランディングの舞台裏【プロセス全公開】 - estie inside blog

estieの旧ロゴと新ロゴ
リブランディングに合わせデザイントークンのライブラリを配信し、開発しているすべてのプロダクトに導入しました。これらの流れについてお話しできたらと思います。

estie で抱えていた課題

estie では現在いくつものプロダクトが立ち上がっています。おおよそ1チームに1人以上のデザイナーまたはデザインエンジニアが所属しています。

Vue.js で開発しているプロダクトもあれば React を採用しているプロダクトもあるのですが、各プロダクトごとにデザイントークンを定義している状態でした。

Figma 上で定義してあるトークンを元にそれぞれのプロダクトで利用していたのですが、リブランディングに合わせてプロダクト内で使用しているカラーも見直しをしていたため

  • トークンを更新する際に対応が漏れてしまう可能性がある
  • 人の手でコピーすることになるため typo が発生する可能性がある
  • 上記の2つの課題はプロダクトの数が増えると発生確率も上がる といった課題が見つかりました。

話は少し変わりますが自分はプロダクト開発を担当する側、デザインシステムのチームにも所属しています。そのため、ライブラリとして配信し導入することでトークンの更新作業を楽にすることを目指しました。

デザイントークンの配信

ライブラリで配信することの利点としてトークンの更新があった場合にはライブラリ側に変更を加え、利用側では(破壊的変更がなければ)バージョンを上げるだけで完結できます。

ただ、人手でライブラリ側に変更を加える際に間違えてしまう可能性もあるため自動化することにしました。 具体的には Figma 上で定義してある Color styles や Text styles で設定したトークン、さらに border-radius, spacing といった Local styles で定義することのできないトークンを Figma API を用いて JSON に変換し、Style Dictionary を用いて JSON を JavaScript のコードに変換しています。これら一連の処理をコマンド1つで完結するようにしました。

取り組む中で(案の定?)問題に突き当たってしまうのですが Vue.js を使ってるプロダクトでは Sass、React を使ってるプロダクトでは TypeScript でトークンを定義しているため出力形式を2つ用意する必要がありました。また、ライブラリを導入する側の負担を減らすためにも出力されるファイルを各プロダクトで定義している形式に寄せる必要もありました。

この辺りの問題は Style Dictionary が解決してくれました。このパッケージは、JSON を Android や iOS, CSS, JavaScript といったさまざまな利用シーンに応じた形式に変換するフォーマットを用意してくれています。細かな点において満足できなかったので estie ではフォーマットを自作して読み込ませています。

カスタマイズを効かせているので多少やりすぎかなと思うことはあったのですが、デザイントークンに変更がある度に依存するプロダクトすべてでバラバラに対応してたことが1箇所に集約され、当初の課題を解決できたため個人的にはベストな形にすることができました。

事前調査としての初手導入

最初の導入はプロダクトではなくUIライブラリでした。こちらも取り掛かり中ではあるのですが、まだ利用者がいない段階だったため導入にあたっての壁がどこにあるかを調べる目的で導入しました。

元々コンポーネントライブラリ内で定義していたトークンからの置き換えはスムーズに行えたのですが、Private な GitHub Package として配信していたため利用者に Personal Access Token を発行してもらう手間などに気づけました。この点に関しては、ローカルでの開発において .npmrc を利用するか npm login で設定する方法や CI での設定の書き方を README に記載して対応してもらうようにしています。

導入してみた結果、トークンの出力形式をなるべくプロダクト側に寄せたため置き換える作業はスムーズにできることが分かりました。

全プロダクトへの導入

デザイントークンを配信しようという話がでた今年の2月時点では、6月末までに1つのプロダクトに導入しようと計画していました。結果としては全プロダクトへの導入が実現したのですが、振り返ると積極的な導入支援が功を奏したと思っています。

  • モブプロをしてローカルでのビルドや CI/CD が通るところまで確認・サポートする
  • 他プロダクトの導入事例をドキュメントにまとめ、他チームが参照できる
  • リリースのアナウンス(自動化)をし、前回との差分を共有する

リブランディング前の段階でほとんどのプロダクトへ導入が完了し、リブランディング当日はライブラリのバージョンを上げるだけで対応が完了する状態を作り出すことができました!

リブランディング後も細かい Primitive Color の調整があったのですが当初の課題が解決できたことで Semantic な部分の議論を中心にできている気がします。デザインシステムのチームとして詰まりそうなところはドキュメントに残し、困っていたら積極的に助けに行くことは改めて大事だと感じました。

最後に

estie ではマルチプロダクト戦略を掲げており、これからもさまざまなプロダクトを立ち上げる予定です!UIライブラリ構築など、プロダクトを横断した取り組みも進んでいます!

デザインエンジニア・デザイナーの採用も行っているので、お話ししましょう!

hrmos.co

hrmos.co

© 2019- estie, inc.