マルチデバイスのUIデザイン設計

# 📚 主な参考書籍

[UIデザインの教科書［新版］ マルチデバイス時代のインターフェース設計(著: 原田秀司)](https://www.shoeisha.co.jp/book/detail/9784798155456)

# デザインの目的とUI/UX

## デザインの目的

`デザイン(Design)`とは、**機能の仕方(how it works)** であり、見え方(how it looks)ではない。

| 概念 | 概要 |
| --- | --- |
| デザイン(Design) | **既存の状態から好ましいものへと移行**するプロセス |
| アート(Art) | 人の心を動かし鼓舞するもの |

とある機能が寡占状態にあれば、**機能そのもの**に価値が生じるためデザインの価値は相対的に低下する。
→ 機能が一般的になるにつれ、インタフェースや使い勝手が差別化要因として重要になる。

## UIとUX

| 概念 | 概要 |
| --- | --- |
| UI(User Interface) | ユーザ ⇄ システム(サービス) の接点 = **客観的** |
| UX(User Experience) | ユーザがサービスによって受ける全ての体験 = **主観的** |

参考: `カスタマージャーニーマップ` … 顧客が経験する一連の行動を、旅の地図のように可視化する手法

![カスタマージャーニーマップ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/3dd450a3-61ab-d1e0-97bb-1563f6001e1b.png)

**必ずしも優れたUIが優れたUXとなるわけではない**。
例えば、スマートフォンにおけるアカウント認証機能で「メールアドレス」と「パスワード」の入力欄のUIを洗練されたものにするより、デバイスに備わった**指紋認証や顔認証**を用いた方が良い場合もある。

参考: Design vs. User Experience
→ 道路に設計された道(Design)と実際にユーザが通る道(User Experience)について、デザインされた道をいくら整備しても根本的な改善には繋がりにくい。

![Design vs. User Experience](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/177c4c05-7ede-a03d-316a-b84738a80662.png)

広告・セールス・マニュアルの`可読性`・`視認性`・`判読性`からサポート応対まで、**サービスに関するあらゆる事象が`UX`に影響**する。

| 「読みやすさ」の指標 | 概要 |
| --- | --- |
| 可読性(Readability) | 長文の疲れにくさや読むスピード = **読みやすさ** |
| 視認性(Visibility) | 字の発見しやすさや目立ちやすさ = **認識しやすさ** |
| 判読性(Legibility) | 似た字の区別しやすさや読み間違いの少なさ = **誤読の少なさ** |

# 物理的な制約

## デバイスのバリエーション

|  | スマートフォン | タブレット | PC | スマートTV |
| --- | --- | --- | --- | --- |
| 入力手段 | タッチパネル | タッチパネル | キーボード+マウス<br>トラックパッド | リモコン |
| 画面の大きさ | 小さい<br>4-7インチ程度 | 中程度<br>7-13インチ程度 | 大きい<br>11-27インチ程度 | 非常に大きい<br>32-60インチ超 |
| 画面の可変さ | 全面固定 | 全面固定 | 可変(ブラウザ) | 全面固定 |
| 画面の向き | 主に縦(時に横) | 縦・横 | 任意(ブラウザ) | 横のみ |
| 画面との距離 | 至近 | 近い | やや近い | 非常に遠い |
| アスペクト比 | 16:9 , 18:9 など | 4:3 , 16:10 など | 16:9 , 16:10 など | 16:9 |
| 文字の入力 | △ | △ | ○ | × |
| 操作の細かさ | △ | △ | ○ | × |
| デザインする要素の大きさ | やや大きい | 大きい | 小さい | 非常に大きい |
| プライバシー性 | 1人 | 1人・共用 | 主に1人 | 多人数かつ同時 |
| 機動性 | ◎ | ○ | △ | × |
| 二面性をもつ端末 | ファブレット | ファブレット<br>タブレットPC | タブレットPC |   |

※ファブレット(Phablet) … 「5.5-7インチのスマートフォン」の総称

## 入力手段の違い

| デバイス | 入力手段 | 特徴 | メリット | デメリット |
| --- | --- | --- | --- | --- |
| スマートフォン<br>タブレット | タッチパネル | ゆったりと大まかな画面<br>閲覧向き<br>**目視**によるコンポーネントの選択可否<br>**片手**による操作 | 多様な**ジェスチャー操作**<br>**インタラクション**が使える | 文字入力がやや弱い<br>**大きめのコンポーネント**が必要<br>ホバーが使えない<br>**指の可動範囲**を考慮 |
| PC | キーボード<br>ポインティングデバイス | 細かいコンポーネント<br>縦長の画面<br>ホバーやスクロールの活用 | 細かい操作が可能<br>**縦スクロール**に強い<br>文字入力が容易<br>**ホバー**が使える | **横スクロール**に弱い |
| スマートTV | リモコン<br>コントローラ | **フォーカス移動・音声入力**による操作 | **インタラクション**が使える | コンポーネントの**直接選択**が不可<br>フォーカス位置の変更に**肉体的負担**が生じやすい<br>**コンポーネントの連続性**を考慮 |

`スマートTV`における**フォーカス位置の視認性**を向上させるために、以下のような表現の差別化を(できれば2つ以上)加えるのが望ましい。

- 枠でくくる
- 背景色・文字色を変える
- 要素を大きくする
- 動きをつける

また、`スマートTV`のフォーカス位置の変更には肉体的負担が生じるため、なるべく同じボタンの連打で済むよう**縦または横の一方向**の移動が望ましい。

参考: スマートTVアプリのUIデザイン

![スマートTVアプリのUIデザイン](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/edce77a9-4b23-2561-7bdc-55b1332cb55e.png)

### クリック/タッチ/フォーカスの違い

| デバイス | 選択手段 | メリット | デメリット | 直接選択 |
| --- | --- | --- | --- | --- |
| スマートフォン<br>タブレット | タッチ | **多様なジェスチャー**が可能 | ホバーが活用できない<br>細かい操作に不向き | ○ |
| PC | クリック | 細かい操作が可能<br>**ホバー**が活用できる | - | ○ |
| スマートTV | フォーカス | **インタラクション**が活用できる | **肉体的負担**が大きい<br>細かい操作に不向き | × |

**直接選択が可能**な`PC`・`スマートフォン`・`タブレット`は基本的に同じUIでデザインできるのに対し、**直接選択ができない**`スマートTV`は異なる考え方でデザインする必要がある。
また、近年ではスマートTVリモコンの操作性の悪さを解消すべく、Google社の「**Google Cast**」機能やApple社の「**Remote**」アプリをはじめとする**スマートフォンとの連携アプリ・機能**が登場している。

## 画面の違い

| 視覚要因 | スマートフォン | タブレット | PC | スマートTV |
| --- | --- | --- | --- | --- |
| 画面の距離 | 近い | 近い | 近い | 遠い |
| 画面サイズの**可変性** | 可変 | 固定 | 固定 | 固定 |
| 画面の**アスペクト比** | 任意 | 16:9 | 4:3 | 16:9 |
| 画面の**大きさ** | 小さい(※) | 中程度(※) | 大きい | 非常に大きい|
| 視角 | 狭い | やや狭い | 広い | 非常に広い |
| 画面の向き | 縦・横 | 縦・横 | 横 | 横 |

※2022年5月現在、`Android`では「**マルチウィンドウ**」、`iPad`では「**Split View**」などの画面分割が可能になっている。

画面の向きは、「**スクロール方向**」と「**サービスの機能**」に大きく影響を与える。
「スクロール方向」は**画面が長い方向にスクロールする方が自然**に感じられる性質を指し、「サービスの機能」は同アプリ内でも**画面の向きに応じてUIが変化**する性質を指す。

また、`スマートTV`では**画面の外枠周囲**に「番組タイトル」や「現在時刻」などの情報が表示される可能性を踏まえ、「**画面全体の内側90%**」を目安としたセーフゾーンを意識する必要がある。

参考: スマートTVアプリにおけるセーフゾーン(Safe Zone)

![スマートTVアプリにおけるセーフゾーン](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/16474b64-0bfe-fc3e-d371-4fdefc679bb1.png)

## AndroidとiPhone

`iPhone X`以前の`iPhone`ではハードウェアとして「**ホームボタン**」を採用しているが、多くの`Android`では画面内に「**戻るボタン**」が配置(= **`Android`の優位性**)されている。
この差異によって`iPhone`では **「戻る」機能をアプリ内で実装**する必要があるため、同サービスのアプリでもUIに差異が生じる。

参考: 「Facebook」アプリにおけるUIの差異

![「Facebook」アプリにおけるUIの差異](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/35f33382-4f02-9310-5b54-008dad57157f.png)

→ `Android`版では「戻るボタン」(またはジェスチャー操作)によって**ページ上部への移動・ページの更新が行える**ため、**指の可動範囲内**にホームタブを設置する必要がない。

# ソフトウェアの影響

## OS

| デバイス | Google | Apple | Microsoft |
| --- | --- | --- | --- |
| スマートフォン | Android | iOS | (Windows Phone) |
| タブレット | Android | iPadOS<br>iOS | Windows |
| PC | ChromeOS | macOS | Windows |
| スマートTV | AndroidTV | tvOS | - |

## Webとアプリ

| ソフトウェア | 区分 | メリット | デメリット |
| --- | --- | --- | --- |
| アプリ | 専用ツール | 動作が速く、**操作が軽快**<br>タッチパネルの場合は**多様なジェスチャー操作**に対応<br>データ通信量が少ない<br>中断・再開が容易 | OSごとに異なるプログラム言語で開発する必要がある<br>最適なUIがデバイス・OSによって異なる<br>サービス毎にインストールが必要 |
| Webブラウザ | 汎用ツール | **マルチデバイス**展開が容易<br>OSの違いによる環境の差異が小さい<br>**同時に複数**のブラウザを起動できる<br>サービス毎のインストールが不要 | 操作スピードが遅い<br>操作上のインタラクションが乏しい<br>ジェスチャー対応が難しい |

※ネイティブ(Native) … OSと直接やり取りするプログラム言語。`Android`では`Java`・`Kotlin`、`iOS`では`Swift`・`Objective-C`。

`Webサイト`は**URLと不可分に結びつく**ため、**デバイス種類が同じであればOSが異なっていてもUIがほぼ同じ**になる。
そのため、同じURLであっても画面幅によって表示コンテンツを切り替える**レスポンシブデザイン**で実装することで、**マルチデバイス対応**が可能となる。

また、`スマートフォン`や`タブレット`のアプリでは`iOS`・`Android`間で**ハードウェアやデザインガイドラインが異なる**ため、それぞれで**UIデザインを工夫**する必要がある。

### Webサイトとアプリの使い分け

| ソフトウェア | 特長 |
| --- | --- |
| Webサイト | **実装の容易さ**<br>サービスを利用してもらう**手軽さ**<br>**マルチデバイス**の対応力 |
| アプリ | 動作の**高速性**・操作の**軽快さ**<br>単機能・サービスの**専用性**<br>**インタラクション**の対応力 |

### PWA(Progressive Web Apps)

**Webサイトをネイティブアプリのようにインストール**できる技術を`PWA`と呼ぶ。

| メリット | デメリット |
| --- | --- |
| **ホーム画面に追加するだけ**で利用可能<br>**動作が軽快**で表示速度に優れる<br>キャッシュを利用した**オフライン操作**<br>**プッシュ通知**が可能<br>`スマートフォン`・`タブレット`・`PC`で利用可能 | インタラクション対応はアプリに劣る<br>「戻る」機能の実装が必要 |

参考: 「Twitter」におけるアプリ・PWA・WebブラウザのUI

![「Twitter」におけるアプリ・PWA・WebブラウザのUI](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/99aa8d43-c535-20ae-c19f-81de367f1676.png)

## 解像度

| 区分 | 概要 |
| --- | --- |
| 物理解像度 | **ハードウェア**として表示できる解像度 |
| 理論解像度 | **OS**によって実際に表示される解像度 |

※ドットバイドット(dot by dot) … **物理解像度と理論解像度が同値**である状態

近年はディスプレイ技術の発達によって、あらゆるデバイスにおいて**物理解像度 > 理論解像度**となっており、**縦横の物理解像度がそれぞれ理論解像度の$n$倍**である場合は **「@$n$x」または「$n$倍」解像度**と呼ばれる。

参考: n倍解像度

![n倍解像度](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/1d39c3c8-799a-4f18-6e48-a6171fc2ad29.png)

## テキスト

テキストで表示できるものは画像化せず**テキストのまま表示**するのが望ましく、その理由として以下の点が挙げられる。

- **OS**によって**あらゆるデバイス・解像度下での最適な表示**が担保
- **コピー&ペースト**が可能
- 海外のユーザが**翻訳機能**によって閲読できる
- 技術や解像度の進化による経年の影響を受けない

参考: テキストによる解像度比較

![テキストによる解像度比較](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/6573be94-0c72-7d8f-7f77-11291c70fd7a.png)

### 国コードと言語コード

Webサイトではしばしば、URLに`国コード`・`言語コード`の両方を埋め込むことで、地域・言語に応じた**多言語対応**が行われている。

| 国コード/言語コード | 国名 | 言語名 |
| --- | --- | --- |
| jp/ja | 日本 | 日本語 |
| us/en | アメリカ | 英語 |
| uk/en | イギリス | 英語 |
| ca/en | カナダ | 英語 |
| cn/zh | 中国 | 中国語 |

## 画像

画像はOSやデバイスといった**環境によらず同一に表示**できるという最大の特長をもつ。
テキストを画像化する利点として、テキストの行間・マージンやアンチエイリアス(anti-aliasing)のように**文字に対して細かく調整**できることが挙げられる。

ラスタデータのデメリットである**解像度に応じて画像データを複数用意**しなければならない点について、近年では2倍解像度の画像のみで対応するケースも見られる。
**人間には3倍以上の解像度の違いがほとんど認知できない**ため、等倍解像度では縮小、3倍以上の解像度では拡大して表示している。

参考: 解像度と画像データ(ラスタデータ)

![解像度と画像データ(ラスタデータ)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/dca68060-b7dd-927d-9096-5699c13e87c7.png)

| 形式 | 概要 | メリット | デメリット | 主な拡張子 |
| --- | --- | --- | --- | --- |
| ラスタデータ(raster data) | 1pxごとの情報を集積した画像形式 | 写真のような**繊細な画像**を表現できる<br>ほとんどの環境で表示できる | 解像度に応じたサイズの画像を分けて用意 | `gif`<br>`jpeg`<br>`png`<br>`bmp`<br>`webp` |
| ベクタデータ(vector data) | 幾何学的計算によって描画される画像形式 | **解像度の影響を受けない** | 色・形状が**単純な図形**しか表現できない<br>古い環境・ブラウザでは非対応 | `svg`<br>`pdf` |

参考: ラスタデータとベクタデータ

![ラスタデータとベクタデータ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/70cef96c-e1ad-02eb-2cb0-0bde5b8dd099.png)

## 動画

動画はコンテンツとして利用するほか、**バックグラウンドムービー**として補助的な役割を持たせることができる。

## Unityによるマルチプラットフォーム実装

アプリの難点の一つである**デバイス・OSごとに個別のプログラム言語で開発**しなければならない点を解消した`Unity`では、以下のようなほぼ全ての環境での**マルチプラットフォーム実装**ができる。

- スマートフォン・タブレット(`iOS`・`Android`・`iPadOS`・`Fire OS`)
- PC(`Windows`・`macOS`・`Linux`)
- スマートTV(`tvOS`・`Android TV`・`Fire OS`)
- ゲーム機(`PlayStation`・`Nintendo Switch`・`Xbox`)
- AR/VR(`ARCore`・`Playstation VR`・`Microsoft HoloLens`)
- Web(`WebGL`・`Unity Web Player`プラグインが導入済のWebブラウザ)

| メリット | デメリット |
| --- | --- |
| **ほぼ全てのプラットフォーム**に対応<br>拡大・縮小・回転のような**3D演算処理が高速** | OSごとのネイティブ言語で開発・最適化されたアプリに比べ**動作が低速** |

## HTTP/3

`HTTP(Hypertext Transfer Protocol)`は、**Webサーバ ⇄ Webクライアント間でデータを送受信**するためのアプリケーション層プロトコルである。

| バージョン | 概要 |
| --- | --- |
| 0.9 | URLによるHTML取得 |
| 1.0 | **複数ドキュメント**の送受信<br>HTML以外のデータ形式に対応<br>コンテンツの追加・削除・更新<br>サーバからのリダイレクト要求 |
| 1.1 | `Keep-Alive`・`HTTPパイプライン`による通信の高速化<br>`TLS(Transport Layer Security)`によるデータの暗号化<br>`チャンク形式エンコーディング(Chunked Transfer Encoding)`によるデータの逐次処理 |
| 2.0 | バイナリ形式の`フレーム`による処理の高速化<br>ストリーム(Stream)による**複数リクエスト・レスポンスの並列処理、優先度指定**<br>`サーバプッシュ(Server Push)`によるHTTPレスポンスの事前送信<br>`HPACK`によるヘッダ圧縮・差分更新 |
| 3.0 | `QUIC`によるUDP通信(3Way Handshakeの削除)<br>`QPACK`によるヘッダ圧縮・差分更新<br>`QUICストリーム`による`TCP Head-of-Line Blocking`の解消 |

※TCP Head-of-Line(HoL) Blocking … 先頭ストリームで生じたパケットロスによって、後続ストリームの処理に遅れが発生すること

## Resource Hints API

`Resource Hints API`は、**コンテンツやDNSの先読みをブラウザとして提供**する仕組みであり、**描画するコンテンツに優先度を割り当てる**ことで操作上の高速化を図ることができる。

## AMP

`AMP(Accelerated Mobile Pages)`は、**モバイルページの表示を高速化**する仕組みであり、**非同期方式のJavaScriptの使用を制限**したり、`AMP Cache`によって**コンテンツをCDN(Content Delivery Network)上にキャッシュ**したりすることで読み込み速度の高速化を図ることができる。

一方で、通常の`HTML`に加え **`AMP HTML`を用いてWebページを実装**する必要があり、AMPページは**ドメインがCDNのプロバイダのものに変更**されるため、アクセス解析時に集計結果や指標が不正確になるというデメリットがある。

# 人間の認知特性

## 色・形・動き

| 認知対象 | 効果 | 注意点 |
| --- | --- | --- |
| 色 | 要素の**瞬間的な把握**<br>**状況理解**の促進 | 色数を増やさない<br>誤認しやすい色を組み合わせない |
| 形 | 要素の**瞬間的な把握**<br>**状況理解**の促進<br>色覚障害者に対する**アクセシビリティの向上** | 類似形状を羅列しない |
| 動き | **注意**を引きつける<br>**状態変化**の把握<br>ギミック(※)の演出 | 多用しない |

※ギミックの例として、**背景画像とのスクロール距離に差をつける**ことで画面に奥行きを持たせる`パララックス(Parallax)`や、**写真の一部に動きをつける**`シネマグラフ(Cinemagraph)`などが挙げられる。

## インタラクションコスト

インタラクションコスト(Interaction Cost)とは、ユーザが目的を達成するために必要な**精神的・肉体的負荷の総量**で、**ユーザビリティ(サービスの使いやすさ)の指標**となる。

| 種類 | コスト | 例 |
| --- | --- | --- |
| 精神的負荷 | 待機<br>発見<br>解釈<br>記憶 | ページの読み込みを待つ<br>ページ内から目的達成の手がかりを探す<br>対象の情報・コンポーネントを把握する<br>情報を覚える |
| 肉体的負荷 | クリック・タップ<br>スライド<br>スクロール<br>スワイプ | マウスのボタンを押す<br>マウスを動かす<br>マウスのホイールを動かす<br>指を動かす |

インタラクションコストを最小限に抑えた「**直感的**」な状態とは、**ユーザの予測とその結果が完全に一致**することを指す。

| アプローチ | 概要 | メリット | デメリット |
| --- | --- | --- | --- |
| 一貫性(Consistency) | サービス内のデザイン要素全てが**一定の基準に準拠** | コンポーネントの理解・操作が予測可能<br>機能の追加・改善が容易<br>信頼性が向上 | 柔軟性に欠ける |
| 簡潔性(Simplicity) | **意味と目的が明快**な最小限の要素で構成 | 認知資源が節約できる | 複雑な操作を行う際の手順が増える |
| 一般性(Universality / Familiarity) | **学習コストが不要**な要素で構成 | コンポーネントに対する学習コストを抑えられる | 国や地域によって意味が変わる(※) |

※**文化・言語・年齢・能力によらず万人が利用可能**な`ユニバーサルデザイン(Universal Design)`を用いるのが望ましい

# 階層と構造

## 階層の深さと広さ

階層の「深さ」は**階層深度**、「広さ」は**同一階層内でのカテゴリ数**を表す。
サービスで扱う情報量が同一である場合は「**浅く広い**」状態が望ましいとされており、その理由として`ラベリング(labelling)`をする際に**排他的(exclusive)な命名**が行いやすいことが挙げられる。

モバイルアプリケーションでは階層を表現するのに`タブバー(Tab Bar)`が多く用いられるが、画面幅の制約上タブアイテムは**多くても5つ**までしか配置できない。
そのため「**その他**」タブに機能が詰め込まれるケースがよくあるが、ラベリングとしては**抽象的(abstract)・包括的(inclusive)** であり好ましくない。

代替手段の一つとして、**階層を縦に表現**する`ハンバーガーメニュー(Hamburger Menu)`が挙げられる。

参考: モバイルアプリにおけるタブバーとハンバーガーメニュー

![モバイルアプリにおけるタブバーとハンバーガーメニュー](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/3e7867fe-8f21-b3f3-3be8-a54305146530.png)

## 現在地と差別化表現

| 手法 | 概要 |
| --- | --- |
| パンくずリスト(breadcrumb list) | 何らかの区切り文字を用いて、トップページから現在地までの階層をテキストで表現 |
| カレント表示(current location) | **差別化表現**を用いて、現在地や展開中のカテゴリを表現 |

`パンくずリスト`はページの**現在地を正確に表現**できる一方で、テキストによる表現であるため**認知負荷(Cognitive Load)** が生じる。

カレント表示で用いられる差別化表現としては、以下の5種類の手法がある。

| 手法 | 概要 |
| --- | --- |
| 太さ(Weight) | 太字(bold) / 細字(regular) |
| 色(Color) | 明度差(brightness) / 彩度(saturation) |
| 級数(Size) | サイズ |
| 背景(Background) | 背景色 |
| 目印(Point) | 下線(underline) / アイコン |

`スマートTV`では**身体的負荷が大きくなる**傾向があるため、**フォーカスの移動と同時に画面を遷移**することでインタラクションコストを抑えるケースがある。

また、長い読み物系のサービスでは**スクロールと連動して目次の装飾を変える**ことで、**ページ内のカレント表示**を行っているものがある。

参考: ページ内のカレント表示(UX MILK)

![ページ内のカレント表示(UX MILK)](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/53cb1a65-0fc6-dd80-6c45-a303d1ede599.png)

## トップ・一覧・詳細

多くのサービスは、**トップ・一覧・詳細**ページの**3層構成**からなり、**トップページが一覧ページの機能を兼ね備える**ケースもある。

| ページ | 概要 |
| --- | --- |
| トップ | サービスの表紙 |
| 一覧 | 詳細情報の見出し・概要リスト |
| 詳細 | ユーザが求める詳細情報 |

ユーザが求める詳細ページに辿り着くには必ず「一覧」ページを経由するため、**一覧ページのUIが最も重要**である。
一覧ページに必要な機能は基本的に以下の3つであり、これらのコンポーネントを**常設**するか**格納**するかはデバイスごとの画面幅の制約に応じて設計する。

| 機能 | 概要 |
| --- | --- |
| 絞り込み(filter) | 指定した条件をもとに対象を絞って表示する機能 |
| 並べ替え(sort) | 任意の属性を基準に全体を並べ替える(※)機能 |
| 切り替え(switch) | 見せ方をリスト・ブロック表示で切り替える機能 |

※`並べ替え`では、**ソート基準も属性値として表示**するのが望ましい

参考: トップから詳細への経路

![トップから詳細への経路](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/9e88e6a9-8b23-a970-e171-ed229daba4dc.png)

## 関連情報

**詳細**ページでは、詳細情報の他に**関連情報へのリンクを用意**することでユーザの潜在的欲求を満たせる可能性がある。

| 情報の種類 | 概要 | 詳細情報が「プリンタ」である場合の例 |
| --- | --- | --- |
| 付随 | 詳細情報に付随する**別カテゴリ**の情報 | マニュアル<br>ドライバ |
| 同種 | **同一カテゴリ**に分類される情報 | 他のプリンタ<br>インク<br>コピー用紙<br>ケーブル |

## 混乱を招く要因

**ブラウジング中にユーザが混乱する要因**は**構造と操作において一貫性のあるUI**にすることで解消することができる。

| 混乱の要因 | 概要 |
| --- | --- |
| 場所 | 全体における現在地の位置関係が不明 |
| 操作 | 目的地に到達するまでの操作に規則性・一貫性がない |

# ナビゲーションとインタラクション

## ナビゲーション

参考: [Chapter 4. Types of Navigation(O'Reilly)](https://www.oreilly.com/library/view/designing-web-navigation/9780596528102/ch04.html)

`ナビゲーション(Navigation)`とは、ユーザが目的の情報・機能に到達するための**インタフェースの集合体**を指す。
適切なナビゲーションの配置場所は、利用する**デバイスやインタフェースによって変化**する。

| 手法 | 概要 | 役割 |
| --- | --- | --- |
| ヘッダ(header) | ページ上部に配置するリンク集 | ユーザアクションの起点<br>サービスの全体像を訴求 |
| フッタ(footer) | ページ下部に配置するリンク集 | 優先度の低いリンクの配置 |
| パンくずリスト(breadcrumb list) | 現在地を基準とした上部階層へのリンク集 | 現在地の明示<br>上位階層への移動 |
| グローバルナビゲーション(global navigation) | ページ内に表示される最も大きなカテゴリ間のリンク集 | サービスの全体像を訴求 |
| ローカルナビゲーション(local navigation) | グローバルナビゲーションで選択したカテゴリ内でのリンク集 | 現在地の明示 |
| メガドロップダウンメニュー(mega-dropdown menu) | 選択カテゴリ内のコンテンツを表示するプルダウンメニュー | サービス詳細の提示 |
| 関連ナビゲーション(associative navigation) | 関連情報へのリンク集 | 潜在的欲求の導出<br>新情報の提示 |
| オーバーレイ(overlay) | ページ内に立体的に挿入される追加情報 | 意識の強制を伴う補足情報の提示 |
| インレイ(inlay) | ページ内に平面的に挿入される追加情報 | 意識の強制を伴わない補足情報の提示 |
| アコーディオン(accordion) | 蛇腹型に列挙した見出し群 | 全体像の早期提示<br>コンテンツ量の制御 |
| 埋め込みナビゲーション(embedded navigation) | コンテンツ内に配置されるテキストリンク | 関連情報の提示 |
| 無限スクロール(infinite scroll) | コンテンツを無制限に表示するスクロール | スクロールのみの軽快な操作性<br>コンテンツに対する意識の集中 |
| ページネーション(pagenation) | 情報量の多いコンテンツを分割した各ページへのリンク | コンテンツ量の制限 |

### ヘッダ

画面のスクロールに応じて注目対象をコンテンツへと遷移させる場合、**ヘッダを格納**するのが望ましい。
このとき、タブバーを用いた`モバイルアプリ`のように画面上下にナビゲーションがある場合は**最も有用なナビゲーション以外は非表示**にするのが望ましい。

### パンくずリスト

| 種類 | 表示経路 | メリット | デメリット |
| --- | --- | --- | --- |
| 優先型 | 固定された1つの経路 | 実装が容易 | 実際の経路と異なる場合がある |
| 複数型 | 全ての経路 | 実装が容易<br>バリエーションを列挙できる | 見た目が冗長的 |
| 変動型 | 実際の経路 | 実際の経路を提示できる | 実装が困難 |

## インタラクション

`インタラクション(interaction)`とは、ユーザの入力に対する**動き・変化を伴うフィードバック**を指す。

| 目的 | 概要 |
| --- | --- |
| 理解 | **状況の変化に対する理解**を促すための動き |
| 演出 | **サービスの魅力**を向上させる動き |

関連: `マイクロインタラクション(microinteraction)` … 製品・サービスにおける「必須ではないがあれば良い」という**最小単位のインタラクション**

## カラムと左右ナビゲーション

| カラム数 | メリット | デメリット |
| --- | --- | --- |
| 1 | ヒーローイメージ・レスポンシブデザインとの相性が良い<br>演出的なインタラクションとの親和性が高い | ナビゲーションの工夫が必要 |
| 2(左右のどちらか) | ナビゲーションしやすい<br>`スライド`を用いることでモバイルアプリにも対応可能 | ある程度の画面幅が必要 |
| 3(左右の両方) | コンテンツ量の多いサービスで有効 | 大きな画面幅が必要 |

※`ヒーローイメージ(Hero Image)` … 画面全体に配置するグラフィック要素またはそのデザイン手法
※`レスポンシブデザイン(Responsive Design)` … 画面幅に応じて表示方法を切り替えるデザイン手法

画面幅の小さいモバイルアプリ等では、`スライド(slide)`を用いることで**擬似的に2カラム・3カラムのレイアウトを表現**することができる。
スライドを用いることの目的としては、以下の2つが挙げられる。

- 画面エリアの制約に対処
- メインコンテンツを強調

| レイアウト | バランス |
| --- | --- |
| 左ナビゲーション | 階層構造 ≒ コンテンツ |
| 右ナビゲーション | 階層構造 < コンテンツ |

## スクロールとページング

画面におけるスクロール方向が**縦と横の2方向**になると意図しない**誤スクロールを誘発**し、操作性が悪くなる。

| 種類 | 概要 | メリット | デメリット |
| --- | --- | --- | --- |
| スクロール(scroll) | **連続的(continuous)** に画面が変化<br>画面の**長辺**との親和性が高い | 演出的なインタラクションとの親和性が高い<br>連続性のある細かい移動が可能 | - |
| ページング(paging) | **段階的(gradual)** に画面が変化<br>画面の**短辺**との親和性が高い | 現在地・経路の道のりが明確<br>コントロール感のある操作性<br>タブ・機能の切り替えとの親和性が高い |  |

| 手法 | 概要 | メリット | デメリット |
| --- | --- | --- | --- |
| 無限スクロール(infinite scroll) | コンテンツを無制限に表示するスクロール | 操作が**スクロールのみ**で済む<br>コンテンツに意識を集中できる | 全てのコンテンツを見れない<br>フッタが使えない<br>スクロール量に応じてメモリが圧迫<br>「戻るボタン」との親和性が悪い(※) |
| 無限ページング(infinite paging) | コンテンツを無制限に表示するページング | 操作が軽快<br>フッタが利用可能<br>現在地・機能が明確 | コンテンツ量に制約がある |
| カルーセル(carousel) | 部分的な横向きのスクロール / ページング | 省スペース性に優れる<br>大量に配置しても構造が崩れない | カルーセルであることを示す視覚的要素(※)が必要 |
| パンニング(panning) | 上下左右のドラッグ | 画面内を自由に動き回れる操作性 | - |

※無限スクロール時の遷移を`オーバーレイ`・`別ウィンドウ展開`で行うことで、**遷移元に戻れる**ような工夫をしているケースもある
※カルーセルかどうかを判別する要素として、`ドットインジケータ`や左右の`矢印アイコン`などが挙げられる

## スクロール方向の決定要素

画面のスクロール方向は**コンポーネントを見切らせる**ことでユーザに識別させる。

| 要素 | スクロール |
| --- | --- |
| テキスト量 | 多い場合は縦<br>少ない場合は縦または横 |
| スクリーン形状 | 長辺方向 |
| 要素の形状 | 短辺方向 |
| 要素間のマージン | 間隔の大きい方向 |

# デザインの実体化

## ミニマルデザイン

`ミニマルデザイン(Minimal Design)`を適用するにあたって、以下の3点を意識する必要がある。

- インタラクションが利用可能かどうか容易に判別できるようにすることで、認知負荷を低減させる
- 色を絞って余白を増やすことで、コンテンツに集中させる
- 不要な装飾・要素を最小限に抑える`ミニマル(minimal)`と`シンプル(simple)`の違いを理解する

| 用語 | 目的 |
| --- | --- |
| ミニマル(minimal) | 認知負荷を下げ、コンテンツへの集中を促す |
| シンプル(simple) | 要素の意味・目的を明快にする |

| デザイン手法 | 概要 | メリット | デメリット |
| --- | --- | --- | --- |
| スキューモーフィズム<br>(skeuomorphism) | コンポーネントを**現実世界の実物に寄せる**ことで親近感を持たせる | シグニファイア(※)に富む | 読み込み時間がかかる<br>画面サイズとの互換性が低い |
| ミニマリズム<br>(minimalism) | コンポーネントの**装飾・要素を極限まで排除**することで認知負荷の低減を図る | 認知負荷の低減<br>マルチデバイス対応 | コンポーネントが目立たない<br>没個性化しがち |

※シグニファイア(Signifier) … `対象物 ⇄ 人間` 間の**インタラクションの可能性を示唆**する手掛かり

| デザイン | 開発元 | 概要 | 参考画像 |
| --- | --- | --- | --- |
| Modern(Metro) UI | Microsoft | パネルやタイルの表現 | ![Modern UI](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/2ab5752c-b227-c0b4-4c22-1e1c41310682.png) |
| フラットデザイン(※) | Apple | ぼかし(blur)による奥行きの表現 | ![フラットデザイン](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/e5c90dbd-a075-932e-d249-9f66d8aa1d75.png) |
| マテリアルデザイン | Google | マテリアルとメタファーに基づく現実世界の表現 | ![マテリアルデザイン](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/51d36f9a-30cf-3d75-32e9-401acff4a9bc.png) |

※フラットデザイン(Flat Design) … 視覚効果を抑え、**シンプルで平面的なコンポーネント**で構成するデザイン手法

## デザインガイドライン

デザインガイドラインを定義する目的は以下の3つ。

- 個々のパーツを定義し、再利用性を向上させることで**成果物の品質を統一**する
- デザイン要素のルールについて綿密に定義することで、**コンポーネントの一貫性を担保**する
- デバイスに左右されない**共通のデザイン・操作感を保証**する

デザインガイドラインは、網羅しようとするのではなく、ルールの存在理由に立ち返りながら**定期的にアップデート**することが重要である。

1. 主要画面の設計
2. デザインガイドラインの作成
3. サブ画面の設計

| デザインガイドライン | 企業 | 概要 |
| --- | --- | --- |
| Human Interface Guidelines | Apple | OSごとのデザインテーマ |
| Material Design | Google | 物質的なデザイン |
| Microsoft Design | Microsoft | 世界観の表現 |

### Human Interface Guidelines

参考: [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/)

| OS | デザインテーマ |
| --- | --- |
| macOS | 柔軟性に富む(flexible)<br>拡張性に優れる(expansive)<br>可能性を引き出す(capable)<br>視認性を高める(focused) |
| iOS | 明瞭性に富む(clarity)<br>コンテンツを目立たせる(deference)<br>立体的にする(depth) |
| watchOS | 一目で分かる(glanceable)<br>情報をもとに意思決定できる(actionable)<br>俊敏性に富む(responsive) |
| tvOS | IoTデバイスと人を繋げる(connected)<br>直感的な理解を促す(clear)<br>没入感を高める(immersive) |

### Material Design

参考: [Material Design](https://material.io/design)

`Material Design`では、以下の3原則を基本としている。

- 実世界の物質に近づける(Material is the metaphor)
- 力強く、生き生きと、意図的に表現(Bold, graphic, intentional)
- アニメーションには意味をもたせる(Motion provides meaning)

### Microsoft Design

参考: [Microsoft Design](https://www.microsoft.com/design)

`Microsoft Design`では、`Fluent Design System`に基づくデザインテーマを以下のように定義している。

- あらゆるデバイスでも自然に(Natural on every device)
- 直感的で力強く(Intuitive and powerful)
- 魅力的で没入できる(Engaging and immersive)

## スケッチ/ワイヤーフレーム/モックアップ/プロトタイプ

`モックアップ`や`プロトタイプ`を作成する際は、試作にリソースを割くことで心理的な`補償(compensation)`が生じないように注意しながら、**思考を実際に動く形で試しながらその良し悪しを吟味**することが重要である。

※`補償(compensation)` … ある事柄に対し劣等感を持っている際、他の事柄で優位に立ってその劣等感を補おうとする防衛機制

| 用語 | 概要 |
| --- | --- |
| スケッチ(sketch) | **アイデア**を視覚化するための絵 |
| ワイヤーフレーム(wireframe) | **コンテンツ・レイアウト**を定めた設計図 |
| モックアップ(mockup) | **ページの前後関係・インタラクション**を擬似的に体験する概要図 |
| プロトタイプ(prototype) | ビジュアル・インタラクション・操作性・印象・パフォーマンスの**ユーザビリティと実装上の問題点**を検証する試作品 |

参考: ワイヤーフレーム/モックアップ/プロトタイプ

![ワイヤーフレーム/モックアップ/プロトタイプ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/295193f3-176f-1787-8640-f7d0d6b46f41.png)

## マルチデバイスデザイン

| 要点 | 概要 |
| --- | --- |
| 機能の同等性 | サービスが提供する機能をデバイス間で同等に扱えること |
| インタフェースの最適性 | デバイス毎の特性を考慮していること |
| サービスの連続性 | デバイスの切り替え時にサービスを再開できること |