デザインしやすい部品の分け方を考える

Atomic Design の課題

デザインシステムを作っていく際、Atomic Design は非常に参考になる考え方です。Atomic Design は以下の 5 つの要素によって構成されていて、Pages へ近づくほど、より複雑で大きなものになります。

1. Atom : UI を構成する最小かつ基礎要素。ラベルやボタンなどが含まれる。
2. Molecules : 2 つ以上の Atom によって構成された小さなグループ。ラベル、インプット、ボタンで構成された検索フィールドはその一例。
3. Organisms : 2 つ以上の Molecules もしくは Atoms によって構成されており、画面上で独自の枠組みになっていることが多い。
4. Templates : コンテンツ構造が分かる大きな枠組みで、利用文脈によって分類できるレイアウトになっている。
5. Pages : テンプレートが実際どのように扱われているか、Atoms から構成された部品が効果的に使われているか分かるもの。

Atomic Design は参考になるところが多々あるものの、デザインシステムを作るときに Atoms – Molecules – Organisms – Templates – Pages の考え方をそのまま採用するのが辛い場合があります。そもそも「Molecules」という単語が日本人には馴染みがないですし、人によって Molecules、Organisms, Templates, Pages の分け方が曖昧な場合があります。

Atomic Design で用いられているラベルは Atomic Design の概念を広める上で最適化されているものと考えています。よって、自分たちで似たような概念を取り入れる際、チームで理解できる言葉や分け方へ変換するべきでしょう。

また、 Sketch でシンボル管理をする際、Atom から Template くらいまですべてをシンボルにする必要はありません。例えば iOS の Tab Bars を Organisms としてシンボルにすることも可能ですし、アイテムの順序の変更や数を増減させることも難しいことではありません。ただ、シンボルで管理しないほうが、デザインの模索がしやすい場合もあります。

Overrides できる要素がたくさん用意されている Tab Bars のシンボルですが、アイテムの数を変えたい時に少し不便です。

確実に崩れない、変わりないものであればシンボルにしていったほうが良いですが、Organisms, Template, Pages くらい大きな単位は、デザイナーが自由に考えることができる余裕をもたせるべきだと考えています。シンボルのルールを変えてから画面のデザインを考えるという行為は、模索というクリエイティブプロセスにおいて少々足かせになります。 Organisms はシンボルにしなくて良いという意味ではなく、今求められているデザインがしやすい分け方を考える必要があるわけです。

デザインしやすい分類を考える

Atomic Design のように小さな部品から徐々に大きなものを作るという考え方は採用するべきですが、言葉まで同じにすることはありませんし、同じように 5 段階に分けることもありません。以下のような質問は、プロジェクトに合うデザインシステムを考える上で重要になります。

• 制作しているアプリ・サイトに適した分類は？
• 分類のラベルは何が適当か？
• 制作フェイズで必要とされる柔軟性・汎用性は？

「デザイナーがデザインシステムに参加するための課題と対策」でも指摘しましたが、デザイナーが日々使うデザインツールでも、デザインシステムを意識できるようにしなければ、使えるシステムとして成熟しません。そこで、 Atomic Design の考え方と制作のしやすさを考慮してシンボルの分類を以下の 4 つにしました。まだ製品がリリースされていない設計段階であれば、これくらいで十分だと思います。

1. Colors : カラーパレット。Sketch には Document Colors と呼ばれるカラーパレットを保存できる場所がありますが、シンボル化することでアイコンやボタンの色をシンボルの Overrides で上書きできるようになります。
2. Icons : アイコン集。上記したシンボル化した色を追加しておくことで、自由にアイコンの色を変えることができます。
3. Parts : Atomic Design の Atoms と近い役割ですが、UI 要素を後で Overrides したいものを Parts として切り出しています。例えばボタンのデザインでも色を反転させる場合があるので、テキストも Parts として扱い、あとで Overrides できるようにします。
4. Components : これは Module? Component? それとも Template? という混乱を避けるために、アプリの構成要素をすべて Components と呼ぶことにしました。

決めたラベルをそのままシンボルの分類に用います。

作られたシンボルは必ずいずれかに該当するように整理しておけば、何があるのか明確ですし、文書化するときも比較的楽になります。ただ、どのように Components をまとめあげるかは今でも試行錯誤です。あまりカッチリと Component という塊を作ってしまうと、デザインする際の柔軟性を失われてしまうこともありますし、だからといって小さなシンボルを貼り付けてばかりいるだけだと後々管理が大変になります。ここに関してはアプリ・Web サイトの成熟度で調整するしかないかなと思っています。

まとめ

デザインがだいたい決まって、基本構造は今後あまり変わらないというのであれば、厳格な分類をしても良いと思いますし、Atomic Design をそのまま継承するのもひとつの手段です。まだ変わる可能性がある、運用次第で大きく変わる可能性がある場合は注意が必要です。ただ、初期段階から デザインシステム の基本的な考え方を意識してもらうためには、小さな単位だけでも『部品化』を初めると良いでしょう。決まり事を作りつつも、デザイナーが自由に模索できる余地を設けるというバランス作りがデザインシステム啓蒙の前進にも繋がると思います。