目次

• はじめに

第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　サービスのフェースに応じて進化するデザイン・システム

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

• さくいん