デザインシステムについての知見が溜まってきたので、The 12 Factor App のパロディで The 12 Factor Design System というものを考えてみました。
元ネタのThe 12 Factor AppはモダンなWebアプリケーションとしてあるべき姿を12のベストプラクティスにまとめた方法論です。
それを真似て、自身の経験からデザインシステムとしてあるべき姿を12個にまとめてみました。
無理やりなところやコンテキストによるところがあると思いますが、半分ネタ半分本気で作りました。
文章の構成などもあえて真似て書いています。
何かの参考になればと思います。
はじめに
デザインシステムは次のようなWebサービスやアプリを作り上げるための方法論です。
- 宣言的なフォーマットを使い、プロジェクトに新しく加わったメンバーが要する時間とコストを最小化する。
- UIパーツの依存関係を明確化し、ページ間での移植性を最大化する。
- スタイルガイドやモックページと本番環境の差異を最小限にし、アジリティを最大化する継続的な更新を可能にする。
- 明文化されたデザイン原則に従い、サイトのブランドを損なうことなくサービスをアップデートする。
Twelve-Factor Design System の方法論は、どのような現場にでも適用できます。また、どのようなデザインツール（AdobeXD, Figmaなど）やフロントエンドフレームワーク（React, Vueなど）の組み合わせを使っていても適用できます。
背景
このドキュメントは、あるサイトの開発現場でのフロントエンドエンジニア（FE）とデザイナの経験と観察をまとめたものです。
これは、サイト開発における理想的なプラクティスを見出すための三角測量です。
特に、以下に注目しています。
- サイトが時間と共に有機的に成長する力学
- デザイナーとFE間のコラボレーションの力学
- サイトのデザイン/実装の腐敗によるコスト回避
また、私たちの動機は、サイト開発での変更に対する問題への関心を高めること、この問題を議論するための共通の語彙を提供すること、そしてこの問題に対する広い概念的な解決策と専門用語を提供することです。
Ⅰ. 明文化
プロダクト作成に関わる人々が価値に賛同し、その実現に尽力するために以下のことを明文化します。
- プロダクトの目的と価値：サイトの対象ユーザーとその目的、ニーズ、動機を理解します。
- デザインで解決したい課題：デザインで何を解決しようとしているのかを明らかにしておきます。
- デザイン原則：プロダクトの目的を表現する基盤となる原則を確立します。デザインする上で迷わなくします。
ただ、測定や数値化ができないので、定義は反復作業しながら徐々に作られていきます。
Ⅱ. コードベース
Twelve-Factor Design System ではGitやAbstract などのバージョン管理システムで、常に変更を追跡しています。
コードベースとはこのGitのリポジトリとAbstractのプロジェクトのことを指します。
コードベースとアプリケーションの間には、それぞれ１対１の関係にあり、サイト開発に対してGitリポジトリが複数あったりAbstractプロジェクトが複数あってはなりません。
Ⅲ. コンポーネント分割
原則、サイトのページはすべてUIパーツに分割され、定めた階層に整理されます。
サイトでの分割の仕方はプロジェクトで決めたフローに合わせてデザインも実装も分割していきます。
例えば、Atomic Designという概念を用いる場合、Atoms、Molecules、Organisms、Templates、Pages の５つの階層に分けられます。
ただ、AtomsとMoleculesとOrganismsの違いが曖昧になってしまう可能性がよくあるため、事前に必ず関係者でその定義を明確にしておきます。
Ⅳ. 依存関係
すべてのUIパーツは関係者で定めた階層構造に従い整理します。
Atomic Designでは、大きいパーツは小さいパーツを使うという依存関係が存在します。
Atomsの中でMoleculesを呼び出したり、Moleculesの中でOrganismsを呼び出したりしてはいけません。
どのような命名規則で階層をつくってもよいですが、この依存関係は壊してはなりません。
Ⅴ. スタイルの設定
サイトをデザインする上で最低限必要なスタイルを定義します。
例えば
- 色
- フォントサイズ
- タイポグラフィ
スタイルは明文化されたプロダクトの目的と価値、解決したい課題、デザイン原則から作り出します。
FEはこのスタイルを定数やテーマとして定義します。
コードからはその定数を利用し、原則マジックナンバーを用いてはなりません。
Atomic Design の５階層とは別に、スタイル設定用の階層（foundations、ions、styleguideなど）を作成し、そこに定義したファイルを格納します。
Ⅵ. 再利用
原則、既存のUIパーツのデザインとコードを活用して、新たなサイトページを構築します。
その際にパーツは可能な限り再利用可能な状態にし、LEGOブロックのように他のパーツと組み合わせて使えるようにします。
ただし、繰り返し利用可能な箇所がない精巧にデザインされたページも有用な場合もあります。
関係者で話し合い、どちらが良いかを吟味します。
Ⅶ. 一覧化
すべてのUIパーツはパターンライブラリとして一覧化します。
一覧に載せるコンポーネントは階層で分けられており、関係者で吟味されたもののみが一覧になります。
また、各コンポーネントには利用用途などの事業側にも有益な説明を記載しておきます。
関係者全員が参照できるようにします。
Ⅷ. デザイン、ビルド、リリース
基本的な作業の流れの前提として、ワイヤーフレームからデザイナーがデザインをおこし、FEはそのデザインをみて実装を行います。
実装前にFEはデザインをみて、すでに作成したコンポーネントはないかなどを確認し、ある場合はデザイナーと話し、再利用できないかを相談します。
実装がおわったらソースコードのビルドとパターンライブラリの更新を行い、関係者に向けて公開します。
検証環境で確認が完了したらリリースします。
Ⅸ. 廃棄容易性
UIコンポーネントを議論するうちに、見た目はかわらないが実装を修正したい場合があります。（テーマの名称変更など）
この際、簡単にコンポーネントを捨てやすくするために、FEはUIコンポーネントを格納したパッケージにバージョン番号も含めておきます。
ソースコードは以下のようにディレクトリを分けて、段階的にバージョンアップできるようにしていきます。
原則、最新バージョンのコンポーネントを使い、古いバージョンは非推奨にします。
├ molecules │ ├ Accordion │ │ ├ _v2 │ │ │ └ index.js │ │ ├ _v3 │ │ │ └ index.js │ │ └ index.js │ │
Ⅹ. デザイン/本番実装一致
デザインとFEが実装したページの見た目のギャップは最小限になるようにすべきです。
そのため、デザインツールで共通パーツ化したもの（Sketchのシンボルなど）と実装したUIコンポーネントの名称をなるべく一緒にしていきます。
Ⅺ. 意思決定のログ
デザインする際に決まったことはADRに書き残していきます。
ADRとはArchitecture Decision Recordの略で、重要な意思決定とそのコンテキストおよび結果を記録するための手法です。
小さくまとまりのあるドキュメントを心がけ、将来のデザイナー/開発者との会話であるかのように記述します。
フォーマットは以下。
タイトル：「001: 〇〇ページのトンマナについて」
ステータス：承認、却下、保留
コンテキスト：結論にいたった背景など
決定事項：決定事項
結果：導入した結果
Ⅻ. 監視
パターンライブラリが見れなかったり、足りていなかったり、記載されている利用用途などの説明が不十分であったりと、パターンライブラリが腐敗しないように稼働状況を確認します。
自動システムでは監視できないので、頻繁に確認する人（デザインシステム警察）をアサインします。
