はじめてのAtomic Designのプロジェクトでやっておいた方がよかったことリスト

Livesense not engineers Advent Calendar 2018 の11日目を担当いたします、@mokddです。
普段はデザイナーだかエンジニアだかよくわからないスタンスで転職会議というサービスに関わっています。

ここのところReact.jsやVue.jsなどでAtomic Designを取り入れたプロジェクトがいくつかあったのですが、諸々つまずいた点などを踏まえて**「これはやっておけばよかったな…」**というのをあげてみたいと思います。

ちなみにデザイナーはざっくりこんな感じで運用して、

• sketchでデザイン作成

• POとはinvisionで共有＆フィードバック
• 開発側はinvisionで状況を把握しつつ、Zeppelinでデザインファイル共有

エンジニアはざっくりこんな感じで開発してました。

• React.jsやVue.jsを採用

• cssはcss modules、もしくはコンポーネント内でスコープ化
• Storybookでモック確認

1. Kick Off編

Atomic Designでやっていくという合意形成

うまく設計できて運用フローに乗せられれば素晴らしいのですが、最初のうちは意外とコストもかかるし、考慮する点も多くなります。
リリーススケジュール・デザイン設計・開発フローなどを含め、 **合意がないまま始めると、個々の考慮漏れが影響しやすくなり、炎上のリスクが高まります。**エンジニア・デザイナー・POなど、プロジェクトに関わる人全員で合意をとっておくことをおすすめします。

Atomic Designとは何を指して言っているのか、共通認識をもつ

Atomic Designに対する認識ずれがあるとのちの悲劇を生むため、始める前にAtomic Designとは何を指して言ってるのか、どう開発していくのかを揃えておきます（単なるパーツ分解だと思っている場合もあるので）。
再利用性を意識したコンポーネント設計やAtomic Designそのもののフレームワーク認識、エンジニアリングの実装と運用をどうしていくのかなどを含めて、認識合わせをすることをおすすめします。特にエンジニアとデザイナーは見ている部分が違うことが多いので、最初にじっくり話した方が安全です。

Atomic Designで目指すゴールへのざっくりロードマップ

「これを足がかりに、ゆくゆくはデザインシステムの運用に載せていきたい」のか、「とりあえず影響範囲の少ない所で、新しいことを試してみたい」のか…では、取り組むスタンスが大幅に変わります（前者は先を見据えて考慮・リファクタする必要あり、後者はゆるふわでもセーフ）。最初に決めておくのが無難です。

SP・PCなどの切り分けに対する見解を決める

レスポンシブ or NOTなど、どうやって実装してくかによってデザイナーのデザイン設計プラン・エンジニアの実装プランが変わるので、早めに決めておくのが無難です。「タブレットはどうするか」とかも決めておくと良いです。

適用範囲を決める

厳格にAtomic Desighをやっていくのか、それとも「テキストなどは柔軟にサイズ変える可能性があるから管理外にする」みたいな取り組み方にするのかを先に決めておきます。特にデザイナーさんは、柔軟にしておきたい部分を先にピックアップして共有できるようにしておくと良いと思います。

2. デザイナー編

ピクセルパーフェクトに別れを告げる

Atomic Designはピクセルパーフェクトと相性が良くないです（と思います）。
下手をすると無限に増えるコンポーネント地獄に陥ってしまう恐怖があるので、個別最適化することは極力避けて、再利用性や抽象化を意識してデザインを設計していきます。

概念定義や振る舞いを意識してデザイン設計する

• そのコンポーネントはどんな時に使うものなのか
• 期待される動き・振る舞いは何なのか
• 結びつく概念は統制が取れているか
• 上記を踏まえつつ、操作や認識の統一性は取れているか

などを意識してコンポーネントを作ると、Atomic Designに相性が良いデザインファイルになります。シンボル名などに関しても、GreenBtnよりもPrimaryBtnやDefaultBtnの方がどんな場面で使われるのかが推測しやすく、実装との乖離も少なくなるためおすすめです。

Sketchのシンボル化は実装を意識して行う

Sketch => Zeppelinでデザインファイルをやりとりする場合は、変更に強い&データに落とし込みやすい様にシンボル化してもらえると、みんな幸せになります。
ボタンなんかはこっちよりも

こっちの方が喜ばれますし、

アイコンはアートボード(viewbox)のサイズを揃えるのは当然として、見た目のサイズ感も揃えてもらえた方が微調整が発生せず助かります。

構造化を試みる

コンポーネントのバリエーションを整理して構造化しておきます。
モック作成時にサイズなど微妙なバラツキが多いコンポーネントは、よきところで棚卸ししてサイズルールやSP/PCの切り分けルール、カラー概念の齟齬がないか…などを可視化しておくと、後々実装&運用しやすくなります。

「デザインファイルはズレていることもあります」という免罪符を発行

エンジニアはもちろん、自分以外のデザイナーも「この1pxは意図的なのか、それともズレなのか…？」ということはわかりません。正確なデザインファイルをきちんと作れるなら問題ないですが、そうでもない場合は「自分のデザインファイルはズレるので、よしなに合わせてください」という免罪符を先に出しておくと、みんな安心してコードに起こすことができます。
その際は、

• margin padding設計（ex: 自分の場合は8、もしくは4の倍数で作ってますとか）
• font-sizeルール （ex: 偶数で作ってますとか、ベース16でフィボナッチで作ってますとか）
• paletteルール（ex: 先に使用paletteをFIX、それ以外の色が出てきたら近い色に置き換えてくださいとか）

のように、数値で表せる指示を共有しておくのがベターです。
ズレのないデザインファイルを作るのであれば、（Sketch前提ですが）

• 実装を意識したシンボル化
• palette・style登録を利用してゆらぎを防ぐ
• Anima、ButterやPaddyなど、レイアウト作成支援のプラグインを利用する

などは日常的に取り組んでおくと良さそうな気がします。

3. エンジニア編

コンポーネント粒度の認識をすり合わせる

コンポーネント粒度は常に議論が別れる問題なので、チーム内で認識を揃えます。
正直オレオレルールでも、チーム内で揃っていれば運用できる気がしているので、一人ジャッジマンを用意しておくと紛糾しなくていいんだろうなーと思います。

命名規則を決めておく

「このタイプコンポーネントは何と呼ぶか」「suffix or prefixで行くか」など、命名に関しての認識を揃えておくと、統制が取りやすく、後に運用しやすくなります。
現実と命名に乖離がある場合は、すぐにリファクタすることをオススメします。

コンポーネント実装方針を決めておく

個別の解釈で実装すると、それぞれの影響が推測しにくく、事故が起こる可能性もあります。

• Atom・Moleculesにレイアウト要素は入れない
• stateの分離ルール
• 見た目とロジックの分離ルール
• コンポーネント登録ルール（ex: Buttonは1ファイルにまとめる or 種類ごとに登録？など）

くらいは共通認識を持っておくと良さそうです。

Storybookにknobsやinfoなどのアドオンを入れる

複数人で触る場合、props地獄でもはやよくわからない・このコンポーネント何に使うんだ問題が起きやすいので、Addonを活用して共有できるようにします。
infoはデザイナーさんに「どんな場面で使うのか」などを書いてもらえると、より後世の人が使いやすくなりそうです。

• knobs ：propsの動的確認
• info ：コンポーネントに関する情報（description・source・props一覧）を表示

4. 進行中編

各自MUST / WANT HIGH / WANT LOWを意識する

リリースまでに最低限揃えたい部分と+αの部分を切り分けて、認識を擦り合わせながら進めていきます。
全体感を見ながら「それは今は待ってくれ」「それはあとでも平気なやつだ」などを日々共有できる状況ができればベストです。ちなみに個別要望に答えすぎていると「あれ、これ全然リリースできねえや」ということになります。

デザイン変更フロー・実装タイミングのすり合わせ

ぬるっとデザインファイル修正 => エンジニア「あれ、なんか変わってる…？」 => 永遠に続くいたちごっこの予感に戦慄…という図式が発生するとプロジェクトが紛糾するので、デザインのFIXタイミングと共有タイミング、その伝達方法などはPO・デザイナー・エンジニアそれぞれが意識しつつ取り組むと良い気がします。
また、デザインと実装は一旦切り分けて、デザイン的な調整はまとめて最後にする手段もあります。その際はロジックやコンポーネント構成が大幅に変わりそうなところがあれば、エンジニアからデザイナーに対してあらかじめ共有しておくと事故が少なくなります。

リファクタチャンスは早めに指摘しあう

後からまとめてリファクタを考えると、つらい&げんなりしてしまうので、「このコンポーネント、抽象化できるんじゃない？」と思ったタイミングでお互い指摘するとスムーズです。エンジニアさんの間だけでなく、デザイナーさん含めてガンガン「コンポーネント自体」を直し続けられると、よりAtomic Designが活きてくる気がします。

最初から完璧を目指さない

本当に心が折れるので、なんとなく動く状態を作ってから個別に調整をかけた方が精神衛生上良いかと。

まとめ

なんだかほとんど同じことばかり言っている気がしますが、

• 関係者内での認識すり合わせ
• 相手の立場を考慮する
• 状況把握・周知は常にやっておく
• 遠慮せず指摘しあって、積極的に妥協する

あたりを意識しながら、「みんなでAtomic Designで良いプロダクトにしていくぞ！」という「やっていく気持ち」を持って生きたいと思います

あと、みんな同じ本・同じ参考記事を読んでおくと意識の統一がしやすく、捗るんでおすすめです
Atomic Design ~堅牢で使いやすいUIを効率良く設計する