- 第１回AtomicDesignについて考える会に参加してきました。
thinkatomicdesign.connpass.com
- AtomicDesignに関して様々な視点からの考えが聞けて学びが多かったです。
- エンジニアとデザイナーあわさって、共通の考えを持って取り組むのがよいという意見が多かったです。
- AtomicDesignにこだわりすぎずプロジェクトの中での共通認識のベースにしていくというのが良さそうと感じました。
- パネルディスカッションでの質問の多さからもみんな悩んでるんだなってのを実感できました。
| タイトル | 発表者 | ロール |
|---|---|---|
| コンポーネント指向から見るAtomic Design | camcam_lemon (camcam_lemon) | フロントエンドエンジニア |
| デザイナー・エンジニアのコンポーネント分割境界と、その理想郷 | resessh (resessh) | フロントエンドエンジニア |
| AtomicDesignを導入する理由と悩み | sakito (mki_skt) | フロントエンドエンジニア |
| 手戻りが少ないアトミックデザインの導入 | fujiken (kenshirof) | デザイナー |
| Redaing The Atomic Workflow | 腹筋ローラーの力を信じろ (8845musign) | デザイナー |
| StorybookでAtomicDesignなコンポーネント管理してる話 | masaya (msykd) | フロントエンドエンジニア |
| サーバーサイドエンジニアがAtomicDesignを学んでみた | remsleep_zzz (remsleep_zzz) | サーバーサイドエンジニア |
| Atomic Design との上手な付き合い方 | takanorip (takanori_oki_9) | フロントエンドエンジニア |
コンポーネント指向から見るAtomic Design
- camcam_lemon (camcam_lemon)
- フロントエンドエンジニア
AtomicDesign
- 考えること多い
- よく分かってないままアプリ単位で採用してるから
- チームに合った設計を取り入れるのが正解ではないか
コンポーネント指向
- UIパーツを部品として使う
- 見た目と機能をカプセル化
- 粒度が小さいほど再利用性が高まる
UIライブラリ
- よく使うUIパーツを提供
- AtomsかMoleculesを提供する
- 再利用性に極振り
- ロジックは入り込まない
- UIライブラリのパーツに加えて再利用されないAtomsやMoleculesをアプリで作る
まとめ
- 小さい単位で考えると悩みが減る
- 再利用性に特化したUI設計に集中
- 小さく始めて大きくスケール
デザイナー・エンジニアのコンポーネント分割境界と、その理想郷
- resessh (resessh)
- Retty
- フロントエンドエンジニア
デザイナー視点
- ユーザ行動をベースに考える
- 画面を開いて関心のあるコンテンツを探す
- コンテンツを理解
- 手順を理解
- アクションを実行する
エンジニア視点
- コンテンツ内のレイアウトとコンテンツ外のレイアウト
- 外 -> サイドバーとかヘッダーとか
- データソースが決まったコンポーネントとそうでないコンポーネント
- Storeにアクセスできるかどうか
- Container Component / Presentational Component
コンポーネントの分類
- Organisms
- URLを持っていることが多い
- アクションも付随していることが多い
- 特定のデータソースに依存してもよい
- Molecules
- コンテンツが一つで完結しない
- 特定のアクションを行うUI
- 特定のデータソースに依存しない
- Atoms
- HTMLのタグに対応
- 迷う時は
- デザイナーとエンジニアが分類について対話できる環境があるとよい
AtomicDesignを導入する理由と悩み
- sakito (mki_skt)
- Yahoo
- フロントエンドエンジニア
なぜ導入したか
導入して抱えた悩み
- PagesとOrganismsどの単位でReduxをConnectするか
- プロジェクトの規模によりけり
- AtomsなのかMoleculesなのか
- エンジニアだけで導入してもダメ
- デザイナーのアウトプットとの認識齟齬があってはいけない
まとめ
- デザイナーとエンジニアで密にコミュニケーションをとる大事さは変わらない
- チームにフィットした形で柔軟に返ることも大事
Redaing The Atomic Workflow
- 腹筋ローラーの力を信じろ (8845musign)
- デザイナー
The Atomic Workflow
- 静的なカンプではなくブラウザに早く持っていくべき
- Role
- UX Designer
- Visual Designer
- Frontend Developer
UX Designer
- コンテンツの並びを書いたもの
- ページの構造と階層
- レイアウトを作らずに議論できる
Visual Designer
- The 20 second gut test
- ステークホルダーへ20秒ごとにページを見せて評価してもらう
- Style Tiles
- 色とかフォントとかをまとめたもの
- ビジュアルの洗練なしにレイアウトについて検討できる
- 静的カンプ
- 作らないわけではない
- 全体像を描くのには有効
- 段階が進んでからかく
Frontend Developer
- デザイナーと近い席に座るべき
- デザインプロセスのコアパート
- 先行してマークアップしていくべき
ワークフロー
- ブラウザでイテレーションすること
- 一度ブラウザでデザインしたらブラウザにとどまり続けるべき
- 意思決定を動くものでするべき
- パターンベースで回す
- 使い回せる
まとめ
- ブラウザで生きた設計を
- 常に全体を見て設計を
- AtomicDesignの本質はステークホルダー全員との合意形成プロセス
手戻りが少ないアトミックデザインの導入
- fujiken (kenshirof)
- Cookpad
- デザイナー
- komerco
- https://note.mu/fjkn/n/n9c8f8921b13c
開発初期
- 新規事業でAtomicDesignを導入
- デザイナー一人
- デザインデータが管理しきれなくなる
- このデザインどっかで使ってたけどどこかにあるか分からん
導入前
期待
- 管理が楽になる
- 使い回しの適用がしやすくなる
- スピードがあがる
導入してみて
- 地味
- 効率は上がるけどメンテが大変
- コンポーネントの整理に時間がかかる
導入するなら
- カトナ期待はせずに
- 定期的な整理整頓が待ってる
- 整理で進捗が止まることを伝えておこう
導入中
- 整理整頓そんなにうまくいかない
- 整理整頓してる暇がなくて大きくなってしまう
- コンポーネント化しすぎて無駄に時間かけすぎた
- 適度にやることが大切
導入後
- 曖昧さを許容すること
- コンポーネントの粒度どうしてますか?
- デザイナーとエンジニアで話し合ってる
- 見てる視点が違うから理解し合うことが大切
- 最初は特定の動作に特化した部品
- 徐々に汎用的な部品に
- ほとんどのデザインはすぐに消える
まとめ
- 導入前：覚悟をもとう
- 導入中：タイミングと量に注意
- 導入後：曖昧さを許容しよう
StorybookでAtomicDesignなコンポーネント管理してる話
- masaya (msykd)
- モノオク株式会社
- フロントエンドエンジニア
モノオク
- モノの保管場所に困ってるユーザとスペースが余ってるホストをマッチング
- React/Redux
Storybook
- コンポーネントの管理画面のようなもの
- AtomicDesignと相性抜群
Storybookいいところ
Storybookつらいところ
- メンテがめんどくさい
- 開発に追われていると時間がない
- コンポーネントマネージャーをおいた
まとめ
- Storybook便利
- 1,2人くらいのチームだとメンテコストのほうが高い
- 他と比べてメンテの優先度下がりがち
- 目的をもって運用方針を考えるべき
サーバーサイドエンジニアがAtomicDesignを学んでみた
- remsleep_zzz (remsleep_zzz)
- CyerBuzz / STARACT
- サーバーサイドエンジニア
導入事例
- うまくいった
- デザイナーがReactかけたり
- フロントエンドがAPI書いたり
- といった環境だったから
サーバサイドから見ていいところ
- 共通言語として使える
- 学習コスト少し高い -> 習得後のブレが少ない
- プロジェクトの途中から導入するるのはとても大変
- 開発速度の向上
- organismsとpagesだけにstateをもたせる
- それよりも小さい粒度はstatelessなので爆速で作れる
- Reduxみたいなところはフロントエンドエンジニアにまかせてコンポーネント単位で作り込める
まとめ
- サーバサイドエンジニアからみてAtomicDesignのメリット
- 共通言語としての役割
- 粒度間違えなければ開発爆速
Atomic Design との上手な付き合い方
- takanorip (takanori_oki_9)
- フロントエンドエンジニア
思うこと
- AtomicDesignに真面目すぎる
- 設計の手助けのはずが難しくしている
- 大雑把に付き合うことが大切
- そこが本質ではない
意識すること
- 最小単位(Atoms)を意識すること
- それ以外はある程度全体見えてきてからでよい
なぜつらい
責務を分ける
- Pages/TemplatesとOrganisms以下の責務の分離
- Organisms以下はそのコンポーネントのことしか知らなくていい
デザイナーを巻き込むこと
- エンジニアだけでこういう話をするのは良くない
- デザイナーにAtomicDesignの概念をフローに入れてもらう
- 単位はデザイナーに決めてもらうのがいい
