Atomic Design（五藤佑典）

書籍情報

著者:五藤佑典
発行日:2018-04-25
ISBN:9784774197050
URL:https://gihyo.jp/book/2018/978-4-7741-9705-0

書籍目次

はじめに
第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 サービスのフェースに応じて進化するデザイン・システム
  - フェーズによってサービスの課題は異なる
  - デザインを仕組み化する
  - コンポーネント・リストからデザイン・システムを拡張する
索引