embryo

エンジニアの備忘録

AtomicDesignが解決してくれないこと

デザイン UI設計 DLS

今日はAtomicDesignについてです。

概要

弊社のとあるチームでAtomicDesignの導入を試みていたのですがあまり上手くいっていないようでした。そこでなぜ上手く行っていなかったのか考えて整理したので、その内容をまとめました。

AtomicDesignとは

Design Language System (DLS) を作る上でのパターンの一つです。詳しくは下記を参照してください。

atomic design

大まかに説明するとデザインパーツの粒度を定義し、それらの組み合わせでデザインパーツを構成していこうというものです。 粒度は下記のように定義されています。

Organisms > Molecules > Atoms

フロントエンド界隈には大分普及してきたようで最近では活用事例を耳にする機会も多くなりました。

AtomicDesignのメリット

まずはAtomicDesignのメリットについてですが以下の2点がよく挙げられています。

共通言語が作られる

粒度を共通言語として定義することにより、開発者間でのコミュニケーションが円滑に進みます。

分解粒度が属人化しづらい

再利用性の高いUIコンポーネントを作っていく際、どうしても開発者のセンスによるところが大きかったように思えますが、とにかく細かく分解して足し合わせるというメソッドなので属人化しにくいのもメリットの一つと言えるでしょう。

※ しづらい、としたのは限られた階層しか無い以上必ず属人化はするからです。

AtomicDesignで起こりがちな問題

AtomicDesignを採用する時によく起きている問題をまとめました。

分解されている == 良いUIコンポーネントではない

Atomic Designの粒度に分解して配置することを目的にしてしまい、1度しか使わないUIコンポーネントが量産されるケースを現場でよく見かけます。目的は再利用することなので、分解していく過程でどこが再利用出来るかを考えるべきです。

グループ化やパターン化は解決してくれない

良いUIコンポーネントを作るためには適切なグループ化とパターン化が必要です。例えばボタンの場合は下記のようなグループ化、パターン化を行うことで再利用性が高まりますが、AtomicDesignをただ実践するだけではそうはなりません。

Group Pattern
TextButton type, size
IconButton type, size, icon

ユーザビリティが良くなるわけではない

UIコンポーネントの分解粒度が最適化されることがユーザーにとって嬉しいわけではありません。あるUIコンポーネントのルールがアプリケーション内で一貫していることで初めてユーザーにとって嬉しいものになります。

そもそも良いUIコンポーネントとは

AtomicDesignをきっかけにDLSを作り始める事自体は良いことです。ただAtomicDesignを実践する前に良いUIコンポーネントとはどういうものなのかを整理し、チェックすると良いかと思います。

再利用性が高いこと

主に開発効率化のためになりますが、UIコンポーネントに関して言えば最も重要な要素です。新たにページや機能を制作する際に、今まで分解したパーツを使用できないか、またそれらをどのようにグループ化されていれば矛盾なくパーツにはめ込めるのかを考えましょう。

最終的には下記のように文字で指示書が書けるのが理想です。

f:id:sue71:20180502232454p:plain

ルールと拡張性のバランス

そのUIパーツが本質的にどういう性質なのかを考えましょう。画面だけ見ていると見えていない性質が見えてくるはずです。 例えば下記のようなナビゲーションバーが提供されている場合

f:id:sue71:20180502231513p:plain

- 左部はページの遷移をコントロールするものである
- 中央はページを説明するものである
- 右部はページに対するアクションを提供するものである

というルールが考えられます。

ある程度ルールが定まっているとその拡張性の方向も限られてくるため実装も最適化されます。 ルールが定まっていない場合そのUIパーツ内で拡張性の方向が定まらないため、パターン化がしづらくなります。これが1度しか使われないコンポーネントが量産されること、もしくはUIコンポーネントの分岐が多くなる原因になります。

また、必ずしも汎用的なルールに落とし込めないことに注意してください。時には似ている形でも全く別の欲求によってデザインされている場合があります。 こういった場合は無理にパターンに当てはめるのではなく、特殊なケースとして考えるのが良いかと思います。

ちなみに自分はどうしているか

基本的には汎用的なUIコンポーネントと、より詳細度の高いUIコンポーネントの2つを定義しています。(名前は適当です

またユーザービリティを意識した場合、必ずしも汎用性の高いパーツのみで完結するとは限らないため、各ページ内でしか使用しないものも定義することを許容していますが、依存を分かりやすくするためにページのディレクトリ配下に置くようにしています。

詳しくは別の記事でまとめたいと思いますがOOUI(UX)などが近い考え方になると思います。

まとめ

AtomicDesignの実践時によく見かける課題について説明しました。

「設計とはフレームワークではなく良いコードを書こうとする意思である」という言葉も記憶に新しいですが、DLSやUIコンポーネント設計にも同じことが言えます。

手法に名前をつけることは大変意義があることであるのには間違いは無いのですが、ベストプラクティスを考えることが最も重要です。つまり、あるパターンを実践するのを目的とするのではなく、良いUIコンポーネントを作ることを目的としましょうということです。