Human Interface Guidelines（iOS版）まとめ資料

HIG (iOS)
まとめ
2021年10月

HIG（Human Interface Guidelines）とは
- Appleが定めたUI設計における原則
- 以下の4つの環境別にまとめられている
- macOS
- iOS
- watchOS
- tvOS
- 今回はiOSについてまとめる

1. iOSは他のプラットフォームとここが違う
- 明快さ（Clarity）
- 的確で分かりやすいこと
- 尊重（Diference）
- コンテンツを尊重すること
- 奥行き（Depth）
- 奥深さがあること、見た目にも体験的にも階層があり重層的であること

- 明快さ（Clarity）
- どんなサイズでも読みやすいテキスト
- 的確で分かりやすいアイコン
- 微細・控えめかつ適切な装飾
- 機能性に重点を置くこと
- 色、フォント、スペース、グラフィックのような
I/F要素を控えめにさせることでコンテンツを強
調させ、対話的(interactive)であることをユーザに伝える
（I/F＝インターフェース。次ページ以降も同様に略す）

- 尊重（Diference）
- 滑らかな動きと分かりやすく美しい
I/Fがコンテンツの理解と対話に役立つ
- コンテンツは通常画面全体に表示されるが、半透明やぼかしをうまく使うことで多くの場合コ
ンテンツの理解・操作のヒントとなる
- コンテンツがメインとなるように、分かりやすくも邪魔にならない
I/Fとするためにはベゼル、グ
ラデーション、ドロップシャドウの使用を最小限に抑える必要がある
（ベゼル：枠。ボタンの枠線やカードの枠線など）

- 奥行き（Depth）
- 表示上の明快な階層構造とユーザの意図した通りの動き・反応が奥深さとなり、ユーザの
アプリを触りたいという動機・気力となり、理解の手助けとなる
- 触れて発見することで喜び(delight)が高まり、（今アプリがどういう状態なのかという）コン
テキストを見失うことなく機能や追加コンテンツにアクセスできるようになる
- 画面遷移の挙動はコンテンツの移動を通して奥行きを感じさせる

- appleさんがここで言いたかったこと（超意訳）
- appleといえば
- 分かりやすく無駄がない！　美しい！　奥深い！　大事な所に拘ってる！　高級！ etc
- とこんなブランドイメージがある
- こういうブランドイメージを壊すようなアプリデザインにすんなよってこと
- やっぱiOSは違うね、ってそういうイメージを持って欲しい。そのためには
appleの持つブラ
ンドイメージをそのまま表現するようなデザインにしてくれってこと
- どういうデザインなのかはさっき伝えた通り
- じゃあどういう風にすればそれが実現できるか？
- それは次に紹介する原則を守ってくれればいい

2. デザイン原則
- 美的完成度（Aesthetic Integrity）
- 一貫性（Consistency）
- 直接的な操作（Direct Manipulation）
- フィードバック（Feedback）
- メタファー、暗喩、比喩（Metaphors）
- ユーザによる制御（User Control）

- 美的完成度（Aesthetic Integrity）
- アプリの果たすべき役割・目的・機能に合った、美しい見た目・挙動であること
- 例えば、大事な作業の支援を行うアプリであれば、集中力を維持できるようにグラフィック
は繊細かつ控えめにし、予測しやすい挙動で標準で用意された制御部品（ボタンや入力
ボックスなどのcontrolと呼ばれる要素）を使うことが望ましい
- また一方で、ゲームのように没入するようなアプリでは、操作を促し、どんどん新しい発見
をさせるような、楽しそうで魅力的な見た目にする必要がある

- 一貫性（Consistency）
- よく知られている標準的・模範的なものを使っていること
- システムの提供するI/F要素やよく使われているアイコン、標準のテキストスタイル、一般
的な用語や表現を使用すること
- そうして一般的な表現で実装されたものが、ユーザの期待通りの挙動を示すこと

- 直接的な操作（Direct Manipulation）
- 画面上のコンテンツ自体が直接触れるような
UI、挙動になっていること
- そうなっていればユーザはコンテンツを理解しやすく、興味関心を抱きやすい
- Direct Manipulationとは、端末の回転でコンテンツを回転させたり、スワイプのようなジェ
スチャー操作によってコンテンツを移動させたりするような直感的・直接的な操作のことを
いう
- このようにユーザの操作を即座に反映させ、操作と反応をほぼ同時に発生させることで、
直接的に操作している感覚をユーザは得ることができる

- フィードバック（Feedback）
- 適切なフィードバックがあること
- フィードバックとはアクションを受け取り、反応を返すことによってユーザに情報を与えるも
のである
- iOSに最初から入っている標準のアプリでは、どんなユーザアクションでも必ずフィード
バックを返すようになっている
- 例：interactiveな要素をタップしたときに強調(highlight)表示になる
- 例：時間のかかるような操作のステータス表示にはインジケータが使用される
- 例：アクションの結果を示すためにはアニメーションとサウンドが使われる

- メタファー、暗喩、比喩（Metaphors）
- ユーザは良く知っている挙動と類似したような挙動であれば、その挙動を学習しやすい
- そのような慣れ親しんだ体験そのものやそれに類似した挙動のことをメタファーと呼ぶ
- ユーザは画面のタップを通して慣れ親しんだ表現や挙動を期待するため、メタファーはと
ても有効であり、それを活用すること
- 例えば、本や雑誌をめくるかのように、コンテンツをスワイプジェスチャーで切り替えられる
ようにすることがメタファーの活用である

- ユーザによる制御（User Control）
- アプリではなくユーザが制御を行うこと
- アプリが一連のアクションを提案したり、警告を表示したりすることはできる
- しかし、アプリが勝手に意思決定してしまうのは誤りである
- ユーザの操作を受け付けるのか、それとも望ましくない結果を回避するのかについてうま
くバランスを取るように設計されたアプリが、最高のアプリである
- アプリがinteractiveな要素を一般的で挙動の予測しやすい状態に保ち、破壊的なアクショ
ンは確認を取り、処理中であっても簡単にキャンセルできるようにしておくことで、ユーザ
は自分がコントロールしていると感じられるようになる

- appleさんがここで言いたかったこと（超意訳）
- 要はiOSの自然な挙動をイメージして欲しい
- 見た目はもちろんシンプルでとても美しい
- そしてそれは非常に直感的で、説明書なんてなくてもなんとなく操作できちゃう
- やりたいことがあったときにそれを邪魔したりしない、目的達成までは一直線だ
- 見ればどうなるかがすぐ分かるし、
やった結果がどうだったかもスムーズに理解できる
- 操作してないのに何かが起こることはなくて、全ては自分の思いのまま
- それがiOSってものだろ？
- そういうアプリを作ろう

- 前節までのようなiOSアプリを作るために
Appleが提供してるUIKitは大別すると
以下の3つの要素から構成される
3. インターフェースの3つの要素
Bars Views Controls

- Bars
- ユーザがアプリの現在の位置を把握し、画面を遷移するための機能を提供する
ナビゲーションバー、タブバーなど。
Views/Controlsを中に置くこともできる
- Views
- text/graphics/animations/interactive elementsなどの主要なコンテンツを含む目に見え
る要素。スクロール、挿入、削除、配置などの動作も可能
- Controls
- アクションを開始し、情報を伝える要素
- 例：ボタン、スイッチ、テキストフィールド、進行状況インジケータなど
3. インターフェースの3つの要素

- Launching（起動）
- Onboarding（研修、アプリ初回起動から慣れるまでの過程）
- Loading（読み込み）
- Modality
- Navigation
- Accessing User Data and Resources
- Settings（設定）
4. アプリのアーキテクチャ（App Architecture）

- 起動画面とは
- アプリ起動からアプリの最初の画面が表示されるまでの一時的な画面のこと
- 起動画面の役割
- 最初に表示するコンテンツの読み込みをしながらも、アプリ自体は高速ですぐ反応するという
印象を与える役割を持つ
- 起動画面の要件
- 起動後の最初の画面に似た控えめでテキストを含まないデザインにすること

- 起動画面の例

- 起動時の注意事項
- 端末の回転方向に応じた画面表示にすること
- すぐにアプリが使えること
- 使う為にセットアップ情報を必要としないこと
- アプリを使う多数派に向けて自動で設定をし、必要に応じて設定で調整できるようにすること
- セットアップ情報がどうしても必要な場合でも、あとで設定から変更できるようにすること
- アプリ内でライセンス規約や免責事項を表示しないこと
- App Store内で表示し、ダウンロードの前に確認できるようにすること

- 再起動について
- 再起動の時には、前の状態を復元して中断したところから続行できるようにしよう
- 再起動を勧めないこと。時間もかかるし、信頼性が低くて使いにくいアプリに見える
- ストア評価を頻繁に求めないこと
- ユーザには時間を与え、いつでもストア評価ダイアログの表示を offできるようにし、決してアプリ
の評価を強制しないこと

- Onboardingの前提
- アプリを楽しむ手助けとなるように導入の過程を作ること
- セットアップやライセンス詳細を含めないこと（起動の記載と同じ）
- すぐにアプリが使えること（起動の記載と同じ）
- チュートリアルが必要でも、スキップできるようにすること

- ヘルプ・案内について
- 必要な時に適切にヘルプを表示すること
- どんな時に必要か？　→　人が行き詰まっている時に必要
- たとえばゲームでは、一時停止中やキャラクターが移動していないときなど
- 初回の案内を見逃した場合に備えて、チュートリアルを再生できるようにすること

- チュートリアルについて
- 初心者向けに案内をすること自体に問題はない
- しかし、チュートリアルは優れたアプリ設計の代わりにならない
- 何よりもまず、アプリを直感的にすること
- あまりにも多くの案内・情報提供が必要な場合は、アプリの設計を再確認すること

- ユーザがアプリに慣れる為に必要なこと
- 操作を通して楽しく新たな発見・学びができるようにすること
- 少しずつ状況に応じて学べるようにすること
- その為に、アニメーションとユーザの操作に応じた反応を利用すること
- 操作可能に見える静的なスクリーンショットを表示しないこと

- 読み込み状態の表示
- 読み込み中は、読み込み中であるということがユーザに伝わるように明確にすること
- 少なくとも、アクティビティスピナー（クルクル回るやつ）を表示すること
- さらに良いのは、明示的に進行状況を表示し、待機時間が分かるようにすること
- できるだけ早くコンテンツを表示すること
- スケルトンローディングのように、画面自体はすぐに表示し、プレースホルダーやアニメーショ
ンなどを使用して、まだ利用できない場所がどこか分かるようにすること
- アニメーションの再生中やメニューなどで何か操作している時など、できる限りバックグラウン
ドで次のコンテンツを事前読み込みしておくこと

- ユーザへの案内や楽しめる画面にすること
- 読み込み中、ただ待機させるのはもったいない
- 面白い動画や簡単なミニゲーム、 tipsなどを表示しよう
- アプリのスタイルに合わせて、読み込み画面をカスタマイズすること

- Modality
- 一時的に表示し、戻るのにアクションが必要な性質のこと
- 具体的には、今表示中のコンテキストから離れて一時的に別のコンテンツを表示し、前のコンテキストに戻る為
には何かしら明示的なアクションが必要になるような、そうした性質のこと
- これにより、以下のようなことが実現できる
- まとまったタスクの完了の為に集中させたり、情報を集約して見せたりするような、関連性の
ある塊でのタスク提案や表示ができる
- 情報をユーザに提示し、それによってアクションを促せる

- Modality
- システムが提供するモーダル
- アラート
- アクティビティビュー（共有シート）
- アクションシート

- Modality
- iOS13以降で以下のモーダルがサポートされている
- シート（Sheet、別名セミモーダル）
- 複雑なタスクを有効にしない非没入型のコンテンツに使用する
- 全画面（Fullscreen）
- ビデオや写真などの没入型コンテンツや、写真の編集などの複雑で全画面表示の利
点が活かせるタスクで使用する

- Modality
- シート（Sheet、別名セミモーダル）

- Modality
- 全画面（Fullscreen）

- Modality
- モーダル表示における注意点Part 1
- 明確な利点があるときのみ利用すること
- 現在のタスクとは異なるタスクを選択または実行することに注意を集中させることが重要な場合にの
み、モーダルを作成すること
- アラートは重要な情報の提供で利用すること（できれば対応が可能な情報であること）
- アラートは体験を中断する。中断されて当然だとユーザが思えるアラートであることが重要
- 表示するのはシンプルなコンテンツ・タスクにすること
- モーダルが複雑だと、モーダルに入ったときに中断したタスクを見失う可能性がある
- ユーザが迷子にならないように、モーダルの先でさらに階層がある場合には特に注意が必要。階層は
一直線に辿れて、しかも完了の為には何をすればいいかが明確になるようにしましょう

- Modality
- 閉じるためのボタンを常に表示しておくこと
- ボタンはタップだけではなく、アクセシビリティ技術（音声操作など）でも使う
- 閉じると入力情報などが失われる場合、閉じる前に確認を取ること
- tips表示のようなpopoverの更に上にモーダルを出したりしないこと
- モーダルを出す場合、popoverを閉じてから出そう

- Modality
- コンテキストが変わるので、タイトルをつけておくこと
- モーダル表示でガラッとイメージが変わるような表示にしないこと
- 例えば、モーダルで出る画面のナビゲーションバーの色は元のアプリの色に合わせること
- モーダル表示の際の遷移アニメーションを統一すること
- デフォルトの遷移は下から上に出るアニメーション
- 一時的に表示しているということが伝わるようにアプリ全体で一貫した遷移にしよう

- Navigation
- 主要なナビゲーションの形式
- 階層的ナビゲーション
- 例：設定アプリ
- フラットナビゲーション
- 例：App Storeアプリ
- コンテンツ主導や体験主導型ナビゲーション
- 例：ゲームアプリ、書籍アプリ

- Navigation
- 階層的ナビゲーション
- 例：設定アプリ

- Navigation
- フラットナビゲーション
- 例：App Storeアプリ

- Navigation
- コンテンツ主導や体験主導型ナビゲーション
- 例：ゲームアプリ、書籍アプリ

- Navigation
- ナビゲーションにおける注意事項Part 1
- 今どこにいるのか、行きたい場所に辿り着くにはどうすべきかを明確にすること
- コンテンツのパスが論理的で予測可能で、簡単にたどることが不可欠
- 基本的には各画面に辿り着く経路は1つすること。どうしても複数の場所から表示する必要がある場
合、アラートなどのモーダルの使用を検討すること
- 最短で簡単にコンテンツにアクセスできる構造にすること
- ジェスチャー操作により簡単に画面移動できること
- 例：画面を左端から右にスワイプしたときに戻れる

- Navigation
- ナビゲーションにおける注意事項Part 2
- 標準のナビゲーションコンポーネントを使用すること
- ナビゲーションバーやタブバーをうまく活用すること
- ナビゲーションバーは現在の位置のタイトル表示や前に戻るボタンを設置ができる
- タブバーは現在の場所に関係なく、カテゴリをすばやく簡単に切り替えることができる
- 同じ種類の複数コンテンツを表示する場合は、ページコントロールを使用すること

- ユーザーのプライバシーは最も重要である
- ユーザデータやリソースの使用法について透明性を確保する必要がある
- 例えば以下のようなデータにアクセスする場合は許可を求める必要がある
- 位置情報、健康情報、財務情報、連絡先情報、その他の個人識別情報を含む個人データ
- 電子メール、メッセージ、カレンダーデータ、連絡先、ゲームプレイ情報、 Apple Musicアクティ
ビティ、HomeKitデータ、およびオーディオ、ビデオ、写真コンテンツなどのユーザが作成した
コンテンツ
- Bluetooth周辺機器、ホームオートメーション機能、 Wi-Fi接続、ローカルネットワークなどの保
護されたリソース
- カメラやマイクなどのデバイス機能

- アプリで明らかに必要な場合にのみ、権限を要求すること
- できれば、アクセスを必要とする機能を使うときに初めて許可を求めること
- アプリを使うために必要な場合にのみ、起動時に権限を要求すること
- 権限要求アラートに表示するテキストで権限が必要な理由を明確に記載すること
- テキストは端的で具体的、かつ理解しやすい、簡潔で完全な文章を目指すこと

- iOS 15以降では位置情報取得用のボタンが用意されている
- アプリの機能のために一時的に位置情報が必要な場合は
そのボタンの利用を検討すること
- ボタンUIはカスタマイズ可能なので、
アプリのデザインに合わせて調整すること
- 注意：カスタマイズした位置情報ボタンに一貫した問題が
　　　あることがシステムによって確認された場合、
　　　ユーザーがボタンをタップしても、アプリにデバイス
　　　の位置情報へのアクセスが与えられません

- iOS 15以降ではShazamKitという音声認識が利用可能
- 音声認識のためにデバイスのマイクが必要な場合は、各種データ
/リソースへのアクセス
と同様に、マイクへのアクセスを要求する必要がある
- 録音は可能な限り早く停止すること
- 認識した音声をiCloudライブラリに保存できる場合、保存するかどうかはユーザに選択さ
せること

- アラートの前にカスタムメッセージを表示する場合、システムのアラートを出すアクション
のみが可能な状態にすること
- 理想的には、カスタムメッセージなしで文脈で許可を要求する理由が理解できること
- ユーザに遅延戦術と解釈させないように、カスタムメッセージを閉じたら必ずシステムアラート
が表示されること
- アクションのタイトルは「続行」のような言葉を使い、「許可」のようなカスタム画面内で許可を
与えたり他のアクションが実行できるような言葉を使わないこと

- アプリのトラッキングについて
- システムが提供するアラートの前に、人々を混乱させたり誤解させたりするようなカスタム
メッセージを表示しないこと
- アプリのトラッキングはデリケートな問題であり、適切な表示でない場合などは
App Store
Reviewでリジェクトされる可能性があるため、ガイドラインを良く確認しておくこと

- Settings（設定）
- 必要なデータはなるべくシステムから取得すること
- 例：郵便番号の入力を求めるのではなく、現在地の使用許可を求める
- 設定には優先順位をつけること
- 最初に見える画面には重要な設定や頻繁に変える設定を配置する
- 深い階層の方に変える頻度が低い設定を配置する
- 滅多に変更されない設定は設定アプリに置くことも検討する
- 必要に応じて、設定アプリへのショートカットを提供すること
- 例：Push通知や位置情報サービスなど

- HIGではこの他以下の項目について定められている
- User Interaction：3D Touch, App pencil, Audio, Authentication, Data Entry, ...
- System Capabilities：Augmented Reality, Multitasking, Multiple Windows, ...
- Visual Design：Adaptivity and Layout, Animation, Branding, Color, ...
- Icons and Images：Image Size and Resolution, App Icon, Custom Icons, ...
- Bars：Navigation Bars, Search Bars, Status Bars, Tab Bars, Toolbars
- Views：Action Sheets, Activity Views, Alerts, Collections, Image Views, ...
- Controls：Buttons, Context Menus, Edit Menus, Labels, Page Controls
- Extensions：Custom Keyboards, File Providers, Home Screen Actions, ...
5. その他

- HIGでは構成として、前提になる理念・方向性を提示したあと、個別
の要素がどうあるべきかをグループごとにまとめて提示してある
- 前提を理解した上で、都度個別の要素について調べにいくリファレ
ンス的な使い方がしやすいようになっている
- なので、その他の細かい要素の「どうあるべきか」は個々に参照して
いくことが望ましい
5. その他

https://developer.apple.com/design/human-interface-guidelines/

Human Interface Guidelines（iOS版）まとめ資料

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Human Interface Guidelines（iOS版）まとめ資料

Similar to Human Interface Guidelines（iOS版）まとめ資料 (20)