こんにちは。アスクル初のデザインエンジニアになることを目論んでいる現フロントエンドエンジニアの谷です。
本記事では、サイトのフロント刷新のために1からデザインシステムを構築したという取り組みについてご紹介します。
背景
今回フロント刷新の対象となったのは、次のアスクルロジストの貨物追跡用サイトです。
https://cargo.askullogist.co.jp/delivery?ca=0
こちらのサイトですが、サイト内で使われているボタンやボックスなどが要素単位で管理されておらずCSSのセレクタが各パーツの親子関係に依存するような書き方となっています。
そのため「このボタンを使いたいけど他の場所に持ってくるとデザインが崩れちゃう…」という現象が発生しやすくなり、画面を跨いだパーツ単位での共通修正が難しい状態となっています。
そこで、サイトをAtomic Design化することでデザインシステムを整え、コンポーネント単位での管理ができるよう改善することになりました。
Atomic Design化
サイトのAtomic Design化に向けて、次のようなプロセスで進めていきました。
- パーツ洗い出し
- 課題抽出・修正
- コンポーネント分類
パーツ洗い出し
まず、画面内で使用しているすべてのパーツを把握するために全画面のキャプチャとパーツの洗い出しを行いました。
課題抽出・修正
洗い出しの結果、同じ機能を持ったパーツなのにデザインが微妙に異なっていたり、他では使用していない固有のフォントサイズやカラーを持ったパーツが存在していることがわかりました。
Atomic Designとして各パーツをコンポーネント化するためには、このような共通化されていないデザインを無くし矛盾を取り除く必要があります。
そこで、インタフェース・インベントリと呼ばれる手法を用いてチーム内で議論しました。
Interface Inventoryとは、Atomic Designで知られるBrad Frost氏によって提唱された、Webサービスやアプリケーション上の既存コンポーネントに関する議題を見つけ出すためのアクティビティです。 コンポーネント・UIパーツをカテゴリー分類することによって、プロダクト全体のコンポーネントの中で最新のデザインが反映されていないUIパーツや、共通化できていないコンポーネントなどを見つけ出すきっかけにすることができます。
引用元:https://techblog.yahoo.co.jp/advent-calendar-2018/interface-inventory/
今回は次のような手順で議論を進め、デザインの矛盾といった課題点の抽出や細かなスタイルの精査をしました。
- コンポーネントを切り出す
- カテゴリごとに分類する
- 役割/目的ごとにさらに分類する
- 分類したパーツのデザインを比較する
コンポーネント分類
作成するコンポーネントを明確にしたら、それらをAtomic Designへ落とし込むため各構成要素に分類しました。
分類の厳密な定義はプロジェクトによって異なるかとおもいますが、本プロジェクトでは次のように設定しました。
- Atoms
個々で存在できる最小のコンポーネント。<h1>
や<button>
など、HTMLのタグ1つ分に相当する。 - Molecules
2つ以上のAtomsまたはUtilsによって構成されるコンポーネント。 - Organisms
2つ以上のMoleculesから構成されるコンポーネント。 - Templates
OrganismsやMoleculesなどを内包したコンポーネント。 - Utils
アイコンやテキストなど、Atomsよりも細かい粒度で汎用的に使用するコンポーネント。
スタイルガイドの制定
コンポーネント作成の前に、コンポーネント間で使用しているカラーやフォントといったプロジェクト内の共通スタイルを定義するため、スタイルガイドを制定しました。
実装者目線でのちょっとしたこだわりポイントなのですが、各スタイルの命名はFigma上とソースコード上でブレないようにしています。
たとえば上記画像内の赤枠で囲われたグレーのカラー(#AAAAAA
)を示す場合、Figma上ではcolor/text/gray02
のカラーとなります。
次が該当箇所のソースコードです(vanilla-extractというCSS in JSのライブラリを使用しています)。
const color = { gray: { 1: '#666666', 2: '#909090', 3: '#aaaaaa', 4: '#cccccc', 5: '#eeeeee', }, ... } ... export const colorTextVariable = { black01: color.black[1], gray01: color.gray[1], gray02: color.gray[3], blue01: color.blue[1], blue02: color.blue[2], white01: color.white[1], green01: color.green[1], red01: color.red[1], } as const;
コード上でもcolorTextVariable.gray02
で定義しています。
デザイナーとエンジニアで会話をするとき、お互いが異なるスタイルを思い浮かべて認識齟齬が発生してしまう、ということのないように工夫しています。
Figmaコンポーネント化
スタイルガイドが定まったら、定義したスタイルを使用してFigmaコンポーネントを作成しました。
事前にインタフェース・インベントリを用いて議論し、作るコンポーネントの種類を明確にしていたのでスムーズに作業を進めることができました。
また、コンポーネントのバリアントもできるだけ実装で扱うReactコンポーネントのpropsに沿った内容となるよう、命名などを合わせました。
ここに関してはFigmaの機能の限界的に厳しいところもあるので無理のない範囲で作り込みました。
私自身今回まともにFigmaを触ったのが初めてなので、もっと改善の余地はあるかと思います。
ドキュメント作成
コンポーネント作成が終わったら、それらの仕様や各状態のスタイルの変化などが明確になるようドキュメントへまとめました。
ドキュメントの内容はデジタル庁が公開しているデザインシステムを参考にしました。
デジタル庁のデザインシステムは、各コンポーネントの種別や使い分けといった仕様面からWebアクセシビリティまで考慮されており、とにかくボリュームが凄いです。
開発メンバーが多い大規模なプロジェクトになればなるほど活きてきそうなドキュメントだなと思いました。
今回はページデザインを担当したわけではなかったのでここまでは作り込んでいませんが、実装時に迷わないようにという観点でできる限り情報の詰まったドキュメントを作成しました。
やってみて
1からデザインシステムを構築するのは初めての経験だったのですが、まさにデザインエンジニアという働きができてとても楽しかったです!
本件で作成したFigmaコンポーネントやドキュメントは、普段携わっている別のプロジェクトで抱えている問題を見ていて「こうやって解決できたらいいな」と思っていたことをすべて盛り込んだつもりです。
小規模なページだったのでここまで作り込むことができましたが、より大規模なプロジェクトになると情報伝達やドキュメント作成にかかるコストが膨大になってしまうだろうな…と思いました。
また、一番の課題としては度重なる仕様変更によるメンテナンス性を担保する必要があるためどこまで厳密にFigmaでカバーするかといった現実的なところは改めて考えなければならないなと思いました。
とはいえ、しっかりと整ったデザインシステムを構築し伝わる形でドキュメントにまとめておくことは後戻りの工程を少なくし実装をスムーズに進めることに大いに貢献できる大事な試みだなと感じました。
プロジェクト全体としてはまだ開発環境を整えたという段階で今回刷新したコードが本番サイトに使われるのはまだ先のことなので、実際にコンポーネント管理がしやすくなった、という恩恵を実感できる日が楽しみです。
今回得た知見を他の業務にも活かしていきたいですし、またこのような機会があればやってみたいです!
ここまで読んでいただきありがとうございました!