Atomic Design の理解 : molecules と organisms をどのように分割するか

Making sense of atomic design: molecules and organisms

translated on

我々のインタラクションデザイナーである Alla Kholmatova が FutureLearn での Atomic Design の利用の状況について考察します。

1年前、私たちは FutureLearn での最初のパターンライブラリ開発について、そしてなぜ我々が Atomic Design を使うことになったのかについて著しました。
全般的に、Atomic Design は我々のチーム内でうまく機能しています。それはインターフェイスの理解の共有や、さらなるモジュール化への移行、我々のデザイン言語の進化などに貢献しました。

Atomic Design におけるいくつかのコンセプトについては最初から明確でしたが、その他はあいまいに感じていました。例えば、我々の理解がまだ不十分な分野は、molecules と organisms の違いについてです。

molecules と organisms

Brad Frost は、molecules を「複数の atoms が一緒になり最小限の機能を構成するグループ」として、organisms を「ほかと比べて複雑で、インターフェイス上明確な区分を形成するために複数の molecules が集まったグループ」と定義しています。

これらの定義は、理論上は単純に聞こえるかもしれませんが、molecules が organisms になるのにとても複雑な場合や、molecules と organisms の違い、そもそも双方のタイプがなぜ必要なのかなど、正確に理解するのに苦労しています。(organisms と molecules の CSS の部分はとても良く似ています。 それは単に大きいもしくは小さい molecules とする方が簡単なのではないでしょうか?)

なぜ molecules と organisms があるのか?

我々は、molecules と organisms 分けることについて、3つの利点があると考えました。

  1. フロントエンドの観点からは、organisms は HTML を分割するのに有効なやりかたである(molecules ではそれをおこなうにはおそらく単純すぎるだろう)。
  2. デザインの観点からは、それはデザインの理解と、何から構成されているかを理解するのに役立ちます。また、デザイン時において正しい要素をより早く見つけるのに役立ちます(例えば、「ここにこのコンテントを共有させるための要素が必要なんです、えーと、これを見て欲しいのですが、、」)。
  3. パターンライブラリの観点からは、要素を整理し見つけ易くするのに役立ちます(少なくとも我々が使っていたひとつの長いリストよりは簡単です)

解決しようとしていた問題

しかしながら、どのように分割すればよいかという共通理解がチーム内にありませんでした。
それは視覚的なプレゼンテーションについてなのか -例えばサイズなのか視覚的な複雑さなのか? 複雑さなのかコンテンツの重要性なのか? 機能についてなのか? コンテンツが機能を変更したらどうなるのか? そして機能が相対的で、ある要素が出現するコンテキストに依存してたら?

結果として、何が molecules で何が organisms なのかを論争するのに長い時間をかけてしまいました。
討論は常に生産的である訳は無く、我々はそれを続ける余裕はありませんでした。
そこで、どうすれば要素を分類分けするのにより効率的になれるかを確認するため、我々はデザイナーやフロントエンドの開発者とのワークショップを開くことを決めました。

ワークショップ

いつものように、我々はインターフェイスの要素を紙上に書き出しました(上の画面参照)。
我々は小さいチームに分かれ、それぞれのグループに、インターフェイスの要素をすでに整理したパターンライブラリよりも分かりやすい形で分類するよう(カードの分類のように)依頼しました。狙いは、皆がどんなグループ分けをするのか確認することでした。

ワークショプの結果

ワークショップの結果は、要領を得ないものでした。チームは様々な方法でモジュールを分類し、最終的には異なったグルーピングになってしまいました。

しかし、そこには二つの明らかなタイプがありました。我々が気付いたのは、いくつかのモジュールはそれら自身にも使われる一方、他のモジュールは、他のモジュールの一部としてのみ動作するということです。例えば、これらの二つのコンポーネントは機能的にもプレゼンテーションのレベルでも全く異なります:

最初のグループ(最上位のコンポーネントに相当する)要素は補助的な機能以上のものを持っています。それを「helpers」と呼びましょう。2番目の要素はより独立しているので「standalone」と呼ぶことにします。

Helpers

helpers はそれ自身では意味を成しません。ここには、このグループの典型的な例が、いくつかあります。我々のインターフェイスの中では、molecules が典型的なヘルパーです。

Standalones

standalone の要素はそれ自身の中で「生き残り」ます。 すなわち、それは自分自身の独立したコンテンツと機能の構成として参照されます。FutureLearn における standalone のモジュールの典型的な例ですが:

[https://ugc-about.futurelearn.com/wp-content/uploads/04_small.jpg:image=https://ugc-about.futurelearn.com/wp-content/uploads/04_small.jpg]

我々のインターフェイスでは、organisms は典型的な standalone です。

ここまでは理解できます。molecules は主に他のインターフェイスの要素をサポートします。organisms は主に自己完結型で、自分自身に依存しています。

Helper か Standalone か?

しかしながら、多くの要素がその中間の何処かに存在します。中間に落ちたものは、主にふたつの要因(コンテンツと文脈)により、理論的にはどちらかのグループに属します。コンテンツと文脈はもちろん変化する対象で、それらの要素を分類するのを難しくしています。ここにそんなモジュールの典型的な例があります:

見かけ上は organisms のように見えます(かなり複雑な要素で多くのコンテンツを含んでいます)。しかし、自己完結していません。シェアボタンを押すと何が共有されるのか、「このコースは2日後に始まります(The course will start in 2 days)」とありますが、どのコースが2日後にはじまるのか、明確ではありません。

でも、我々がコンテンツを変更し、より意味のあるタイトルをつけ、コースのタイトルを参照したと想像してください。突然、このモジュールは自立できるようになります。

我々のインターフェイスはこのような要素にあふれています。こちらがその例です。

教訓

Atomic Design に取り組んで一年たっても、インターフェイスの要素をどのように分類するかについてチーム内で未だに明快に理解が共有されていません。でも多分それでオーケーです。物事を分類し整理する「正しい」方法が常にあるとは限りません。

我々が学んだことのひとつは、モジュールがどのグループに属するかを決めるに当たっては、より柔軟であるべきということです。討論でチーム全体を巻き込むよりは、新しいモジュールを導入するデザイナーや開発者が、molecules もしくは organisms のどちらになるのか最終的に決めるべきです。残りのメンバーは、強くそして事実に基づいた異議がなければ、その決定を受け入れるべきです。

要素の複雑さを考えるとき、それは molecules を helper として、また organisms を standalone のモジュールとして見なすことを助けます。もしある要素がどちらかのグループに明確に当てはまらないなら、これらの質問が役に立つでしょう:

  • これは補助的な要素か、それとも自立した要素か?
  • それは通常他のモジュールの一部になっていて、様々なコンポーネントの中で再利用されるか?(これはおそらく molecules)
  • それは明確に定義され、他と比べて独立したセクションになっているか?(これはおそらく organisms)

もしあなたが Atomic Design に取り組むなら、ぜひあなたの考えを聞かせてください。モジュールを organisms から molecules に分離することに価値があると思いますか? もしそうなら、どうやってその二つを区別しますか? 下のコメント欄に書き込んでください。 興味のある方は FutureLearn でのデザインの役割まで。