Atomic Design
~堅牢で使いやすいUIを効率良く設計する

書籍の概要

この本の概要

「1画面を変更したつもりが,アプリ全体のUIが崩れてしまった」
「理想のデザイン通り実装したのにユーザーが使いにくい」
「コードが複雑に入り組んでいてもはやメンテナンス不能」

こんな課題の数々は,Atomic Designの考え方を使えば解決できます。

本書では,UI設計のこれまでの問題をあぶり出し,設計の本質から,具体的な手順,UIテスト,現場でひっかかりやすいポイントまでを,インターネットテレビ「Abema TV」のUI設計で実践導入した著者が解説。フロントエンドの方にオススメの1冊です。

こんな方におすすめ

  • 良いUIを効率良く設計したいフロントエンド・エンジニア/デザイナー
  • Atomic Designを現場で実践する方法を知りたいエンジニア/デザイナー

著者の一言

UIをより効率良く開発したい

私は長らくWebフロントエンド・エンジニアとして,複数のWebサービスのUI開発に携ってきました。最近の開発では,新しくサービスを作るたびにそのアプリケーションの開発規模は大きくなり,開発するUIの数は増すばかりです。UIの数が増えると,その機能を実装するために書かなければいけないコードが増えます。コードが増えるということは,工数もそれ相応に増えます。しかし,開発に当てられる期間は,競合サービスがどんどん出てくるなか,想定よりもどんどん短くなっています。
また,書くコードが増えれば,バグが生まれやすくなります。どんな場合であってもバグは好ましくありませんが,特にUIのバグは,ユーザーの体験に直接的な影響を与えるため,より慎重に実装しなければいけません。

「ユーザーが使いやすいサービスをより少ない工数で作りたい」

こう私と同じように感じている読者の方は多いのではないでしょうか。

コンポーネント・ベースで,確実で効率が良い開発を実現する

本書は「WebアプリケーションのUI開発を効率的に行いたい」というWebフロントエンド・エンジニアのために書きました。大規模なアプリケーション開発でも不具合を生みにくく一貫性があるUIを作るために,Atomic Designを使ったコンポーネント・ベースでの開発方法を説明しています。
「機能をコンポーネントに分ける」という考え方は,ソフトウェア開発では一般的なものですが,UIについては,きれいにコンポーネントに分けて実践するのは難しいです。なぜなら,UIというものは,画面を通してユーザーが実際に触って感じるものであり,ブランディングされた見た目を伝えるための役割も担うので,人間の感性や感覚に大きく依存する要素を持っているためです。また,デザインやマーケティング的な戦略も含めチーム全体で向き合う要素が強いため,実際の開発では,ほかの職種のチームメンバーとの深いコミュニケーションを必要とします。それもUIのコンポーネント化をより複雑にする要因となっています。
しかし,コンポーネント・ベースでUI開発を進めることには,以下のようなさまざまなメリットがあります。

  • 複雑なUIも確実に組み立てることができる
  • しっかりとコンポーネントごとに分けられたUIの機能は再利用性が高い
  • 多くの画面に対して少ないコードで実装できる
  • 再利用性が高いコンポーネントは,統一された使い勝手をユーザーに提供できる
  • 画面別ではなく機能別に分けられたUI設計が複数人の平行実装を実現し,開発速度がアップ

そして,この開発方法はテストにも大きく力を発揮します。UIは,1度アプリケーションに組み込まれると,アプリケーション全体の状態にUIの状態が依存するため,テストで状態のパターンを網羅することがかなり難しくなります。しかし,コンポーネントに分割されたUIは,さまざまな種類のテスト手法を組み合わせることで,効率良くテストすることが可能です。
本書では,始めにこれまでUI開発の現場を振り返りつつ,コンポーネント・ベースのUI開発の具体的な手順から,テストの方法,現場のUI開発においてエンジニアリング以外で問題になりがちなチームメンバーとのコミュニケーションの問題へのアプローチ方法までを説明しています。

Atomic DesignとReactによる実践

本書では,UIのコンポーネント化を行う道具として,Atomic Designという設計手法とReactというライブラリを取り上げています。Atomic Designは,スケールしやすくメンテナンスしやすいUIの開発を実践できるデザイン手法です。私も2014年にカナダで開催された「Smashing Conference Whistler」のBrad Frost氏によるワークショップでAtomic Designの実践的な手法について学んだ後,「AbemaTV」というインターネットTVサービスの開発でUI設計に採用しています。最近ではUI設計手法としての認知度も確実に上がってきていて,多くの導入事例を耳にするようになりました。また,Reactも最近のモダンなWebアプリケーションのフロントエンド開発では必ず候補に挙がるほど普及しているUI開発用ライブラリです。
Atomic DesignとReact,この2つをUI開発の道具として,掲載するコードもできる限り実践的な内容になるように心掛けました。特定の道具を例として採用してはいますが,もちろんそのUI設計の考え方は,ほかの道具や手法を採用したとしても必ず活きる内容になっています。

より良いユーザー体験を提供するために

私はモノを作る身として,「より良いユーザー体験を提供するアプリケーションが増えてほしい」と思っています。アプリケーションのUIは,ユーザー体験を直接的に大きく影響する存在なので,「UIコンポーネント設計を正しく行うで,そういったアプリケーションを生み出しやすくできる」と確信しています。本書を通して,私の経験が,これからアプリケーション開発に関わる方のUI設計の一助になれば幸いです。

(「はじめに」から)

目次

  • はじめに

第1章 UI設計における現状の問題を振り返る

1-1 アプリケーションのUIに求められる直感性

  • アプリケーションを使う人の変化
  • UIによってユーザーの使いやすさが変わる
  • 直感的なUIの7つの定義

1-2 UI開発の現場1:JavaScriptの進化

  • かつてのJavaScript
  • 大規模アプリケーションにも使える言語へ

1-3 UI開発の現場2:CSSの努力

  • 大規模アプリケーション開発が難しいCSSの弱点
  • オブジェクト指向で捉えるCSS
  • それでも破綻しやすいCSS

1-4 UI開発の現場3:スタイルガイドの普及

  • スタイルガイド・ジェネレーター
  • スタイルガイドがプロダクトからかい離する問題

1-5 UI開発の現場4:デザインカンプ・ファーストなUI開発ワークフロー

1-6 UI開発の現場5:UIフレームワークの普及

  • デザイナーが存在しない現場
  • Twitter Bootstrapの登場

1-7 UI開発の現場6:Single Page Applicationの普及

  • Webフロントエンド・フレームワークの普及
  • 見直されるUXの価値

第2章 コンポーネント・ベースのUI開発

2-1 なぜコンポーネント・ベースで開発するのか

  • 複雑なUIを確実に組み上げる手段

2-2 堅牢なUI開発を実現する

  • コンポーネント単位でテストできる
  • 不具合のリスク・ポイントを減らすことができる
  • メンテナンスがしやすくなる
  • 解決する問題を小さくすることで不具合発生リスクを減らす

2-3 開発作業を効率化する

  • 再利用で実装量を減らす
  • 平行開発で待ち時間を減らす
  • 仕様変更による手戻り作業を最小化する
  • 新規参入開発メンバーを最短で戦力化する
  • コラム AbemaTVで即戦力となった新規参入エンジニアの例
  • 複数のテスト・アプローチでテスト工数を下げる
  • 複数アプリケーションの開発を容易にする

2-4 コンポーネント・ベースUI開発がもたらすユーザー・メリット

  • 多機能アプリケーションのユーザビリティを向上させる
  • UIとは会話である
  • YUコンポーネントは単語

2-5 コンポーネント設計の基本を知る

  • コンポーネントがもつ4つの特徴
  • コンポーネント設計で押さえておきたい2つのポイント

2-6 コンポーネント・ベースUI開発の現状

  • コンポーネント化に向かない特性
  • コンポーネント化を実現する言語仕様
  • 現状でコンポーネント・ベース開発を実現するツール
  • モジュール化したJavaScriptのコードをバンドルするwebpack
  • CSSに擬似的なスコープを与えるCSS Modules

第3章 Atomic DesignによるUIコンポーネント設計

3-1 Atomic Designとは

  • UIコンポーネント設計のためのデザイン・フレームワーク
  • コンポーネントは化学要素と同じ
  • コラム 化学用語とWeb用語が混在している理由

3-2 UIコンポーネントの分割基準を考える

  • 階層の依存関係を整理する
  • デザイン視点で関心の分離を考える
  • UIデジアンの関心事をAtomic Designで階層化する
  • 階層化するメリット

3-3 Atoms(原子)を設計する

  • プラットフォームのデフォルトUI
  • プラットフォームのデファクト・スタンダードなUI
  • レイアウト・パターン
  • セマンティックなデザイン要素
  • デジアンの統一感を支える

3-4 Molecules(分子)を設計する

  • ユーザーの動機に対する機能を提供する
  • コラム 化学と同じAtomsとMoleculesの関係性
  • Moleculesのデザインを統一するには

3-5 Organisms(有機体)を設計する

  • 独立して成立するコンテンツを提供する
  • MoleculesとOrganismsの分け方

3-6 Templates(テンプレート),Pages(ページ)

  • ページ・レイアウトに対する責務を担う:Templates
  • コンテンツとコンポーネントをつなぐ:Pages

第4章 UIコンポーネント設計の実践

4-1 開発環境を準備する

  • Node.jsのインストール
  • Yarnをインストールする
  • サンプル・プロジェクトのダウンロード

4-2 UIコンポーネントの設計を考える

  • Atomic Designによるコンポーネント設計実践
  • デザインカンプからコンポーネントを分割する
  • Atoms層コンポーネントの抽出度を適切にする

4-3 UIコンポーネントを実装する

  • コンポーネント・リストとは
  • Storybookでコンポーネント・リストをつくる
  • Atoms層のコンポーネント実装:Balloon
  • Atoms層のコンポーネント実装:Img
  • Atoms層のコンポーネント実装:Heading
  • Atoms層のコンポーネント実装:TrashCanIcon
  • Atoms層のコンポーネント実装:Txt
  • Atoms層のコンポーネント実装:Time
  • Molecules層のコンポーネント実装:DeleteButton
  • Organisms層のコンポーネント実装:Notification
  • Organisms層のコンポーネント実装:NotificationList

4-4 コンポーネント実装におけるポイント

  • ロジックと表示に関する責務を分離する
  • Stateless Functional Componentで表示を予測しやすくする
  • コンポーネント同士を組み合わせやすくする
  • Higher-order Componentでさらに効率良くコンポーネントを実装する

4-5 コンポーネントに適切なスタイルを与える

  • レイアウトしやすいスタイル
  • UIコンポーネント外部からスタイルを適用する
  • 別の要素に影響を与えるスタイルの回避

4-6 アプリケーションにおける統一性担保

  • 基本的な視覚デザイン要素を一元管理する
  • デザイナーの頭の中をデザイン要素管理に反映する
  • デザイン要素を階層化して管理する
  • CSS Custom Propertiesでデザイン要素の値を定義する

4-7 UIコンポーネントを適切に命名する

  • 命名の重要性
  • 役割に対して逸脱しない名前をつける
  • 関心に応じた抽象度を表現する

4-8 アプリケーションとコンポーネントを接続する

  • Templates層とPages層の役割を理解する
  • データの流れとコンポーネントを分離する
  • Fluxアーキテクチャ
  • FluxアーキテクチャをAtomic Designと利用する
  • アプリケーションとして実行する
  • コラム Storybookでコード・スニペットを表示する

第5章 UIコンポーネントのテスト

5-1 テスタブルなUIコンポーネントを作って高速で堅牢な開発

  • 知らない間に壊れているUI
  • アプリケーションに組み込まれたUIのテストは大変
  • UIのテストに使えるツールが揃ってきた

5-2 UIコンポーネントの単体テスト

  • コンポーネントをサンドボックス化した環境でテストする意味
  • UIが正しく表示されるかどうかテストする
  • 表示テストのフィードバックをコンポーネント・リストに追加する
  • インタラクションが正しく動くかどうかテストする
  • コラムUIがにおける手動テストと自動テスト

5-3 リグレッション・テスト

  • ストラクチュラル・リグレッション・テスト
  • ビジュアル・リグレッション・テスト

5-4 ロジック・テスト

  • コンポーネントが満たすべき条件をテストする
  • 効果的な開発を実現するテスト駆動開発

5-5 インタラクション・テスト

  • Enzymeを使ってテストする
  • インタラクション・テストを自動で行う

5-6 コード・カバレッジ

5-7 レイアウト・テスト

  • レスポンシブ・レイアウト・テスト
  • リキッド・レイアウト・テスト

5-8 パフォーマンス・テスト

  • ネットワーク・アクセス
  • JavaScript実行時間
  • レイアウト/ペイント処理
  • 体感速度
  • パフォーマンス・ボトルネックを解決できなかった場合の対処方法

5-9 インクルーシブ・ユーザビリティ・テスト

  • クロス・プラットフォーム・テスト
  • アクセシビリティ・テスト
  • コラム 情報アクセシビリティ環境づくりに向けた世の中の動き
  • アクセシビリティ・テストを自動化する
  • コラム 色のコントラストについて,自動化を試みる
  • アクセシビリティ・レイアウト・テスト
  • コラム i18nテスト

5-10 A/Bテスト

  • TemlatesのA/Bテストで最適なページ・レイアウトを検証する
  • OrganismsのA/Bテストで最適なコンテンツの見せ方を検証する
  • MoleculesのA/Bテストでタスクの最適なユーザビリティを検証する
  • A/Bテストでは特に変更に強いUI設計が求められる
  • コラム トリバゴのユーザーテスト事例

5-11 CIツールを利用して継続的に自動テストする

  • 継続的インテグレーションとは
  • CircleCIで継続的なテスト環境を構築する
  • コラム macOS/LinuxでCircleCI環境を再現する

第6章 現場におけるコンポーネント・ベース開発のポイント

6-1 エンジニアとデザイナーの問題解決におけるアプローチの違いを知る

  • ボトムアップとトップダウンのアプローチ
  • デザインの仕組み化で,両者の方向性を合わせる

6-2 デザインカンプとコンポーネント・ベース開発のかい離を解決する

  • デザインカンプから生まれやすい問題
  • 既存のデザインのワークフローを活かす
  • デザインカンプを活かすためのインターフェース・インベントリ

6-3 長期の開発でコンポーネント・リストを死なせない工夫

  • コンポーネント・リストがプロダクトからかい離する原因
  • ソースコードを共有するしくみで開発の効率化と同期を図る

6-4 平行実装で開発を加速する

  • Gitにおけるコンポーネント・リスト・ドリブン開発
  • 先にモック・コンポーネントを実装する

6-5 小規模プロダクトにおけるコンポーネント・ベース開発のメリット

  • プロダクを超えて使えるコンポーネントを作る
  • クロス・プラットフォームに対応しやすい
  • レスポンシブ・テストの工数を減らす

6-6 Webフロントエンドエンジニア以外の関心を引く

  • まずはコンポーネント・リストを作って共有する
  • デザイン課題をコンポーネント・リストで共有する
  • エンジニア以外が実装に参加できる環境を作る

6-7 サービスに合わせてAtomic Designをカスタマイズする

  • Atomic Designの良いところだけを取り入れる
  • サービス/開発とフレームワークの相性をきちんと見極める

6-8 サービスのフェースに応じて進化するデザイン・システム

  • フェーズによってサービスの課題は異なる
  • デザインを仕組み化する
  • コンポーネント・リストからデザイン・システムを拡張する
  • さくいん

著者プロフィール

五藤佑典(ごとうゆうすけ)

株式会社サイバーエージェント所属のエンジニア。米国カリフォルニア州立大学サンバナディーノ校でグラフィックデザインを学んだ後,大手IT会社にてマーケティングとデザイン業務に従事。現職でエンジニアに転向。「AbemaTV」にてUI設計に携わり,実装レベルで初めて「Atomic Design」を導入した。現在は,技術領域を動画へと広げて,「AbemaTV」の動画技術戦略に携わり,国内外で動画事業における技術研究を行っている。