LoginSignup
60
50

More than 3 years have passed since last update.

[LTスライド&原稿]実装まで視野に入れるならAtomic Designを辞めましょう

Last updated at Posted at 2020-10-03

この記事は2020年10月3日にWCAN 2020 Design Special 〜デザイン力の基本とブランドづくりの一歩〜で行うLTのスライドと原稿です。

投稿時点ではまだイベントは始まっていませんが、先んじて公開します。
以下が実際の内容です。

Frame 1.jpg

それでは「実装まで視野に入れるならAtomic Designを辞めましょう」と題して私のLTを始めます。

Frame 2.jpg

みなさんこんにちは。Increments株式会社でデザイナーをしている綿貫佳祐と言います。

Frame 3.jpg

Incremetnsではこれらのサービスを展開しております。

普段の業務からこれら3つ、インターフェースだけでなくフロントエンドまである程度担当していまして、両方の視点から見た話をしていきます。

Frame 4.jpg

最初にお断りしておきますと、現在Atomic Designを使っている方々を否定するつもりはありません。

Frame 5.jpg

ただ、主観ですがAtomic Designは「汎用的なデザイン制作の概念」「コンポーネント設計のベストプラクティス」として浸透し過ぎている気がします。

何においても、唯一絶対のものが存在しているよりいくつか流派が存在している方が健全だと思うんですよね。

Frame 6.jpg

そして自分は疑問を持ったので世間に投げかけるポジションをやってみよう、とLTをしている次第です。

Frame 7.jpg

まずは自分のこれまでの経験から、Atomic Designが向いているケースと向いていないケースについて話します。

Frame 8.jpg

向いているのはこんなケースではないでしょうか。

職種でチームが分かれているとか、モックアップ作成がゴール。

イメージとしては、Atomic Designを扱うのがデザイナーだけな場合です。

Frame 9.jpg

逆に、向いていないのはこういうケース。

同じチームにデザイナーエンジニアがいる。あるいはそもそもあまり役割に境界がない。

LTタイトル通りですが、Atomic Designをコードの世界に持ち込むのが向いていない……という話です。

Frame 10.jpg

ではなぜ向いている / いないが生まれるのか?

Frame 11.jpg

この3つを主な理由として挙げます。

Frame 12.jpg

1つ目のコンポーネントの分け方に迷うという話……

Frame 13.jpg

これはみなさんある程度経験していらっしゃいますよね?

Frame 14.jpg

Atomic Designにおいて何か定量的な基準があるわけではなく、チームごとに「我々はこういう基準でコンポーネントを分ける」という慣習法を持っているに過ぎないのです。

ですから人数が多くなると意思の統一が難しくなりますし、職種によって視点がどうしても違います。

Frame 16.jpg

次は、Atomic Designはコード的な概念を含んでいないというそもそもの話です。

あまり知られてないのですがAtomic Designはコードとしての在り方には言及していません。

Frame 17.jpg

そのためディレクトリ構造やデータの受け渡しに適用すると不整合が起きがちですし、Design TokenやUtilityをどう持つべきかを考え始めると必然的にオレオレAtomic Designになります。

Frame 18.jpg

最後に、Atomic DesignでいうPageの概念ってコーディングの際にはほとんど存在していないんですよね。

Frame 19.jpg

ここでいうPageとはTemplateに実データを流し込んだ結果みたいなイメージ、ニアリーイコールでレンダリング結果です。

UIモックアップは大抵レンダリング結果の設計図とか予想図みたいな役割なので、Pageの概念は役立つんですが、コードで書く内容ってAtomic DesignにおいてはTemplateに近いです。

Frame 20.jpg

ではどうなるかというとやはりコードでは不整合が起きてPageが形骸化する。

5レイヤーしか無い概念のうち1つが形骸化を余儀なくされるんです。

Frame 21.jpg

ここまで色々話してきましたが、悪い点の指摘だけなら誰でもできるので、代替案として私のオススメを紹介します。

Frame 22.jpg

まずはコンポーネントをサイズ感によって分類しないこと。なんだったら分類を全て取り払っても良いと思います。Material Designはそんな感じですしね。

もし分類するとしてもコンポーネントの種類ごとです。ナビゲーションとかデータ入力とか。ちなみにこれはAnt Designでの考え方です。

Frame 23.jpg

あとはデザインモックアップの作り方として、同一Componentであっても渡されるデータの有無やStateに合わせて作るのは大事だと思います。

AtomからMolecule、MoleculeからOrganismとレイヤーで考えるのではなくてあくまでコード上での振る舞いを重視するのです。

Frame 24.jpg

何故かというと、Atomを探そうとかMoleculeを探そうっていう思考よりも、ボタンを探そうっていう思考の方が自然だからです。そしてSketchやFigmaのライブラリ機能を上手く使えば粒度や階層もAtomic Designに無理やり当てはめるよりよっぽど柔軟です。

そしてモックアップにAtomic Designを適用しないなら、コードに適用するメリットもあまりありません。シンプルにシステム開発におけるベストプラクティスに沿っていけばOK。という具合です。

私のLTは以上です。ご清聴ありがとうございました。

60
50
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
60
50