なぜ Atomic Design の導入がうまくいかないのか、たった 1 つの理由

2020-08-02

Atomic Design を導入しようとしている現場は決して少なくない印象を受けます。

が、その一方で、Atomic Design を効果的に導入できている現場は決して多くない印象です。

なぜ Atomic Design が効果的に働かないのか、その理由はたった 1 つの誤解のせいです。

Atomic Design とはルールであって、導入する以上は守らなければいけないものです。

ルールである以上は、ルールに従ってプロトタイピングを行うことがあるべき姿なのです。

にも関わらず、なぜかプロトタイピングを行った状態で、そこに Atomic Design を当てはめようとする現場がほとんどです。

つまり、順序が逆というか、考え方が逆なんですよね。

ルールは遵守するものであり、ルールに沿えない場合は、仕様を変更するのが正しいフローです。

そのため、Atomic Design は決して銀の弾丸にはなりえません。

ルールに遵守してプロトタイピングが行えず、仕様も変更できないケースでは、そのルールを適用することが厳しいわけで。

つまり、そのプロジェクトには Atomic Design が合っていない、という結論に至るはずです。

で、こういう書き方をすると『つまりうちの現場で Atomic Design がうまく働かなかったのは、Atomic Design がよくなかったからなんだな』と勘違いする人が出てきそうですが。

Atomic Design の公式サンプルを見ればわかると思いますが、比較的シンプルな、サッパリとしたデザイニングが行いやすい思想であることはなんとなくわかると思います。

それもそのはずで、Atomic Design における UI 側のネストは多くても 4 つか 5 つくらいで済むため、そもそも複雑なデザイニングが行えないように定めてあります。

従って、例えば props のバケツリレーが発生する場合も、どんなに多くても 4 つか 5 つくらいで済むわけです。

これを多いと感じるか少ないと感じるかは人それぞれだとは思いますが、これくらいで堅牢なプロジェクトが組めるのであれば、全然大したことないよなーと。

で、これが Atomic Design の良さであり、思想なわけです。

そもそも、複雑なデザイニング、例えば、1 画面に様々なデータを表示するようなデザイニングを行った場合、それに紐付いて Page Components (つまり Container Components) が膨れていくのは目に見えています。

そこにひも付き、Atomic Design で対応できないようなコンポーネント設計を行う必要が出てくる場合、果たして本当に保守性の高いプロジェクトが組みきれるのか。

そして、そんな画面を本当にユーザーが求めているのか、果たして疑問ではあります。

最近書いた、タブもそうですし、モーダルもそうです、果たしてそれは本当に必要なデザイニングなのか。

なんとなくで組んでいませんか?確固たる理由がそこにあるのですが?エビデンスは持ち合わせていますか?

ユーザーファーストの元にプロトタイピングを組むことが Web デザイナーの使命であり、永遠の課題でもあります。

日本では Web デザインを異常なほど軽視しているため、いつまで経ってもまともな UX が高まっていません。

Web デザインを軽視し続ける限り、おそらく Atomic Design の有用性には気づけないですし、携わるプロジェクトに Atomic Design を適用すべきか否か判断することなど不可能です。

ということで、Atomic Design の仕様に文句を垂れるくらいなら、一度 Atomic Design にべったり沿ってプロトタイピングくらいしてほしいなーと思う、今日このごろです。

© 2018 kk-web