Atomic DesignからみたBootstrap

はじめまして。UIデザイナーの@nikoko45です。

最近Webサービスのデザインガイドラインを作っていて、特にコンポーネントをどうまとめたら良いのか模索中です。ユーザーには一貫したUIや世界観を提供でき、開発者にはもっと効率的に作業スピードをあげられる方法はないか考えてみました。

デザインガイドラインで目指したいこと

一貫性のあるデザインを維持するために、デザインファイルのテンプレート作成、コミュニケーションやレビューのコストを少しでも減らすことがゴールなのかなと思っています。（参考：一貫したデザインのためにデザインシステムを運用する方法）

色々記事を読み漁った結果、どうやらデザインガイドラインとしてコンポーネントを整理するにはAtomic Designが役立ちそうということで調べてみました。

Atomic Design

Atomic Designとは

インターフェースに含まれる要素を、Atoms（原子）・Molecules（分子）・Organisms（有機体）・Templates（テンプレート）・Pages（ページ）に分けて考えるデザイン手法です。

（引用：Atomic Design Methodology）

Atomic Designを活用するメリット

1. サービスとして一貫性のあるデザインのクオリティを担保できる

どのページでも一定のルールが確立されたUIが適用することができます。ユーザーの学習コストが減るため、コンバージョンの向上などの相乗効果が期待できそう。

2. デザイン変更に対応しやすい

今回ガイドラインを作っているプロジェクトとは別件なのですが、Sketchテンプレート＆共通Symbolでエンハンス開発をやって、作業スピードがかなり改善できたこと実感したことあるので納得。

3. コンポーネントの名称をうまく定義すれば、開発者間のコミュニケーションコストが軽減できる

・エンジニア：CSSのクラス/スタイル定義にあわせると、共通言語になる（参考：Mirrored atomicity: designers and developers speaking the same language）

・デザイナー：Sketch作成のルールになり、複数人で1つのファイルを編集しやすくなる（大規模開発や長期運用になると結構大事！）

（参考：「Atomic DesignとSketch Symbol」をお話させて頂きました）

命名規則

Atomic Designをサービス運用に取り込んでいく上で、コンポーネントの命名規則はかなり重要になってきます。エンジニアにクラス名を言えば、どんなUIを実装して欲しいかが伝わるコミュニケーションが成立するのが理想です。

今回デザインガイドラインを作る対象は、Bootstrapを使っているWebサイトなので、Bootstrapに寄せた命名規則を導入できそうか試してみました。

Bootstrap

Bootstrapとは

レスポンシブデザインに対応したフロントエンドのフレームワークです。ソースを一元管理できるため、実装＆メンテナンスコストが抑えやすいです。一方レイアウトは制約されるので、デザインの自由度は若干下がります。

Bootstrapにあるコンポーネント

公式ドキュメント（Bootstrap 4）

（引用：Free Bootstrap 4 GUI Template）

公式ドキュメントで存在するもの、Conducting an interface inventoryを参考にしたもの、今回サービス上で必要そうなものを加えて、勝手にグループ分けしてみました。おそらくプロジェクトや立場によって解釈は異なるとは思いますが、かなり間違ってたり、漏れてるものがあれば教えてもらえると嬉しいです…🙏

Atomic Design観点で超ざっくり分類すると以下のようになると考えてます。ちなみにここにはない"Colors"や"Typography"は、Atomsになるかと。

・Atoms（原子）： Buttons, Badges, Figures, Icons

・Molecules（分子）：Forms, Navigation, Messaging, Image Types

・Organisms（有機体）：Sections, 3rd Party, Global

（参考：Atomic Design Template by Nolte Sketch Resource、Atomic Design を分かったつもりになる）

Sketch化する

Bootstrap 4 UI Kit for Sketchから拝借したファイルをいじってみました。

実際に手を動かしていて、理論通り綺麗にコンポーネントを分類することよりも、SketchでSymbol化したときに、いかにUIが作りやすいか＆変更しやすいようにしておくかが大事なのかなと感じました。

これにプロダクトにあわせたカラーやサイズとかも調整すれば、デザインガイドラインとして使い物になりそうな気がしてきました。Symbolのネーミングは他デザイナーやエンジニアと確認しながら進めた方が良さそうです。

デザインプロセス

もしSketchテンプレートができて、プロジェクトで実用するとしたら、最近の私だとこんな感じで進めるのが多そうだなと想像してます。

ここらへんはツールの進化で変わるかもしれないし、メンバーやタスクによって柔軟に対応できればいいかな。

まとめ

今回のブログを通して、自分以外のデザイナーが作業しやすいSketchファイル、エンジニアに伝わりやすい情報共有について考えてみました。それらを実現するためには、デザインガイドラインを、いつどこで誰が見ても理解しやすいフォーマットにしておくことが大切だということが分かりました。

Atomic Designは、パーツ起点でUIデザインをするので、適したパズルピースをみつけて組み立てる感覚に近いです。どんな絵を描きたいかはすでに頭の中ではイメージしていて、それに近いものを探し出す感じです。

あとこのブログ書いてる最中に気づいたのですが、Atomic Designを提唱したBrad Frost氏自ら「Atomic Designは今のレスポンシブなデジタルの世界に対応するために開発されたもの」といった発言をしていたので、元々Atomic DesignとBootstrapは相性が良い方だと推測しています。（参考：珍しいワークフロー：Atomic Designの原則とSketchでデザインからプログラミングまで）

あくまでこの記事では、Webサイトのみ考慮しています。iOS/Androidアプリもある場合は、各プラットフォームのガイドラインともうまく折り合いつけながら、「このサービス全体としてのデザインガイドラインはどうしたいのか」についてより一層深く考える必要があるので、難しくなりそう（だからデザインシステムの資料はWeb寄りが多いのかな）

もし今作ってるデザインガイドラインができたら、どこかでアウトプットできたら嬉しいです。焼肉食べたい。それでは！

（追記：当時作成していたデザインガイドラインはこちら）