Atomic Designでデザインファイルを整えました
デザインの無駄をなくしたい...そんなときに役立つのが、Atomic Designという考え方です。
はじめに
こんにちは！グロービスでUI・UXデザインを担当しています、定着チームのニーです。
デザイナーの皆さんは、デザインファイルを実際に実装されているアプリと比べると、実装上はあってもデザインにない画面があったり、実装上色やフォントの適用がデザインと多少違ったりすることがありませんか？
今回の記事では、グロービス学び放題アプリにある実際のコンポーネントをとりあげて、一貫性のないデザインファイルを整理する方法論「Atomic Design」の概念をご紹介します
目次
入社当初、グロービス学び放題アプリ版のデザインファイルにある問題を整理しました
諸々の問題を解決するため、Atomic Designの概念でデザインファイルを整理しようとした理由
Atomic Designでデザインファイルを整理するメリット
アプリを例として、Atomic Designの概念を説明します
終わりに
入社当初、アプリのデザインファイルにある問題を整理しました
私がグロービスへ入社した当初、グロービス学び放題のネイティブアプリにおけるデザインファイルがありましたが、そのまま保守・運用をしていくと、下記のような問題が起こる可能性がありました。
コンポーネント化の不完全（*ここのコンポーネント化は、Figmaのコンポーネント機能が使われていないことだけではなく、コンポーネントがちゃんと整理されていないことも含まれている）
初めに気づいたことが、コンポーネント化されてないものが画面中に存在していることでした。
この現状を解決しない限り、アプリ内にあるコンポーネントを把握しきれないため、新たな画面をデザインする時に、うまく既存のコンポーネントを使い回すことができません。
同じ用途のコンポーネントが重複して作られている
親コンポーネントだけ作られているので、親コンポーネントに含まれている子コンポーネントが独立して作られ、コンポーネントが重複して作られている場合もあります。
それに、子コンポーネントに文字サイズやPaddingなどが微妙に違う場合もあるので、デザイン上の一致性を担保できません。
コンポーネントのグローバル修正を行いたい場合（色、フォントサイズなど）子コンポーネントが独立しているため、一個一個修正しないといけないので、デザイン作業は非常に非効率になってしまいます。
デザイン上のフォントと実装上のフォントが一致していない
グロービス学び放題のウェブサイトに合わせるため、Noto Sansを指定していましたが、実装上はサイズだけ指定しているため、iOSのシステムデフォルトのHiraginoになっています。
殆どのコンポーネントに文字要素がありますが、フォントの行間や高さなど全部異なるため、実装とデザインでフォントに差が生じてしまい、UI文脈のデザイン確認が行えない状態が続いていました。
諸々の問題を解決するため、Atomic Designの概念でデザインファイルを整理しようとした理由
大半のUIデザインプロセスは、画面ごとに全体のバランスを見ながら行なうと思いますが、Atomic Designは真逆であり、小さい単位からデザインし、それらの単位を組み合わせて画面を構成していくという概念です。
上記の解釈は一見、お互いに許容できないように見えますが、UIデザインの違うフェーズだと僕は思います。いくら経験のあるデザイナーだとしても、画面数の多い新規サービスを作り始めた時に、ワイヤフレームや主要画面のモックアップなどサービスの全容を把握するための作業を先にやらずに、いきなりボタンやアアイコンなど小さい単位のコンポーネントから作成すると、サービス全体に対するイメージがしにくくなります。
僕がもし新規サービスをAtomic Designの概念でデザインするなら、どんな機能が必要なのか？どんなコンポーネントが必要なのか？を大体把握できた後に、コンポーネントや画面の作成作業をやっていくと思います。
Atomic Designは、新たなデザインを作るというよりは、煩雑なデザインを整理する手法だと思います。
Atomic Designでデザインファイルを整理するメリット
Atomic Designのメリットは色々ありますが、全てはコンポーネントが使いまわせることで成り立ちます。
コンポーネント・ライブラリの漏れと重複の防止
私が前職で受託案件の会社で働いていた頃、UIモックアップをたくさん作りましたが、Atomic Designでコンポーネントを整理したことがないため、気づいた時に流用できるはずの子コンポーネントを何回も作ったことがあります。Atomic Designでは、子コンポーネントから作るので、親コンポーネント内に新たな要素が必要な時に、「既存の子コンポーネントが使いまわせるか？」「新たな子コンポーネントを作るか？」を常に考えないといけないので、最終的には漏れ・重複のないコンポーネントライブラリーが作成できます。
デザインファイルの一致性の担保
新たな画面を作っても、常に「コンポーネントが使いまわせるか？」を自問し続けると、デザインの一貫性が自然に担保できるようになります。
デザインファイル管理の効率化
影響範囲の大きいグローバルの変更があったとしても、子コンポーネントの組み合わせによって親コンポーネントが構成されているため、親コンポーネントを一個ずつ調整しなくても、影響範囲内の子コンポーネントさえ調整すれば漏れなく一括変更できます。
グロービス学び放題アプリ版を例として、Atomic Designの概念を説明します
Atomは名詞で、化学元素の最初単位「原子」を意味しています。AtomicはAtomの形容詞であり、「原子の」の意味になり、Atomic Designを直訳すると、「原子のデザイン」になります。Atomic Designと呼ばれているのは、その概念が化学から派生するものであり、物質構成の研究に基づいたデザインの方法論だからです。
Atomic Designでは、デザインの要素が五つの階層に分かられて、最初の三階層が化学世界に当てはまりますが、残りの二つはAtomic Designのために定義されたものです。各階層は前の階層の要素の組み合わせにより構成されています。こちらはFigmaでデザインファイルを作成する前提でこの五つの階層の定義を説明します。
Atoms（原子）
Figmaでコンポーネントを作る時、最小の単位であるものは原子と呼ばれています。例をあげますと、ボタンや入力欄やラベルなどこれ以上分解すると、デザイン上に意味がなくなるものが原子とみなします。原子であるボタンをさらに分解すると、一部が色のついている長方形になり、デザイン上単体に作っても意味がないので、ボタンはコンポーネント作成の最小単位となります。
具体の形がなくても、原子とみなすものも他にもあります。例えば、フォントスタイルやカラーシステムなど、サービス全体のルールになるものも原子の階層で定義します。
Molecules（分子）
分子は原子から構成されているものであり、原子のグループです。デザインの要件を満たすため、同じ原子を違う方法で組み合わせることで別々の分子を作り出すことができます。
Organisms（有機体）
有機体は分子と原子の組み合わせで作られたものです。有機体をデザインする時に、サービスの機能やユーザー体験などへの配慮が入ってきます。分子との区別方法は、有機体は画面に機能性の持つパーツであり、違う画面に独立させても機能として成立できるものです。
Templates（テンプレート）
ページの雛形になるものです。一言で説明すると、実際の内容（画面に表示するデータ）を画面に入れる前の状態は、テンプレートだと定義されています。チーム内では、テンプレート階層でデザインレビューを行っていますが、文言がUI上に入れるかどうかの確認は基本毎回しますので、確かめたい文言だけ画面に入れる場合があります。
Pages（ページ）
本番用データをテンプレートに入れると、ページになります。弊チームでは、デザインレビューを行うとき、テンプレートだけでも意思伝達ができるため、シミュレーションが必要なときだけページを作っています。
終わりに
コンポーネントをAtomic Designで整理することは、かなり時間がかかりますが、その後の運用が効率的になることを考えると、お得だと考えています。
コンポーネントの整理は、デザインだけではなく、エンジニアリングにも関わるので、エンジニアさんとのすり合わせをしながら進める必要があります。また、そのままAtomic Designの概念に（完全に）従うより、チームの現状を考えながらルールの調整や設定をしながら進めるべきだと考えています。
この文章には、Atomic Designの提唱者の本を読みつつ、他のネットの記事も色々参考にして、自分の言葉に転換してしまった箇所が結構あるので、元の方法論とズレのある部分もあるかと思います。本当にAtomic Designをしっかり学びたい方は、是非Atomic Design Methodologyの本を読んでみることをお勧めします！
グロービスで一緒に働くデザイナーを募集しています！
グロービスの開発組織では、一緒に働けるデザイナーを探しています！
まずは、カジュアル面談を通して、あなたに合う組織かどうか確かめてみませんか？
https://recruiting-tech-globis.wraptas.site/