本稿は(序)(破)(Q)のシリーズの2番目の記事(破)になります。
シリーズ(序)ではAtomic Designの概要 を、
シリーズ(Q)ではAtomic Designの実装例を説明していますので、そちらをご覧ください。
Atomic Design(アトミックデザイン)とは、UI(画面)をコンポーネント単位で設計し、それらを組み合わせて使い回し可能なUIを作成するための手法です。
Atomic Designの考えのものとUIコンポーネントを切り出していくことはいくつかの利点があります。
しかし、Atomic Design はUIを構築するための方法論でしかありません。
つまり、デザインや実装方法、運用方法は独自に考える必要があります。
実際に導入してみるといくつか乗り越えなくてならないハードルが存在することがわかりました。
本稿(破)ではそのハードルを乗り越えるために、どのような工夫したのかを紹介します。
同様に困っている現場の参考になれば幸いです。
本稿の対象読者
- Atomic Designを導入してでた課題を他の現場がどう解決しているか気になる方
導入に際してやった3つのことについて説明します。
導入に際してやったこと1:コンポーネントの具体的な定義
各階層のコンポーネントの仕分け方で悩むことが多かったため、具体的なコンポーネントの定義をして共有しました。
※以下でPowerPointという言葉が出てきますが、一旦まずは定義を紹介します。
Atoms(原子)
- リンクやボタンやフォームのパーツ単位など UI の最小要素
- 見た目に関することはこのモジュールで表現する
- PowerPointの一つの図形で表現できるもの
(ラジオボタン・セレクトボックスなどのフォームは例外)
Molecules(分子)
- AtomsとMoleculesから構成されるグループで、比較的小さいコンポーネント
- 中身の文言や配置を変えることで使い回しが可能なもの
- 別のOrganismsを跨いで出現するもの、または、これから出現することがわかっているもの
- PowerPointの図形をグループ化して表現するもの
Organisms(生命体)
- AtomsとMoleculesから構成されるコンポーネント
- 広告のバナーのように、どのページに配置しても意味がわかる独立したコンポーネント
- デザイン上初めてでてくるもので、比較的小さいコンポーネントだが使い回すかどうか不明なもの。 (
未知の生命体
) - 幅を固定しないとデザイン通りにならない、使い方が限定的なもの。
- PowerPointの図形をグループ化して表現するもの。
Atoms(原子)の説明
概念ではAtomsの粒度は、ラベル、入力フォーム、ボタンなどHTMLタグレベルになります。
しかし、実装していると、ラベル単位では粒度が細かすぎるように感じました。
粒度が細かすぎるとそれをコンポーネント一覧に登録することが手間だし、増えすぎてコードの見通しも悪くなります。
そこで、細かすぎずチーム全員が「これは最小単位のモジュールだ」と機械的に判別できる何かを探して辿りついたのがパワポの図形です。
パワポの図形を使って以下のようにatoms(原子)を定義しました。
Components | Definition |
---|---|
Atoms | パワポの図形1つでつくれる単位 |
Molecules, Organisms | パワポの図形をグループ化してつくる単位 |
この考えでいくと、例えば次のように仕分けすることができます。
Atoms(パワポの図形1つでつくれる)
Molecules(パワポの図形をグループ化してつくる)
上の例ではAtomsにもMoleculesにもbutton
があります、これをつくることでボタンの中にアイコンをいれたボタンをつくりたい場合に、最小単位のアイコンを、最小単位であるはずのボタンが制御しなければはならないというジレンマを解消します。
またこれにより、Atomsのbutton
は内側にあるアイコンの位置などは指定せず、色やフォント、シャドウのみを表現することに専念し、最小構成に保つということを守りつつアイコンや他のUIパーツを組み合わせたボタンを作成することができます。
※注意点
図形をグループ化して作ったコンポーネントの中にあるプレーンな「タイトル」や「テキスト」はグループ化して作ったコンポーネントの要素にします。
たとえば、上の図のcard
は2つの図形でできているためMoleculesにしますが、
グループ化した後の「タイトル」と「テキスト」はAtomsとして切り出すのではなく、card
の「タイトル」と「テキスト」になります。
そうしないと、結局Atomsの粒度が細かくなりすぎてしまうためです。
パワポの発想はチームの体制が関係しています。
UI/UXディレクションとビジュアルデザインをやる人が別だったため、下のようなフローで作業していました。
①UI/UXディレクターがパワポの図形を使ってワイヤーフレームを描く
②それを基にデザイナーがデザインカンプをつくる
③フロントエンドエンジニアがマークアップ
画面をつくるときの起点はUI/UXディレクターで、UI/UXディレクターは図形をグループ化したり、コピペしてワイヤーフレームを作成していました。
そこで、コンポーネントをパワポの図形単位で考えるといいのではないかと思いつきました。
Molecules(分子)とOrganisms(生命体)の説明
Atomic Designの悩みどころにMoleculesとOrganismsの判別があります。
概念では「Moleculesは比較的単純で、Organismsは複雑で大きいコンポーネンント」であるとしていますが、判断できないコンポーネントが出現し、その都度悩みます。
そこで、まずOragnisms(生命体)について調べてた結果、独立したコンポーネントと考えるのがよいと感じました。 具体的には「広告バナーのようにどの別のページでもそのまま使えるもの」です。
下からフェードインしてきたり、フローティングしてたり、埋め込まれてたりと大小様々な広告がありますが、どの画面にでても意味が通じます。
さらに、広告には必ず訴求文が存在します。画像でもいいのですが、訴求文があるか、ヘッダーやフッターなどなくても意味がわかるコンポーネント、それを独立したコンポーネントとしました。
次に、Molecules(分子)は適当につくると無駄に膨れ上がってしまうので「Organismsを跨いで使われている、使われる可能性があるもの」としました。
親子コンポーネントの子コンポーネントに相当しますが、親から離れて別の親にも付いて行っちゃう子です。
最後に、Organismsの子コンポーネントとして切り出したが、今後別のOrganisms内で使われるかわからない場合(Moleculesにするか悩む場合)があります。
そんなときは、未知の
生命体ということで、一旦Organismsにすることにしました。
安易にMoleculesにせず、一旦Organismsにして、Organismsを跨いで使うようなコンポーネントだとわかればMoleculesにリファクタします。
悩む時間がもったいないし、Moleculesにしても使わない可能性が高いからです。
ここまで説明した仕分け方法をフローチャートで表現すると以下のようになります。
導入に際してやったこと2:コンポーネント一覧の作成
コンポーネントを作りすぎると、探すのが大変になりました。
増えていくと、探すのをあきらめて新しいファイルを作成してしまうかもしれません。
デザイナーも忘れて新しくデザインしてしまうかもしれません。
この問題に対しては単純な話ですが、コンポーネント一覧を作成しました。
Atomic DesignのUIコンポーネントを一覧化に使えそうな3つのツールを紹介します。 どのツールを使うかはデザイナーの有無と使用しているフレームワークによって変わってきます。
Zeplin
Sketchでデザインしたコンポーネントをエンジニアとシェアすることができます。デザイナー主導になります。デザイナーのスキルが必要です。
[参考]ZeplinとSketchを連携してエンジニアとデザイナーの仕事を円滑にしよう | ShareWis Press(シェアウィズ プレス)patternlab
Atomic Design考案・著者のBrad Frost氏が数名の開発者と開発したオープンソースのツール。React、Vueは不要ですが、あくまでスタイルガイドなため、メンテが大変かも。
Sketchと合わせてつかう方法が以下の記事で紹介されています。
[参考]珍しいワークフロー:Atomic Designの原則とSketchでデザインからプログラミングまで | POSTDStorybook
ReactやVue.jsを使用しているプロジェクトではおすすめです。(賛否両論あるようですが)
[参考]Storybook+AtomicDesignでデザイナーが開発に参加した話 | Nagisaのすゝめ
本シリーズ(Q)では、Storybookを用いた具体的な開発例をご紹介したいと思います。
一覧化手順について、Atomic Designの考案・著者のBrad Frost 氏が Interface Inventory というものを提唱しています。
コンポーネントを分解してKeynote等でリスト化する手順を説明しているもので、コンポーネントがチーム共通の認識で正しく切り分けられているかを振り返りには有用かと思います。
ただ、開発前はKeynote等でもいいかもしれませんが、Web上で確認できるようしておいた方が使い勝手がよいかと思います。
上で紹介したツールはどれもWeb上で確認できるツールです。
導入に際してやったこと3:デザイナーとフロントエンドエンジニアで認識合わせ
デザイナーとフロントエンドエンジニアで進め方の認識合わせを行いました。
やったことは主に次の3つです。
①Atomic Designを導入する目的とコンポーネントの階層定義を共有
先述した定義をデザイナーとフロントエンドエンジニアで共有します。
UIがAtomic Desingの考え方で階層分けされるとフロントエンド実装ではとても助かるので短絡的に導入しがちです。
しかし、デザイナーからするとパーツからつくっていくのはかなり難しいため、デザイナーの理解が必要です。
いきなりコンポーネント指向でデザインするのは大変なので、開発初期はデザイナーは今まで通りページ単位でデザインし、フロントエンドエンジニアがUIコンポーネントに分けるフローにしました。
のちのちUIコンポーネントが溜まってきたらUIコンポーネントを使いながらデザインしたり、慣れてきたらデザイナーがコンポーネント分割をやることを目標にします。
Atomic Designを導入する目的は、UI(画面)をコンポーネント単位で設計し、それらを組み合わせて使い回し可能なUIを作成するためです。
そうすれば、(私の現場に限った話ですが)ゆくゆくはUI/UXディレクターもOfficeの図形でお絵かきではなく、コンポーネント一覧からコンポーネントを選び出しデザイナーなしでデザインカンプをつくれるようになるだろうし、さらに将来的にUI/UXディレクターが何かしらのツールで組み合わせたらマークアップも終わっている状態もつくりだせるとかもと思っています。
②色、タイポグラフィ、余白は無限につくらず段階的に拡張できるようにしておく
例えば、CSS設計手法のBEMを使用しているならば、
.someClass--s { ... margin: 10px; .... } .someClass--m { ... margin: 15px; .... } .someClass--l { ... margin: 20px; .... }
といった3段階まではmodifierを用意して変えられるようにしておきます。
拡張できるのはその段階までとデザイナーと認識あわせしておき、デザイナーはそれ以上の幅を持たせないように気をつけます。
③エンジニアからフィードバックする
コンポーネント切り出しをエンジニアが担っているならば、既にコンポーネント化しているかどうかはエンジニアが発見しやすいです。
なので、段階的な拡張の範囲外だったり、意味合いとして一緒なのに微妙に違うデザインを発見した場合は、エンジニアからデザイナーにフィードバックするよう心がけます。
(破)のまとめ
実際に導入してみて出てきた問題点に対して工夫したことを紹介しました。
Atomic Designの理論と実装にはいくつか折り合いをつけなくてはならない点がありそうです。
最近ではReactやVue.jsのstyled-componentsという CSS in JSのライブラリがAtomic Designと相性がよいため、Atomic Designが再注目されています。
qiita.com
次の(Q)では、このstyled-componentsを使ったAtomic Design実装の紹介と、フレームワークを使わない従来のHTMLとCSSだけでやった場合の両方をご紹介します。