アプリのアーキテクチャ
起動
起動体験はユーザーの心理に大きく影響します。 デバイスの性能や使用頻度によらず、起動は早くなくてはいけないです。
楽しく、違和感のない起動体験の設計をするには以下の要素が重要です。
起動画面の提供
いわゆるスプラッシュ画面。 スプラッシュ画面を表示する意図は、最初のコンテンツの読み込みを可能にしながら、アプリが高速で応答性が高いという印象をユーザーに与えるためです。
適切な方向で起動
アプリの縦向き横向きを判定して適切に表示する必要があります。 SplitViewなども出てきたのでそちらの対応も必要です。
起動後に必要な権限要求をする
ユーザーがアプリを開いたときに情報を提供するように求め、後でアプリの設定で変更できるようにします。 アプリ起動時もですが、位置情報などは必要な画面でダイアログを出すなども検討が必要だと思います。
アプリ内にライセンス契約や免責事項を表示しない
基本はApp Storeに同意書と免責事項はダウンロードする前にユーザーが確認できるようにする必要があります。 アプリに含める必要がある場合はUXを損なわないような設計をします。
アプリの再起動時に以前の状態を復元
アプリキル、バックグラウンド移行からの起動は適切な画面を表示させる必要があります。
再起動を勧めない
再起動には時間がかかり、アプリの信頼性が低く、使いにくいように見えてしまいます。
リリース後すぐに、もしくは頻繁にアプリの評価を依頼しないこと
当たり前ですが、最初のリリース後すぐに、またはユーザーがアプリを使用している間に頻繁に評価を求めるのは煩わしく、正しいフィードバックがさない可能性があります。 決して人々にあなたのアプリを評価することを強制しないでください。
オンボーディング
※いわゆるウォークスルーやコーチマークなどです。
- ライセンスの詳細やセットアップの仕方を載せない
- スキップできる機能をつける
- ヘルプが必要な適切なタイミングを予測する
- 多くのチュートリアルが必要な場合アプリのUIを見直す必要がある
- 指示をするよりも実行して学んでもらうことが1番
ローディング
アプリがフリーズしたように見えるとユーザーがアプリを離れる可能性が高くなるので、ローディングを適切に入れる必要があります。
ロード時間を明確に示す
少なくとも、何かが起こっていることを伝えるアクティビティスピナーを表示します。
できるだけ早くコンテンツを表示する
プレースホルダーテキスト、グラフィックなどを使用して、コンテンツがまだ利用できない場所を特定します。
読み込み時間を楽しませるよう工夫する
ゲームプレイ、面白いビデオシーケンスなどで読み込み時間を有効に活用させます。
ロードのカスタマイズ
アプリやゲームのスタイルに合わせてより世界観に没入できる体験を提供できないか検討必要です。
※別の記事でネイティブアプリに関わらず、6秒未満の待ち時間がある場合はローディングダイアログ（スクリーン）を、7秒以上の場合はプログレスバーを表示させると良いとありました。もちろんケースバイケースです。
モーダリティ
アラートビューやモーダルビューがこれに相当します。
同じコンテキストで一時的に別の操作を終了するために明示的なアクションを必要とする設計手法です。
iOS13以降ではシートと全画面表示の2種類があります。
シート
シートプレゼンテーションスタイルは、メインのコンテンツの上に表示し、カバーされていない領域をすべて淡色表示して、それらとの相互作用を防ぐカードとして表示されます。
親ビューまたは前のカードの上端は、現在のカードの後ろに表示され、 カードを開いたときに中断したタスクを覚えやすくします。
画面を閉じるアクションとして - 画面の上端から下にスワイプ - コンテンツがMaxYの状態で画面を下にスワイプ - ボタンをタップする 複雑なタスクを有効にしない非没入型のモーダルコンテンツのシートを使用します。
全画面表示（Full Screen）
全画面表示スタイルは画面全体をカバーします。 前のビューは完全に覆われ、視覚的な散漫が最小限に抑えられます。 人々はボタンをタップして全画面のモーダルビューを閉じます。
ビデオ、写真、カメラビューなどの没入型コンテンツ、 または写真の編集などのフルスクリーンプレゼンテーションのメリットを活用する複雑なタスクには、フルスクリーンのモーダルビューを使用します。
モダリティの必要性
異なるタスクを選択または実行することに人々の注意を集中させることが重要である場合に使用する。 モーダルは、メインコンテンツから外し、中断アクションを求めるので、 明確な利点を提供する場合にのみ使用することが不可欠です。
モーダルに閉じるボタンを常に含める
たとえば、「完了」または「キャンセル」を使用できます。
閉じる前に確認をとる
何かしらのアクションによってユーザー生成コンテンツが失われる可能性がある場合は、状況を説明し、解決方法を示すアクションシートを提示します。
基本的に、モーダル識別するタイトルを表示
モーダルタスクに入ると、以前のコンテキストから切り替わるので、 新しいコンテキストを明確にすることがお勧めされています。
モーダルビューの外観をアプリと調整する
たとえば、モーダルビューにナビゲーションバーが含まれている場合、アプリのナビゲーションバーと同じ外観を使用する必要があります。
ナビゲーション
ユーザーは自分の期待している機能や画面にアクセスできない状態にならないとナビゲーションに気づかない傾向にあります。 ナビゲーションは自然で親しみやすくアプリの構造と目的をサポートする役割に徹するべきです。
iOSには、3つの主要なナビゲーションスタイルがあります。
- 階層的ナビゲーション
目的地に到着するまで、画面ごとに1つの選択を行います。 別の目的地に移動するには、手順をたどるか、最初からやり直して別の選択をする必要があります。 設定とメールはこのナビゲーションスタイルを使用します。
- フラットナビゲーション
複数のコンテンツカテゴリを切り替えます。 音楽とApp Storeはこのナビゲーションスタイルを使用します。
- コンテンツ主導またはエクスペリエンス主導のナビゲーション
コンテンツ内を自由に移動するか、コンテンツ自体がナビゲーションを定義します。ゲーム、書籍、その他の没入型アプリは通常、このナビゲーションスタイルを使用します。
常に明確なパスを提供
アプリ内のどこにいるか、次の目的地への行き方を常に知っておく必要があります。 ナビゲーションスタイルに関係なく、簡単にたどることが不可欠です。 一般に、各画面へのパスは1つにしてください。 複数のコンテキストで特定の画面を表示したい場合は、 - アクションシート - アラート - ポップオーバー、またはモーダルビュー の使用を検討してください。
すばやく簡単にコンテンツにアクセスできる情報構造を設計すること
最小数のタップ、スワイプ、および画面を必要とする方法で情報構造を整理するべきです
タッチジェスチャーを活用する
スワイプを利用すれば簡単に移動できます。
たとえば、画面の横からスワイプして前の画面に戻ることができます。
標準のナビゲーションコンポーネントを使用する
可能な限り、ページコントロール、タブバー、セグメント化されたコントロール、テーブルビュー、コレクションビュー、分割ビューなど標準のナビゲーションコントロールを使用してください。 ユーザーはこれらのコントロールに慣れており、アプリの操作方法を直感的に理解できます。
ナビゲーションバーを使用して、データの階層を移動する
ナビゲーションバーのタイトルには、階層内の現在の位置を表示できます。 [戻る]ボタンを使用すると、前の場所に簡単に戻ることができます。
タブバーを使用して、コンテンツまたは機能のピアカテゴリを表示します。
タブバーを使用すると、現在の場所に関係なく、カテゴリをすばやく簡単に切り替えることができます。
iPadでは、タブバーの代わりに分割ビューを使用する
分割ビューは、タブバーと同じクイックナビゲーションを提供すると同時に、大きなディスプレイをより有効に活用することができます。
ページコントロール
同じタイプのコンテンツの複数のページがある場合は、ページコントロールを使用します。 ページコントロールは、使用可能なページ数と現在アクティブなページを明確に伝えます。
※個人的にはページコントロールは不要だと思っています。（チュートリアルなど慣れている部分で使うのは良いと思う） 後ろのViewの色などによって目立たない、というかそもそも小さくて目立たないので、 スクロールができることを示すのに十分ではないです。 代替として、画面端に矢印をおいたりセグメントを置くなどがあります。
守ってはいけないiOSデザインとしてこちらにまとめられています。 https://u-site.jp/alertbox/4-ios-rules-break
許可の要求
ユーザーは、アプリが現在の場所、カレンダー、連絡先情報、リマインダー、写真などの 個人情報にアクセスすることを許可する必要があります。 個人情報の利用はユーザーにとって利便性のある機能の提供に限り、基本的に企業側の営利目的で使用することはできません。
※利用の仕方によってはリジェクト対象になるので気をつける必要があります。（実際に位置情報の利用などでありました。）
アプリに情報が必要な理由を説明してください。
システムの権限要求アラートに情報が必要な理由を載せます。 テキストは短く具体的なものにし、文の大文字小文字を使用し、礼儀正しくして、 人々がプレッシャーを感じないようにします。アプリ名を含める必要はありません。
例） 【OK】アプリは、いびき音を検出するために夜間にあなたを記録します。 【NG】より良い体験のためにマイクへのアクセスが必要です。 【NG】マイクへのアクセスをオンにします。
アプリが機能するために必要な場合にのみ、起動時に権限をリクエスト
アプリの操作が個人情報に依存していることが明らかな場合、ユーザーはこのリクエストに悩まされることはありません。
不必要に位置情報を要求しない
位置情報にアクセスする前に、システムをチェックして、位置情報サービスが有効になっているかどうかを確認してください。 この知識があれば、機能で本当に必要になるまでアラートを遅らせたり、アラートを完全に回避したりできます。
設定
一部のアプリは設定機能を提供する必要があります。 ただ、ほとんどのユーザーにとって想定どおりの動きになるようアプリを設計すれば 設定の必要性を減らす事ができます。
可能な限りシステムへ問い合わせる
例えばユーザーに直接住所を入力させるのではなく、現在地情報を取得する許可をシステム側に問い合わせることで 余計な設定の手間を省くことができます。 もし、ユーザーがシステムからの許可を拒否した場合は手入力させます。
優先順位をつける
一次階層にはメインとなる設定を、あまり利用しないものは二次改装にするなど工夫をします。
頻繁に変更されない構成オプションを[設定]で公開
OSの設定アプリは、システム全体で構成を変更するための中心的な場所ですが、 そこに到達するにはアプリを離れる必要があります。 なので、できるだけアプリ内で直接設定を調整する方がはるかに便利です。 もしくはその画面へのショートカットスキーマがあれば、利用し誘導することも可能です。
