Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Adobe XDで始めるAtomic Design
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
assialiholic
June 22, 2019
Design
4.3k
6
Share
Adobe XDで始めるAtomic Design
2019/6/22 のAdobe XD ユーザーフェス 2019 (札幌) で発表したスライドです。
assialiholic
June 22, 2019
More Decks by assialiholic
See All by assialiholic
人生最強のコアスキル a.k.a 開発業務から日常にまで使える最強のスキルについて
assialiholic
0
850
地方都市でもできる! 最新ツールと泥臭さのブランディング
assialiholic
0
540
5年先も第一線で戦えるwebディレクターであるために
assialiholic
3
800
JBUG (札幌#3) LT「大事なことはコメントだけに書くなぁ!」
assialiholic
1
1.1k
ディレクション資料をXD化してわかった、XDのメリットと課題
assialiholic
2
580
デザイナーとコーダの溝を埋める、テクニカルディレクションにおけるXDの活用事例
assialiholic
3
800
Developer meetup for beginners 「札幌ITひよこ会」 webのミライ、web屋のミライ
assialiholic
0
370
webマーケティング手段のいままでとこれから〜ボストン直輸入の新鮮ピッチピチネタをお届けします〜
assialiholic
1
580
最近よく聞くマーケティングオートメーションって?なにがいいの?
assialiholic
1
520
Other Decks in Design
See All in Design
チームをデザイン対象にする / Design for your team
kaminashi
1
1.4k
UI/UX & Web Design Portfolio 2025|Madoka Kumagai
madoka_portfolio
4
240
デザインとフロントエンドの境界が融ける Claude Code × Figma
littlebusters
1
2.8k
全員がアウトプットを出せる時代、 誰を採用する?
nishame
0
550
保育現場にAIを 〜人と技術に橋を架けるデザインで考えてきたこと〜 uiuxcamp2026-hoiku-ai-design
hiro93n
1
250
図面資産×AI 眠れる資産を起こす挑戦
aonomasahiro
0
120
コンテンツ作成者の体験を設計する
chiilog
0
170
root COMPANY DECK / We are hiring!
root_recruit
3
28k
再設計される業務 - AIにより再設計される "デザインワークフロー" / AI Ops Lab #2 Redesigned orkflows
kgsi
0
650
プロダクトデザイナーに学ぶ、『見る気が起きる』ダッシュボードの作り方 / Creating Engaging Dashboards: Lessons from Product Designers
yamamotoyuta
2
820
2026_01_07_3DプリントはじめましたLT.pdf
hideakitakechi
0
190
デザイナーとエンジニアで 同じ山に登ろう
moco1013
0
220
Featured
See All Featured
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
360
The Curious Case for Waylosing
cassininazir
1
360
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
410
Chasing Engaging Ingredients in Design
codingconduct
0
200
For a Future-Friendly Web
brad_frost
183
10k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
10k
Building Applications with DynamoDB
mza
96
7k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
200
[SF Ruby Conf 2025] Rails X
palkan
2
1k
Six Lessons from altMBA
skipperchong
29
4.2k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
23k
Transcript
自己紹介 ・会社:24‒7/パンセ ー テクニカルディレクター/シニアエンジニア ・ブログ:Thinking Salad ・マーケティングからコンテンツ制作からUI設計からエン ジニアリングまで割と何でも器用貧乏
Bracketsの本を出しています 最近アップデートしていなくてアレですが…
PRECSSというCSSアーキテクチャも作っています OOCSS、SMACSS、BEMをベースにした中規模以上向けCSSアーキテクチャ http://precss.io/ja/
Adobe XDで始めるAtomic Design Adobe XD ユーザーフェス 2019 (札幌)
Atomic Designとは
Atomic Designとは ・Brad Frost氏によって提唱されたデザインシステム構 築、運用の方法論 ・UIを以下の5つの粒度に分解して整理しているのが特徴 ー Atoms(原子) ー Molecules(分子)
ー Organisms(有機体) ー Template(テンプレート) ー Page(ページ) http://atomicdesign.bradfrost.com
なぜAtomic Designが必要なのか? ・別Atomic Designでなくてもよい ・ただし、いずれにしても「UIをロジカルに整理する」というアプローチはあった方がよい ー デザイン的な観点でも、それを実装するコード的な観点でも ・現状世界的に1番有名で、受け入れられているのがAtomic Designというだけ
恐らくUIが整理されていないで あろう、某webサイト
None
左に右向きの矢印、テキストの後に鍵アイコン
矢印がなぜか右に!?(しかも大きく) 突然現れた角丸ボタン。どうやら「戻る」系は角丸らしい
どうやら「戻る」系は角丸らしい そうでもないらしい。左向き矢印は当然左に。 (さっき右向き矢印が左についてなかったっけ…?)
ボタンオールスターはこんな感じ
ボタンオールスターもう1つ。同じUIパーツかと思いきや……
ボタンの位置と余白が全然違う…!
UIが整理されていないと ・運用を進めれば進めるほど、「同じ機能・異なるパターン」のUIが増えていく ー ユーザーを戸惑わせる原因になりかねない ー ユーザーが戸惑えば、当然ページ遷移が上手くいかず、CV率の低下に ・異なるパターンのUIであれば、当然エンジニアも新たに実装しなければならない ー その工数無駄では?
Atomic Designの考えるUI整理論 http://atomicdesign.bradfrost.com
Atoms(原子) ・1番最小単位となるコンポーネント ・どのwebページでも使用され得る、例えばボタンやinput 要素、タイトルなど ・「これ以上分解できないもの」と捉えるとわかりやすい http://atomicdesign.bradfrost.com
Atomsの例 http://atomicdesign.bradfrost.com
Molecules(分子) ・Atomsが集まり、グループを形成したもの ・比較的小さめなUIパーツの集合 ・コンポーネントとして機能を持ち始める ・「単一責任原則」に倣い、1つのMoleculesが持つ機能は 1つであるべき http://atomicdesign.bradfrost.com
Moleculesの例 http://atomicdesign.bradfrost.com
Organisms(有機体) ・AtomsやMolecules、他のOrganismsの組み合わせか らなる比較的複雑なUIグループ ・Organismsの中に他のOrganismsも含められることが 粒度のポイント ・特定のエリアを大きく形成することが多い http://atomicdesign.bradfrost.com
Organismsの例 http://atomicdesign.bradfrost.com
Organismsの例 http://atomicdesign.bradfrost.com
Templates(テンプレート) ・今まで出てきたもののを組み合わせ、レイアウトを形成し たもの ・実際に使用する画像やテキストなどのコンテンツは考慮せ ず、あくまでレイアウトや構造の定義に留まる http://atomicdesign.bradfrost.com
Templateの例 http://atomicdesign.bradfrost.com
Page(ページ) ・前述のテンプレートに、実際に画像やテキストなどのコン テンツなどを適用した形 ・webページとしてそのまま公開しても差し支えないもの http://atomicdesign.bradfrost.com
Pageの例 http://atomicdesign.bradfrost.com
Atomic Designに基づいて XDでデザインしてみる
ファイル構成(全てクラウドドライブ) Atoms.xd Molecules.xd Organisms.xd Templates.xd Pagesはサイトに公開される状態なので、HTMLに任せて必ずしもデザインデータは作らなくて良いと思っています。お好みで。
なぜファイルを分けるのか? ・全て1つのXDファイルにまとめてしまうと、コンポーネントが増えたときに探すのが大変なため ・どれがAtomsなのか、Moleculesなのかなどを強く意識するため ・Q. いろんなファイル行き来するのめんどくさくない? ・A. 若干めんどくさいです。が、やはり1つのファイルの肥大化は避けたい ・デザインが進んでコンポーネントが増えたときに、後々これが必ず効いてくる
なぜクラウドドライブなのか? ・クラウドドライブのファイルは、アセットソースとして参照することができます ・アセットソースごとに、コンポーネントのフィルタリングも可能
アセットソースの指定方法
コンポーネントのフィルタリング
しかし粒度が1つ足りない
Atomsの例 CONFIRM タイトルが入ります
Atomsよりさらに細かい粒度 ・AtomsがUIの最小単位として、しかしさらに分解すると、デザイン要素として下記が抽出される ー 色 ー フォントファミリー ー アイコン ーー アイコンをAtomsとすると、アイコンを含む単純なボタンすらMoleculesとなるので都合が悪い
・Atomsを「独立した意味のあるUIの最小単位」とすると、下記もAtoms以下の単位となる ー 本文の標準フォントサイズ ー (注釈のフォントサイズ)
ファイル構成(Nucleusは半田が勝手に命名) Atoms.xd Nucleus.xd Molecules.xd Organisms.xd Templates.xd
あとはどんどん作るだけ (ここからはデモをしながら) https://bit.ly/2IpcgYm
1. 実際にやってみて思う Atomic Design実施のポイント
Atomic Designの考えるUI整理論(再掲) http://atomicdesign.bradfrost.com
じゃあこの順番で作るのか? http://atomicdesign.bradfrost.com
そんなことはない ・ボタンや見出しから作り、それらを組み合わせてUIグループをつくり、それらを組み合わせてページを作 れる人がいたら尊敬します ・私は結局TemplatesまたはPagesから作成します ・そのプロセスの中で作成したUIを、随時AtomsやMoculesなどの他のファイルに登録して、 TemplatesまたはPagesのファイルに再輸入します ・つまり1ページ作るごとに、他のファイルのコンポーネントが少しずつ増えていくイメージ ・ただし見出しやボタンなどのAtoms系はパターンがあるので、タイミングの良いときにバリエーション を一気に作ってしまってもいいかも
その他の細かいはなし ・自分はNucleusで管理するコンポーネントは英語で名前 を付けるようにしています ー そうするとパッと見て区別しやすい ー Nucleusの粒度のものはTemplates/Pagesで直接 使うべきではないので、その防止も含めて ー 将来的にアセットパネルのソートとかもくると思うの
で、それも見越して
その他の細かいはなし ・バリエーションはスラッシュで区切って名前を付けるよ うにしています ー そうするとパッと見て区別しやすい ー 将来的にアセットパネルのソートとかもくると思うの で、それも見越して
その他の細かいはなし ・文字スタイルはフォントファミリーの管理にしか使って いないです ー 意図して大きさも登録してしまうと、それっとつまり Atomsなので、Nucleusで管理するものじゃないなと (つまり大きさとファミリーのセットはAtomsでコンポー ネントとして管理している) ー ただし本文などの標準テキストは例外として、大きさ
と行間もセットにしています ーー 本文をAtomsとして定義できなくもないです が、それってやりすぎかなと
その他の細かいはなし ・ちなみにグリッド表示にすると、文字スタイルがプレビ ューされます。便利。
その他の細かいはなし ・とりあえず1回しか使っていないコンポーネントは、 MoleculesまたはOrganismsとして定義しないこともあ ります ー 特にOrganisms。例えばこのレイアウトなど ー 厳密にやろうとし過ぎると、デザインという本質的な ところ以外で時間を取られてしまうので、ある程度の雑さ は必要です
ー ただし再度似たようなコンポーネントを作りそうであ れば、きちんと定義して整理すべき
その他の細かいはなし ・このページもそう ー フォームなど、ページごとに項目が変わることがほと んどなので、Moleculesの繰り返しであり、いちいち Organismsにはしていないです
2. コンポーネントを操るうえで 使いこなすべきXDの機能
基本のショートカット ・Cmd + Y ー レイヤー表示/非表示 ・Cmd + Shift +
Y ー アセットの表示/非表示 ・Cmd + Shift + K ー マスターコンポーネントを編集 ーー 別ファイルでも大丈夫! (アクション名が変わるらしい)
基本のショートカット ・Cmd + Y ー レイヤー表示/非表示 ・Cmd + Shift +
Y ー アセットの表示/非表示 ・Cmd + Shift + K ー マスターコンポーネントを編集 ーー 別ファイルでも大丈夫! (アクション名が変わるらしい)
基本のショートカット ・Cmd + Y ー レイヤー表示/非表示 ・Cmd + Shift +
Y ー アセットの表示/非表示 ・Cmd + Shift + K ー マスターコンポーネントを編集 ーー 別ファイルでも大丈夫! (アクション名が変わるらしい)
コンポーネントのフィルタリング ・とにかくこれは便利なので、駆使しない手はない ・クラウドドライブでファイルを分けているのも、半分こ れが理由です
コンポーネントのテキストはエリア内テキストがオススメ ・ポイントテキストだと、横幅を変えると拡大縮小してし まう ・エリア内テキストだと、文字が下に流れるため、つまり HTMLの挙動と同じように
複数の要素を一斉にインスタンスに差し替える ・コンポーネント/インスタンスに他のコンポーネントをド ロップすると、差し替えることができます ・マスターコンポーネントに他のコンポーネントをドロッ プすると、インスタンスが全て差し替わります ・そのため、とりあえずTemplates/Pages内で一時的に コンポーネント/インスタンス化しておくと、後で他のファ イルから再輸入するときの差し替えがかなり楽に
同じ位置にインスタンスを配置したい場合は、コピペで ・例えばヘッダーなど、常に同じ位置にあって欲しいインスタンスの場合 ー アセットパネルからのドロップではなく、他アートボードからコピペで ー そうすると、全く同じ位置に配置してくれます(コンポーネント/インスタンスに限らず)
Atomic Designの真価について
Atomic Designの真価について ・実際に実装を行う、エンジニアとの共通言語となる ・UIがロジカルに整理される この2点だと考えています。
しかし共通言語とは しかしながら共通言語とは言っても、実際にAtomic Designで定義した ・Nucleus ・Atoms ・Molecules ・Organisms ・Templates の粒度が、そのままコード設計・実装の粒度になることはまずありません。 それをやろうと思うと、デザイナーとエンジニア間でかなり密なコミュニケーションが必要になり、結局そ
れでもどちらかに必ず負担がかかります。無理に完全一致させようとするものではない。
結局Atomic Designの役割とは 優秀なエンジニアであればあるほど、Atomic Designなどなくても、デザインカンプからコンポーネント の依存関係を読み解き、コードとしてきちんと整理することができます。 そのためAtomic Designの担う役割としては、デザイナーとエンジニアで認識を完全一致させるのではな く、あくまで架け橋になればよい、程度に捉えた方がよいでしょう。 それなりに整理されているだけでエンジニアとしては大助かりなので、無理に一致させようとせず、「デザ インをする上での思考整理」を主目的とするのが、1番無理のない実施方針だと考えています。
それと、整理することはデザインの本質ではないので、目的を見失わないように。
まとめ
何も整理しないよりは、 絶対整理した方がいい!
2019年5月アップデートで、 XDでのデザインシステム構築がかなり 現実的になってきた!
いきなり大規模案件でやってみても 絶対破綻するので、 小規模からでも始めよう!
Thank YOU ;) assialiholic atsushi.handa.3