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
assialiholic
June 22, 2019
Design
6
4.1k
Adobe XDで始めるAtomic Design
2019/6/22 のAdobe XD ユーザーフェス 2019 (札幌) で発表したスライドです。
assialiholic
June 22, 2019
Tweet
Share
More Decks by assialiholic
See All by assialiholic
人生最強のコアスキル a.k.a 開発業務から日常にまで使える最強のスキルについて
assialiholic
0
750
地方都市でもできる! 最新ツールと泥臭さのブランディング
assialiholic
0
500
5年先も第一線で戦えるwebディレクターであるために
assialiholic
3
760
JBUG (札幌#3) LT「大事なことはコメントだけに書くなぁ!」
assialiholic
1
1k
ディレクション資料をXD化してわかった、XDのメリットと課題
assialiholic
2
550
デザイナーとコーダの溝を埋める、テクニカルディレクションにおけるXDの活用事例
assialiholic
3
740
Developer meetup for beginners 「札幌ITひよこ会」 webのミライ、web屋のミライ
assialiholic
0
350
webマーケティング手段のいままでとこれから〜ボストン直輸入の新鮮ピッチピチネタをお届けします〜
assialiholic
1
530
最近よく聞くマーケティングオートメーションって?なにがいいの?
assialiholic
1
470
Other Decks in Design
See All in Design
デザインシステム×プロトタイピングで挑む社会的価値の共創 / Designship2024
visional_engineering_and_design
1
330
コンセプトで経営・事業・組織を動かす、 Ameba20周年ブランディング / ameba-20th-branding
cyberagentdevelopers
PRO
1
550
12年続くB2DサービスとUXデザイン / UX Design keeps B2D service alive over 12 years
tnj
0
280
利用者が離れないUX/UIデザイン 長く使われる業務アプリデザインのポイント
ncdc
5
430
How to go from research data to insights?
mastervicedesign
0
220
共通言語としてのデザイントークンと Figmaでの運用
kamy0042
0
230
志ある事業の種を社会に開花させるための挑戦/ Designship2024_Nishimura
root_recruit
0
260
Designship2024 Panel Discussion インハウスデザイナーは 何をデザインしているか、するべきか で使用したスライドを公開します。
kiyoshifuwa
0
2.4k
ZKK_001.pdf
nicholaspegu
0
1.5k
ゲーム開発における、Figma活用事例の紹介 / applibot-figma
cyberagentdevelopers
PRO
2
620
株式会社デイトラ様│コーポレートサイト│コンセプトシート
haruka_capeo
0
320
[Designship2024] デザインの力でサービスの価値を追求していたら、組織全体をデザインしていた話
okakasoysauce
2
1.1k
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Practical Orchestrator
shlominoach
186
10k
Mobile First: as difficult as doing things right
swwweet
223
9.3k
The Cult of Friendly URLs
andyhume
78
6.2k
Scaling GitHub
holman
459
140k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Visualization
eitanlees
146
15k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
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